Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
> Democracy is not the point IMHO: The point is not to further delay the > release. Implementing a small and safe file format change where everybody > agrees that it is useful does not produce a significant delay. Discussing a > controversal change where no easy solution is in sight has the potential of > delaying the release (at least if the possibility of implementing the change > before the release is seriously considered). Therefore I think that it is > not the right time right now to have this discussion. > Is it really a file format change? If we do not change the physical appearance of the file format, and if we do not change the document output of a certain file, is it then still forbidden to change in a minor release? I mean, it's just a GUI change basically. Vincent
Re: Two Shortcut Changes
Op 5 nov. 2015 21:48 schreef "Jean-Marc Lasgouttes" : > > Le 05/11/15 21:34, Richard Heck a écrit : > >>> I've used PSTricks extensively with LyX. Having a shortcut to ps >>> output has been very convenient. >> >> >> This seems like a case where you should set the default output format to >> Postscript, no? > > > I'd say the same. I am not sure what the use case is, except for people who want to typeset the same document in multiple formats repeatedly. > > Anyway, it was not a good idea to steal C-S-T without stealing C-T too. > > JMarc Should we have a shortcut to export to the last chosen format. So, when I use the toolbar to export to ps, this shortcut let me repeatedly export to ps. If I then choose to export to pdf, this shortcut would export to pdf. Ps, I never liked a document setting indicating the default output format. Vincent
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 21:42, Georg Baum a écrit : I think there is general consensus about \justification and \output_changes, so if this is OK with Scott you could move these to preferences, but for \track_changes I do not see a consensus, so this setting should not be changed so short before a release IMHO. I think that there are still valid points to be discussed, before we resort to democracy. I think everything is on the table now and we can cut down the discussion to this: can we reach a consensus around adding some form of document setting that says "Always open this document with change tracking enabled"? My impression is that it satisfies both use cases of letting us treat change tracking as a per-user-per-document setting, and providing us with a way of distributing copies of change-tracking enabled documents. It would do so better than what we have now in both cases IMO. This does not seem inconsistent with what Libreoffice is doing, which however is not entirely comparable: Libreoffice does indeed store change tracking, but on the one hand they have the philosophy of storing user settings in the file unlike LyX, and on the other hand they include two provisions: 1) for playing nicely with git and 2) for not loading user settings* if that's not wanted. (*disclaimer: for the latter I did not check that change tracking belongs to these non-loaded settings) Democracy is not the point IMHO: The point is not to further delay the release. Implementing a small and safe file format change where everybody agrees that it is useful does not produce a significant delay. Discussing a controversal change where no easy solution is in sight has the potential of delaying the release (at least if the possibility of implementing the change before the release is seriously considered). Therefore I think that it is not the right time right now to have this discussion. Yes, I fully understand this point and I agree that a decision has to be taken somehow quickly, this is why I brought the subject to the list. We are in the process of releasing alpha and this discussion is not delaying alpha, so I believe it comes just in time for 2.2 given the annoyance of the bug and the fact that it incurs a file format change. The other factor is the schedule for the format freeze which I do not request to be delayed. If the case above does not convince, or if there is not enough time before the format freeze, then I am not spending time on an half-baked feature and I will just make the most trivial change there is to be made to avoid this particular merge conflict. Guillaume
Re: [ALPHA Question] Change Toggling Bug
On Fri, Nov 06, 2015 at 11:41:32AM -0500, Richard Heck wrote: > On 11/06/2015 04:12 AM, Jean-Marc Lasgouttes wrote: > >Le 05/11/2015 22:44, Richard Heck a écrit : > >>OK, try this one. > > > >Only 12 minutes, you're a fast learner :) The patch looks perfect to me. > > The code is the documentation, in this case. > > >One advantage of moving stuff to the Buffer class is that it is available > >for command-line changes (although toggling by command line is less useful > >than actually setting). > > And it's just the right place for it, too. > > Scott, is this OK for alpha? OK. Scott
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 21:46, Guillaume Munch a écrit : Le 06/11/2015 21:28, Georg Baum a écrit : Guillaume Munch wrote: Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 02:31, Guillaume Munch a écrit : In terms of least surprise, I would add that both msword 2007 and libreoffice 5 store the setting in the document and consider the document as modified when it is changed (although strangely enough word does not allow to undo the change via Ctrl+Z). I check by sending to another computer that the setting is really attached to the document and not the user. Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to see if CT was recorded. According to my test, CT is not saved with the document. Although ironically the save button gets enabled after toggling CT! Below is the diff. Does that contradict your experiment or have you just tried it with Word? libreoffice 4.3.3.2 stores the setting with the document as well: vs. in content.xml. I would be surprised if both versions 4.3 and 5 store the setting and 4.4 does not store it. Cannot reproduce. Enabled change tracking, made a change, saved, and got . Disabled change tracking, saved, and got again. Strangely, even enabling from the document properties dialog does not change the situation, even though then I expected it to be saved within the document. Maybe there is an option to save within the file or not. Mystery solved: I saved into .fodt (Flat odt) instead of .odt assuming that it was just the uncompressed original file. Apparently it also differs in ways that make it more suitable for versioning systems, like not saving such user preferences into files. So, at least Libreoffice has provisions to make it easier wrt git (for instance there are line breaks everywhere in .fodt files). Note that another provision that Libreoffice has is the option of not loading user preferences from files.
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 21:28, Georg Baum a écrit : Guillaume Munch wrote: Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 02:31, Guillaume Munch a écrit : In terms of least surprise, I would add that both msword 2007 and libreoffice 5 store the setting in the document and consider the document as modified when it is changed (although strangely enough word does not allow to undo the change via Ctrl+Z). I check by sending to another computer that the setting is really attached to the document and not the user. Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to see if CT was recorded. According to my test, CT is not saved with the document. Although ironically the save button gets enabled after toggling CT! Below is the diff. Does that contradict your experiment or have you just tried it with Word? libreoffice 4.3.3.2 stores the setting with the document as well: vs. in content.xml. I would be surprised if both versions 4.3 and 5 store the setting and 4.4 does not store it. Cannot reproduce. Enabled change tracking, made a change, saved, and got . Disabled change tracking, saved, and got again. Strangely, even enabling from the document properties dialog does not change the situation, even though then I expected it to be saved within the document. Maybe there is an option to save within the file or not.
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Guillaume Munch wrote: > Le 05/11/2015 20:25, Georg Baum a écrit : >> Guillaume Munch wrote: >> >>> In addition, what appears even more special to me is the number of times >>> when it produces the effects that you mention: the only times when a >>> per-user, per-document preference would not produce the same effect is >>> the very first time that the user edits the document. >> >> I do not understand this sentence. > > With a per-document setting: we are sure that it is always on after > opening (assuming nobody turns it off) > > With a per-user, per-document setting: we are sure that it is always on > after opening, except maybe the first time, but then the user has just > been told to enable change tracking anyway. Thanks, now I understand. This would not be a problem IMO, if we decide that a per-user, per-document setting is the best choice then this follows naturally. >>> I am willing to >>> bet that that this happened fewer times overall in the past few months >>> for LyX's documentations than the number of times where I had to >>> synchronise with my co-author in the same time frame for a single >>> article. And in any case, having change tracking set automatically on >>> opening is not enough, because you still have to tell new contributors >>> that it is important to track changes. Or did I miss something from your >>> argument? >> >> Well, you need to tell them not to mess with certain settings anyway >> (page format, font size, or all document wide settings, whatever is >> applicable in the specific context). If they do not change document >> settings, then everything is OK. > > I am not sure if we agree or if I missed your point. Then I fear I do not understand what you wanted to say. >> I think there is general consensus about \justification and >> \output_changes, so if this is OK with Scott you could move these to >> preferences, but for \track_changes I do not see a consensus, so this >> setting should not be changed so short before a release IMHO. > > > I think that there are still valid points to be discussed, before we > resort to democracy. Democracy is not the point IMHO: The point is not to further delay the release. Implementing a small and safe file format change where everybody agrees that it is useful does not produce a significant delay. Discussing a controversal change where no easy solution is in sight has the potential of delaying the release (at least if the possibility of implementing the change before the release is seriously considered). Therefore I think that it is not the right time right now to have this discussion. > Also, it would help to have an idea of the schedule for format freeze. Yes. Georg
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Guillaume Munch wrote: > Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit : >> Le 06/11/2015 02:31, Guillaume Munch a écrit : >> >> In terms of least surprise, I would add that both msword 2007 and >> libreoffice 5 store the setting in the document and consider the >> document as modified when it is changed (although strangely enough word >> does not allow to undo the change via Ctrl+Z). >> >> I check by sending to another computer that the setting is really >> attached to the document and not the user. >> > > Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to > see if CT was recorded. According to my test, CT is not saved with the > document. Although ironically the save button gets enabled after > toggling CT! > > Below is the diff. Does that contradict your experiment or have you just > tried it with Word? libreoffice 4.3.3.2 stores the setting with the document as well: vs. in content.xml. I would be surprised if both versions 4.3 and 5 store the setting and 4.4 does not store it. Georg
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Vincent van Ravesteijn wrote: > What actually makes sense is to have a document setting like > "under_version_control". When the user opens such a document (for the > first time?) we turn on change tracking. What has version control to do with change tracking? Georg
Re: [patch] proof of concept for bug 9744: allow parallel configuration of TeX and non-TeX fonts
Guenter Milde wrote: > Dear Georg, dear all, > > On 2015-11-05, Georg Baum wrote: > >> I started to work on bug 9744 in order tor get better test results, as >> discussed. Attached is a proof of concept for the automatic font >> selection. > > Thanks for your work and thanks for the patch. > > For the Document>Settings>Fonts GUI, I suggest > > * radiobuttons or drop-down list for the "fontspec" setting > (auto, tex, non-tex) > > * two tabs for tex vs. non-tex fonts settings. > > This would make it obvious to the user that the settings can be specified > and are kept independently. Since GUI design is not my most advanced skill, I will implement the most simple solution which is possible, or will need help from others. > Currently, it is also not clear which font set is displayed/configured > with the "automatic" setting. As I wrote: The GUI part of the patch is unfinished. The GUI is not supposed to stay like that if the automatic switch is implemented. > One reason for this "double automatic" is, that due to the current setup > we have two competing "Default Output Formats" under > Tools>Preferences>File Handling¹ > > With TeX fonts: > With non-TeX fonts: > > With automatic selection of TeX vs. non-TeX fonts, there could be just one > Default Output Format (and maybe a list of substitutes in case the > document settings prevent the user preverence). Even with automatic it would still be possible to make an explicit choice for the fonts. This would not work with only one default output format. Having a hard coded internal substitution list can look like black magic to the user, and if you make the substitution list configurable then you have more than two formats, and essentially the same problem as we have now with the two formats. > ¹ why are they under "File Handling" and not "Output"? Good question. There is even space in the general tab. > The tests were a trigger for #9744, but the motivation behind it is stated > in the description: > > The usual advise for users experiencing problems with 8-bit TeX is «use > XeTeX» or «use LuaTeX». > > With the current LyX GUI, the most obvious user reaction would be to click > the "view other formats" button and try XeTeX or LuaTeX. However, this > will usually not solve, but worse the problem. > > The reason is, that the common advise "use XeTeX" > > usually implies also to select OpenType fonts with the "fontspec" > package. > > With LyX, this requires checking Document>Settings>Fonts>Use non-TeX > fonts. I understood that. What I do not understand is why it is so important that this button does not need to be pressed (assuming that the font selections survive for switching back and forth). If the document does not compile with one format, then I can toggle the button, configure the fonts (if needed), and be done with it. The font configuration step will also be needed with automatic font selection btw. >> The other motivation would be real use cases by users, and here I am >> not sure: Do such uses cases exist? I am not aware of any. Without the >> automatic setting, the user would have to chose betwen TeX and non-TeX >> fonts, and the recommendation would be to use the default output format >> for viewing. Then we would not have two competing automatic settings, >> and I believe that it is quite unusual to switch frequently between TeX >> engines (but please correct me if I am wrong). > > I tend to use the "View other formats" options a lot to try how a document > looks in different output formats. I really like the possibility to test > different formats without the need to change the document. I understand, but are you the only one who likes that, or is this more wide spread? This is no rethorical question, I honestly don't know, because for my documents it simply does not matter which engine I use. > For HTML or OpenOffice the font set is chosen according to "best practice" > (or just not chosen at all). > > For XeTeX/LuaTeX, the "best practice" (use together with fontspec) is only > available after an explicit change to the document, which has to be > reverted to be able to export to 8-bit TeX again. > >> The test problem could easily be solved in the test machinery instead: >> When exporting via XeTeX or LuaTeX, switch to non-TeX fonts, even if the >> document has a different setting. > > Yes, this is possible. However, if a user wants to compare how our > manuals look after export with LyX-HTML, PDF (ps2pdf), PDF (pdflatex), > PDF (luatex), the comparison is unfair, because luatex is used with a > non-recommended setting. He would need to toggle the tex fonts switch. And of course all manuals should have configured suitable fonts for both choices. Apart from that there will always be output formats that produce ugly results. For example, we have lots of ERT in our manuals, and I don't think that lyxhtml export will look good without doing major changes first. Please do not ge
Re: new patch for Xe/LuaTeX with TeX-fonts
On 2015-11-06, Guenter Milde wrote:
> On 2015-11-06, Kornel Benko wrote:
>> [-- Type: text/plain, Encoding: 7bit --]
>> Am Donnerstag, 5. November 2015 um 20:12:53, schrieb Guenter Milde
>>
>> ...
>>>pass "LaTeXFeatures & features" as argument
>>>and test for "features.runparams().flavor == OutputParams::XETEX"
>>>(cf. BufferParams::writeEncodingPreamble().
>>>Alternatively, pass and use just "runparams".
>>>+1 solves the FIXME
>>>+1 logic at one place
>>>+1 calling BufferParams::encoding() returns the correct encoding
>>>+1 remove hack and FIXME from Buffer.cpp (2 instances).
>>>-3 all calls must be changed to hand over an instance of
>>> "LaTeXFeatures" or "runparams".
>>> I need both, advise on which way to go and a helping hand with the actual
>>> implementation.
>> I'd say this is the right way. But I wonder why BufferParams class does
>> not have access to features.
> From the source doc:
> Buffer parameters.
> This class contains all the parameters for this buffer's use.
> These are known once a document is loaded into the buffer and only change
> when updating Document>Settings.
> The export target and "flavour" is only known after a user request to export
> the document.
> One more idea:
> Encoding const & BufferParams::encoding() const
> {
> // FIXME: additionally, we must check for runparams().flavor == XeTeX
> // to care for the combination of XeTeX and TeX-fonts (see #9740).
> // Currently, we reset the encoding in Buffer::makeLaTeXFile
> // (for export) and Buffer::writeLaTeXSource (for preview).
> Would it help to set BufferParams::inputenc to "ascii" as soon as we know
> the export uses XeTeX?
Answering myself: no - as this would stick for the next export -- possibly
with another "flavour".
Another way out would be to disable XeTeX export unless either the
inputencoding is set to ASCII or the font-set to non-TeX-fonts.
Günter
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 04:37, Pavel Sanda a écrit : Guillaume Munch wrote: express any intention. Your description gives the impression that if your collaborator starts writing and they do not see that the changes are not being tracked, then they will not know or care about enabling change tracking, as if they had no clue, and this little button has to be enabled for them without them to know about it... This seems a bit far fetched to me. It is actually were rare that I co-work with geeks and I am very lucky if I have someone willing to open file in lyx, not to talk about recognizing what various buttons on toolbar might mean. If I set all things (e.g. set CT on) and ask just for simple editing operations I have some chance to go with lyx... I am not far fetching things but I understand that my experience is actually hard to transmit if your usuall colleagues are computer scientist in their 30s or similar. Note: I am not minimizing your use case. I am only pointing out that your description was not the best to illustrate your needs and the reasons behind them. Please understand that it's not necessarily easier on my side to handle needless merge or rebase conflicts, and my co-authors are not all used to lyx and git. That conflict in particular was pointed out to me by my co-author as being a bug in LyX after I explained what had happened. Guillaume
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 09:06, Jean-Marc Lasgouttes a écrit : Le 06/11/2015 02:31, Guillaume Munch a écrit : Besides the lack of intention conveyed, I already mentioned the principle of least surprise: it is not clear for a new user that this is a purpose of the button. So if what is currently implemented is really what you have in mind, then it is a very poorly designed feature. In terms of least surprise, I would add that both msword 2007 and libreoffice 5 store the setting in the document and consider the document as modified when it is changed (although strangely enough word does not allow to undo the change via Ctrl+Z). I check by sending to another computer that the setting is really attached to the document and not the user. Ah, I concluded the contrary by testing Libreoffice (4.4) using diff to see if CT was recorded. According to my test, CT is not saved with the document. Although ironically the save button gets enabled after toggling CT! Below is the diff. Does that contradict your experiment or have you just tried it with Word? In any case I think the new proposal of a checkbox "Open with change tracking enabled" would improve the situation for both use cases. 4c4 < 2015-11-06T17:33:37.0962274562015-11-06T17:34:51.144047803PT1M13S3LibreOffice/4.4.6.3$Linux_X86_64 LibreOffice_project/40m0$Build-3meta:image-count="0" meta:object-count="0" meta:page-count="1" meta:paragraph-count="1" meta:word-count="1" meta:character-count="4" meta:non-whitespace-character-count="4"/> --- > 2015-11-06T17:33:37.0962274562015-11-06T17:34:30.707867127PT53S2LibreOffice/4.4.6.3$Linux_X86_64 LibreOffice_project/40m0$Build-3meta:image-count="0" meta:object-count="0" meta:page-count="1" meta:paragraph-count="1" meta:word-count="1" meta:character-count="4" meta:non-whitespace-character-count="4"/>
Re: new patch for Xe/LuaTeX with TeX-fonts
On 2015-11-06, Kornel Benko wrote:
> [-- Type: text/plain, Encoding: 7bit --]
> Am Donnerstag, 5. November 2015 um 20:12:53, schrieb Guenter Milde
>
> ...
>>pass "LaTeXFeatures & features" as argument
>>and test for "features.runparams().flavor == OutputParams::XETEX"
>>(cf. BufferParams::writeEncodingPreamble().
>>Alternatively, pass and use just "runparams".
>>+1 solves the FIXME
>>+1 logic at one place
>>+1 calling BufferParams::encoding() returns the correct encoding
>>+1 remove hack and FIXME from Buffer.cpp (2 instances).
>>-3 all calls must be changed to hand over an instance of
>> "LaTeXFeatures" or "runparams".
>> I need both, advise on which way to go and a helping hand with the actual
>> implementation.
> I'd say this is the right way. But I wonder why BufferParams class does
> not have access to features.
>From the source doc:
Buffer parameters.
This class contains all the parameters for this buffer's use.
These are known once a document is loaded into the buffer and only change
when updating Document>Settings.
The export target and "flavour" is only known after a user request to export
the document.
One more idea:
Encoding const & BufferParams::encoding() const
{
// FIXME: additionally, we must check for runparams().flavor == XeTeX
// to care for the combination of XeTeX and TeX-fonts (see #9740).
// Currently, we reset the encoding in Buffer::makeLaTeXFile
// (for export) and Buffer::writeLaTeXSource (for preview).
Would it help to set BufferParams::inputenc to "ascii" as soon as we know
the export uses XeTeX?
Could we use this instead of or in addition to the action in
Buffer::makeLaTeXFile and Buffer::writeLaTeXSource?
>> > Next 12 tests with changed outcome
>> How many reversions? (or is XeTeX+Tex-fonts export now suspended)
> None. ...
Nevertheless, there are documents that fail due to this change :-(
Günter
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 07:01, Vincent van Ravesteijn a écrit : Op 6 nov. 2015 05:44 schreef "Pavel Sanda" mailto:sa...@lyx.org>>: > > Guillaume Munch wrote: > > That "CT lock" feature, instead of imposing such a strict constraint > > (that could always be circumvented one way or the other...), could maybe > > display instead a message like "Pavel Sanda has requested that changes > > be tracked. Are you sure that you want to disable change tracking?". > > > > But I would like to read more suggestions from you and Günter given that > > you know better than us what you need. > > No need for locking. I just want to setup defaults which holds for people > receiving the document without me explaining how they should edit it. > If they know what they are doing (or how to do it:) they are free to disable it. > > Pavel What actually makes sense is to have a document setting like "under_version_control". When the user opens such a document (for the first time?) we turn on change tracking. Important is to not save the current state of change tracking. I do like this idea. If I understand correctly: Have a new checkbox in document settings labelled "Open with change tracking enabled". Then the current state of change tracking is made independent from this checkbox; only, if the box is checked then it will do as advertised by the label. Otherwise, the per-user, per-session setting is restored. This seems to fit better than the current situation what I understand of Pavel and other people's use case for change tracking. Indeed, even in this case, one could want to disable it on purpose momentarily, and this new setting would mean that one does not need to worry about turning change tracking back on before saving. Pavel, is this what you had in mind with "permanent vs. until the end of the session" ? Actually we could also treat \output_changes in this way, which makes even more sense for it given that it affects the output. Is that convincing? Guillaume
Re: screen indenting after frames
2015-11-06 17:43 GMT+01:00 Richard Heck: > On 11/06/2015 02:34 AM, Jürgen Spitzmüller wrote: > >> Am Donnerstag 05 November 2015, 18:57:52 schrieb Edwin Leuven: >> >>> i agree >>> >>> may i suggest that you push this change to master? >>> >> I've pushed something similar. >> >> Might be something to consider for branch. >> > > Sure. > OK. Done. Jürgen > > Richard > >
Re: screen indenting after frames
On 11/06/2015 02:34 AM, Jürgen Spitzmüller wrote: Am Donnerstag 05 November 2015, 18:57:52 schrieb Edwin Leuven: i agree may i suggest that you push this change to master? I've pushed something similar. Might be something to consider for branch. Sure. Richard
[ALPHA Question] Change Toggling Bug
On 11/06/2015 04:12 AM, Jean-Marc Lasgouttes wrote: Le 05/11/2015 22:44, Richard Heck a écrit : OK, try this one. Only 12 minutes, you're a fast learner :) The patch looks perfect to me. The code is the documentation, in this case. One advantage of moving stuff to the Buffer class is that it is available for command-line changes (although toggling by command line is less useful than actually setting). And it's just the right place for it, too. Scott, is this OK for alpha? Richard
Re: screen indenting after frames
Le 06/11/2015 07:34, Jürgen Spitzmüller a écrit : Am Donnerstag 05 November 2015, 18:57:52 schrieb Edwin Leuven: i agree may i suggest that you push this change to master? I've pushed something similar. Might be something to consider for branch. Jürgen Thank you!
Re: [LyX/master] Fix algorithm that computes horizontal scroll offset
Le 04/11/2015 00:12, Scott Kostyshak a écrit : Starting with this commit, if I open e.g. the Introduction manual and I triple click on the first line of the first paragraph (starting with "LyX is a document preparation system...", the line is selected and the text jumps a little to the left. If I click then on that line again, the selection is removed and the text does not again change position. But if I then click on a different line, the text jumps back to where it was before. Should be fixed now. Actually it was due to TextMetrics::computeRowMetrics where row.width computation was wrong for text that is not left-aligned. Since the commit above relied on this value, it did not work correctly. JMarc
Re: [patch] proof of concept for bug 9744: allow parallel configuration of TeX and non-TeX fonts
Am Donnerstag, 5. November 2015 um 21:04:03, schrieb Scott Kostyshak > On Thu, Nov 05, 2015 at 09:12:56PM +0100, Georg Baum wrote: > > > The test problem could easily be solved in the test machinery instead: When > > exporting via XeTeX or LuaTeX, switch to non-TeX fonts, even if the > > document > > has a different setting. Unless someone presents a convincing use case for > > the automatic setting, I would like to proceed this way, and only duplicate > > the font settings, so that both the TeX and non-TeX settings could be > > stored > > in parallel. The GUI would still look exactly like before, but you would > > not > > loose the "other" font set if you toggle. > > Thanks for working on this, Georg. +1 > As far as I'm concerned, whatever you > and Günter decide is fine with me since you two seem to be the only ones > that understand what should happen. As far as the tests, I don't have a > strong preference. I think we should try to get the tests to reflect > real user scenarios as much as possible so what you propose sounds > reasonable to me. Let's see what Kornel thinks. The test machinery already select a non-TeX-font. ATM it depends only on the language folder (e.g. /hu/, /he/, etc.) but we could do it also depending on some content in lyx-file. Disabling TeX fonts for lualatex and xelatex is easy. One liner in ignoredTests, but I am not a big fan of it. > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: new patch for Xe/LuaTeX with TeX-fonts
Am Donnerstag, 5. November 2015 um 20:12:53, schrieb Guenter Milde ... >pass "LaTeXFeatures & features" as argument >and test for "features.runparams().flavor == OutputParams::XETEX" >(cf. BufferParams::writeEncodingPreamble(). > >Alternatively, pass and use just "runparams". > >+1 solves the FIXME >+1 logic at one place >+1 calling BufferParams::encoding() returns the correct encoding >+1 remove hack and FIXME from Buffer.cpp (2 instances). > >-3 all calls must be changed to hand over an instance of > > "LaTeXFeatures" or "runparams". > > I need both, advise on which way to go and a helping hand with the actual > implementation. I'd say this is the right way. But I wonder why BufferParams class does not have access to features. > > Next 12 tests with changed outcome > > How many reversions? (or is XeTeX+Tex-fonts export now suspended) None. All of them (beamer-article,svmono_chapter,svmult_author) have only export label. Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Fix algorithm that computes horizontal scroll offset
Le 06/11/2015 12:10, Stephan Witt a écrit : MARGIN is now the right margin of the row plus 2em. That's why the row scrolls to left too early, IMHO. It starts scrolling before reaching the margin. Is this intended? Obviously I did something wrong and did not test enough. I am on it right now. This use of a virtual margin, which intends to make sure that you see some context around the cursor is difficult to get right, especially since we reduce this margin when all the context is actually available. I am not sure though that is is the best experience. Any idea on how it should behave when the cursor moves near the margins is welcome, of course. JMarc
Re: [LyX/master] Fix algorithm that computes horizontal scroll offset
Am 02.11.2015 um 11:18 schrieb Jean-Marc Lasgouttes :
> commit 1f0d210ab56057f35960a3b86f5fa1e03ef8ecd0
> Author: Jean-Marc Lasgouttes
> Date: Tue Oct 27 16:11:01 2015 +0100
>
>Fix algorithm that computes horizontal scroll offset
>
>Rewrite the logic completely:
>* fix cases where the offset was reset unnecessarily
>* fix cases where the row was scrolled too much: as soon as a side of the
> row is completely visible, there is no need to scroll more.
>* fix cases where offset would never reset
>
> diff --git a/src/BufferView.cpp b/src/BufferView.cpp
> index 658fa0e..7287ad8 100644
> --- a/src/BufferView.cpp
> +++ b/src/BufferView.cpp
> @@ -3042,18 +3042,27 @@ void BufferView::checkCursorScrollOffset(PainterInfo
> & pi)
>
> // Horizontal scroll offset of the cursor row in pixels
> int offset = d->horiz_scroll_offset_;
> - int const MARGIN = 2 *
> theFontMetrics(d->cursor_.real_current_font).em();
> - //lyxerr << "cur_x=" << cur_x << ", offset=" << offset << ", margin="
> << MARGIN << endl;
> - if (cur_x < offset + MARGIN) {
> - // scroll right
> - offset = cur_x - MARGIN;
> - } else if (cur_x > offset + workWidth() - MARGIN) {
> - // scroll left
> - offset = cur_x - workWidth() + MARGIN;
> + int const MARGIN = 2 * theFontMetrics(d->cursor_.real_current_font).em()
> ++ row.right_margin;
MARGIN is now the right margin of the row plus 2em.
That's why the row scrolls to left too early, IMHO.
It starts scrolling before reaching the margin.
Is this intended?
Stephan
Re: [patch] Finding the generated latex file
Le 06/11/2015 04:16, Scott Kostyshak a écrit : I also agree that it's better to replace the alert with a message on stderr. I noticed that there are already similar messages on the terminal when files cannot be removed. Attached is a patch. Shall I commit it? Although I personally like this (as I noted above), I think we should get opinions from a couple of other LyX developers. From a quick search, we have been giving a dialog for more than 10 years so there might be a good reason for it. I think that a stderr message is good enough. I do not remember a discussion about having this dialog. If you want to know, find when it was introduced, and look at lyx-devel archives from this time. JMarc
Re: screen indenting after frames
On 06 Nov 2015, at 08:34, Jürgen Spitzmüller wrote: > Am Donnerstag 05 November 2015, 18:57:52 schrieb Edwin Leuven: >> i agree >> >> may i suggest that you push this change to master? > > I've pushed something similar. great > Might be something to consider for branch. yes please best, ed.
Re: [patch] proof of concept for bug 9744: allow parallel configuration of TeX and non-TeX fonts
Dear Georg, dear all, On 2015-11-05, Georg Baum wrote: > I started to work on bug 9744 in order tor get better test results, as > discussed. Attached is a proof of concept for the automatic font selection. Thanks for your work and thanks for the patch. For the Document>Settings>Fonts GUI, I suggest * radiobuttons or drop-down list for the "fontspec" setting (auto, tex, non-tex) * two tabs for tex vs. non-tex fonts settings. This would make it obvious to the user that the settings can be specified and are kept independently. Currently, it is also not clear which font set is displayed/configured with the "automatic" setting. > However, while working on this, I realized that this will create a > combination of settings where we need to make an arbitrary choice: What > should happen if the fonts are set to automatic, and the user wants to view > the default output format? With the patch, the traditional route via TeX > fonts is chosen, but this is an arbitrary decision which I do not like. I can understand the hesitation. One reason for this "double automatic" is, that due to the current setup we have two competing "Default Output Formats" under Tools>Preferences>File Handling¹ With TeX fonts: With non-TeX fonts: With automatic selection of TeX vs. non-TeX fonts, there could be just one Default Output Format (and maybe a list of substitutes in case the document settings prevent the user preverence). ¹ why are they under "File Handling" and not "Output"? > One motivation for the automatic setting was to get the tests right. The tests were a trigger for #9744, but the motivation behind it is stated in the description: The usual advise for users experiencing problems with 8-bit TeX is «use XeTeX» or «use LuaTeX». With the current LyX GUI, the most obvious user reaction would be to click the "view other formats" button and try XeTeX or LuaTeX. However, this will usually not solve, but worse the problem. The reason is, that the common advise "use XeTeX" usually implies also to select OpenType fonts with the "fontspec" package. With LyX, this requires checking Document>Settings>Fonts>Use non-TeX fonts. > The other motivation would be real use cases by users, and here I am > not sure: Do such uses cases exist? I am not aware of any. Without the > automatic setting, the user would have to chose betwen TeX and non-TeX > fonts, and the recommendation would be to use the default output format > for viewing. Then we would not have two competing automatic settings, > and I believe that it is quite unusual to switch frequently between TeX > engines (but please correct me if I am wrong). I tend to use the "View other formats" options a lot to try how a document looks in different output formats. I really like the possibility to test different formats without the need to change the document. For HTML or OpenOffice the font set is chosen according to "best practice" (or just not chosen at all). For XeTeX/LuaTeX, the "best practice" (use together with fontspec) is only available after an explicit change to the document, which has to be reverted to be able to export to 8-bit TeX again. > The test problem could easily be solved in the test machinery instead: When > exporting via XeTeX or LuaTeX, switch to non-TeX fonts, even if the document > has a different setting. Yes, this is possible. However, if a user wants to compare how our manuals look after export with LyX-HTML, PDF (ps2pdf), PDF (pdflatex), PDF (luatex), the comparison is unfair, because luatex is used with a non-recommended setting. > Unless someone presents a convincing use case for the automatic > setting, I would like to proceed this way, and only duplicate the font > settings, so that both the TeX and non-TeX settings could be stored in > parallel. The GUI would still look exactly like before, but you would > not loose the "other" font set if you toggle. This would in any case be a big advantage. It is also the pre-condition for "automatic" choice, if we decide to use this. Thanks, Günter
Re: [ALPHA] Change Toggling Bug
Le 06/11/2015 05:42, Vincent van Ravesteijn a écrit :
The fact that the setting was set in BufferView, the fact that it didn't
call markDirty or recordUndo, all tell me that this setting was not
supposed to be a document property.
Historically, lots of thing that required only a buffer and no view has
been handled in BufferView by laziness. Actually at the time in 2003
Buffer::dispatch was a bit frugal (from 60ec905):
bool Buffer::dispatch(int action, string const & argument, bool * result)
{
bool dispatched = true;
switch (action) {
case LFUN_EXPORT: {
bool const tmp = Exporter::Export(this,
argument, false);
if (result)
*result = tmp;
break;
}
default:
dispatched = false;
}
return dispatched;
}
I would say it had been created for exporting stuff from the command
line, but nobody dreamed of running other buffer-only lfuns from the
command line.
And as far as undo is concerned, I'm afraid that we were not very good
12 years ago.
It probably was stored in the file, because there is no easy machinery
at hand to store a document-specific user preference.
Prove it ;)
JMarc
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
On Fri, Nov 6, 2015 at 10:08 AM, Jean-Marc Lasgouttes wrote: > Le 06/11/2015 10:06, Stephan Witt a écrit : >> >> In this sense there is no need to reduce the likely-hood of merge >> conflicts >> with the state of change tracking. It's not a setting to toggle often, >> IMHO. > > > Well, since some people do change it often (if only to piss off their > co-author :), we could try to see how to mitigate the problem IMO. > > JMarc > Using change tracking continuously will make a huge mess of your document. Imagine moving a float one paragraph down, none of your co-authors cares probably (as the float is floating anyway), but the on the screen it clutters everything. I always have to take care to accept the stuff not really relevant for my co-authors to review, such that they focus on the parts that changed meaning or not. I often disable change tracking when fixing small things, when incorporating previous feedback from co-authors, when doing LyX/LaTeX special stuff, when writing a large new paragraph (it hurts the eyes looking at that as change) and afterwards I will either cut and paste it to show that it is added or my coauthors will know that that part is new. Then, the LyX documentation is supposed to be _the_ workflow in which the current setting of track changes is optimal. Looking in Math.lyx, and UserGuide.lyx in master and in 2.1.x, they all have "\track_changes false". So, it is not working like it is now. I'm not against having a document setting whether the document is using track changes or not, I'm just against storing whether I accidentally had it enabled or not when I saved the document. Vincent
Re: [ALPHA] Change Toggling Bug
Le 05/11/2015 22:44, Richard Heck a écrit : OK, try this one. Only 12 minutes, you're a fast learner :) The patch looks perfect to me. One advantage of moving stuff to the Buffer class is that it is available for command-line changes (although toggling by command line is less useful than actually setting). JMarc
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 10:06, Stephan Witt a écrit : In this sense there is no need to reduce the likely-hood of merge conflicts with the state of change tracking. It's not a setting to toggle often, IMHO. Well, since some people do change it often (if only to piss off their co-author :), we could try to see how to mitigate the problem IMO. JMarc
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 02:31, Guillaume Munch a écrit : Besides the lack of intention conveyed, I already mentioned the principle of least surprise: it is not clear for a new user that this is a purpose of the button. So if what is currently implemented is really what you have in mind, then it is a very poorly designed feature. In terms of least surprise, I would add that both msword 2007 and libreoffice 5 store the setting in the document and consider the document as modified when it is changed (although strangely enough word does not allow to undo the change via Ctrl+Z). I check by sending to another computer that the setting is really attached to the document and not the user. JMarc
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Am 06.11.2015 um 09:52 schrieb Jean-Marc Lasgouttes : > Le 06/11/2015 05:37, Pavel Sanda a écrit : >> Guillaume Munch wrote: >>> express any intention. Your description gives the impression that if >>> your collaborator starts writing and they do not see that the changes >>> are not being tracked, then they will not know or care about enabling >>> change tracking, as if they had no clue, and this little button has to >>> be enabled for them without them to know about it... This seems a bit >>> far fetched to me. >> >> It is actually were rare that I co-work with geeks and I am very >> lucky if I have someone willing to open file in lyx, not to talk >> about recognizing what various buttons on toolbar might mean. > > First a disclaimer: I do not use change tracking with LyX (otherwise I would > have implemented hidden deletions long ago :). I do however, use it when I am > force to collaborate through .doc file (for research contracts mostly). And I > can tell you the truth: > > People don't know what they are doing. > > In this sense, I support keeping a permanent setting for change tracking, as > a state of a document. I think that the workflow "some of the coauthors use > CT for fun" is not what should dictate the design of the feature. I'm using change tracking with LyX-documentation only and think this is an good example for a workflow where the state should be part of the document. All the co-authors use change tracking and one person is doing the review and accepts the changes and controls the state of the change tracking. I agree with Pavel that there is no need for security whistles and bells to make change tracking mandatory for some document. In this sense there is no need to reduce the likely-hood of merge conflicts with the state of change tracking. It's not a setting to toggle often, IMHO. Stephan
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Le 06/11/2015 05:37, Pavel Sanda a écrit : Guillaume Munch wrote: express any intention. Your description gives the impression that if your collaborator starts writing and they do not see that the changes are not being tracked, then they will not know or care about enabling change tracking, as if they had no clue, and this little button has to be enabled for them without them to know about it... This seems a bit far fetched to me. It is actually were rare that I co-work with geeks and I am very lucky if I have someone willing to open file in lyx, not to talk about recognizing what various buttons on toolbar might mean. First a disclaimer: I do not use change tracking with LyX (otherwise I would have implemented hidden deletions long ago :). I do however, use it when I am force to collaborate through .doc file (for research contracts mostly). And I can tell you the truth: People don't know what they are doing. In this sense, I support keeping a permanent setting for change tracking, as a state of a document. I think that the workflow "some of the coauthors use CT for fun" is not what should dictate the design of the feature. principle of least surprise: it is not clear for a new user that this is a purpose of the button. So if what is currently implemented is really what you have in mind, then it is a very poorly designed feature. I am not toolbar person and always used menu for toggling, it might be that toolbar buttons are completely screewed without me noticing :) Before you started this thread it felt natural that CT on/off state should be document setting and not otherwise. How other office packages deal with this? Pavel
Re: RFC: better submenu for tables
Le 04/11/2015 17:19, Richard Heck a écrit : - everything is removed for which we also have toolbar button. (If users disabled the automatic show of the table toolbar they apparently don't use tables that much and the table settings dialog is sufficient) This is not how contextual menus are supposed to work IMO. I would propose instead to use submenus and to micmick what libreoffice (for ex.) does. I personally hate toolbars and almost never use them. So I'd prefer that things not be removed simply because they're also on a toolbar. And I would think that most HIG guides discourage this. JMarc
