Yes. Changing the theme fixes the problem. It seems that the "windows11"
theme is the only one with this issue.
On Mon, Jul 8, 2024 at 4:49 PM LyX Ticket Tracker wrote:
> #13082: Tools | Preferences | Look & Feel | Display graphics | Preview
> size box
>
On Fri, Aug 25, 2023 at 01:36:41PM +0200, Pavel Sanda wrote:
> > At this point I suggest reverting the change you made, unless someone else
> > claims to have reproduced the bug. But it is just a suggestion.
>
> Ok, I can do that.
Committed. P
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
On Wed, Aug 23, 2023 at 11:06:01AM +0200, Dan wrote:
> >> The problem
> >>
> >> Follow through
> >> 1. Run Lyx (version, build and OS info in the text attatchment).
> >> 2. Open the Preferences dialog (Tools > Preferences). 3.
Therefore, this problem should not appear
> to begin with...
>
> For contrast see Tools > Preferences > Look & Feel > Document
> Handling.
> The spin box for the number of minutes
> (https://www.lyx.org/trac/browser/lyxgit/src/frontends/qt/ui/PrefDocH
> andlingUi.ui#L
>> The problem
>>
>> Follow through
>> 1. Run Lyx (version, build and OS info in the text attatchment).
>> 2. Open the Preferences dialog (Tools > Preferences). 3. In the Look and
>> Feel section, choose User Interface.
>>
1. Run Lyx (version, build and OS info in the text attatchment).
> 2. Open the Preferences dialog (Tools > Preferences). 3. In the Look and
> Feel section, choose User Interface.
> 4. Set the number of recent documents to more than 9.
> 5. The last digit of the two-digit number
Hello,
I think I have stumbled upon a bug in Lyx (development version) not yet
reported, or at least I did not manage to find it in the bug tracker.
The problem
Follow through
1. Run Lyx (version, build and OS info in the text attatchment).
2. Open the Preferences dialog
On Fri, May 05, 2023 at 07:26:37PM +0200, Jean-Marc Lasgouttes wrote:
> Make sense. I would have put it in Display subsection, though.
Thanks for taking a look.
Sounds good, I passed that comment on (on the ticket).
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx
Le 05/05/2023 à 19:26, Jean-Marc Lasgouttes a écrit :
Le 05/05/2023 à 18:12, Scott Kostyshak a écrit :
Yuriy has a patch here:
https://www.lyx.org/trac/ticket/12124#comment:2
Any objection?
It's a bit weird that we have Editing > Control and then inside of
that we have another "Editing" s
Le 05/05/2023 à 18:12, Scott Kostyshak a écrit :
Yuriy has a patch here:
https://www.lyx.org/trac/ticket/12124#comment:2
Any objection?
It's a bit weird that we have Editing > Control and then inside of that we have another "Editing"
section and "Fullscreen" section. To me that's a signal
Yuriy has a patch here:
https://www.lyx.org/trac/ticket/12124#comment:2
Any objection?
It's a bit weird that we have Editing > Control and then inside of that we have
another "Editing" section and "Fullscreen" section. To me that's a signal that
the "Fullscreen" section is out of place.
Sco
On 08.09.2017 14:11, Jürgen Spitzmüller wrote:
Am Freitag, den 08.09.2017, 07:32 +0200 schrieb racoon:
Hi,
Can someone point me to the place where the preferences modules are
reset when opening the Preferences for the second time, e.g. after
clicking Cancel the first time and then reopening it
Am Freitag, den 08.09.2017, 07:32 +0200 schrieb racoon:
> Hi,
>
> Can someone point me to the place where the preferences modules are
> reset when opening the Preferences for the second time, e.g. after
> clicking Cancel the first time and then reopening it?
>
> More speci
Hi,
Can someone point me to the place where the preferences modules are
reset when opening the Preferences for the second time, e.g. after
clicking Cancel the first time and then reopening it?
More specifically, I am looking for the resetting of colors. I believe
that the colors are
On Mon, Aug 07, 2017 at 02:26:25PM +0930, racoon wrote:
> Thanks. It seem that you are correct. Unfortunately, I did not find where
> the zoom is set but I tested it without the dispatch and it seems to work
> totally fine. Would you mind removing the dispatch line then?
Thanks for testing, Danie
On 03.08.2017 07:32, Scott Kostyshak wrote:
On Tue, Jul 25, 2017 at 08:23:39AM +1000, racoon wrote:
On 25.07.2017 07:49, Scott Kostyshak wrote:
On Sat, Jul 22, 2017 at 07:41:32PM +1000, racoon wrote:
On 22.07.2017 08:38, Scott Kostyshak wrote:
No, sorry. Most importantly, I do not understan
On Tue, Jul 25, 2017 at 08:23:39AM +1000, racoon wrote:
> On 25.07.2017 07:49, Scott Kostyshak wrote:
> > On Sat, Jul 22, 2017 at 07:41:32PM +1000, racoon wrote:
> > > On 22.07.2017 08:38, Scott Kostyshak wrote:
> >
> > > No, sorry. Most importantly, I do not understand what the debug messages
> >
This looks weird.
As far as I could see, reading preferences is done via
LyXRC::read(FileName const & filename, bool check_format)
which return true if everything is OK.
But if using '\input "some file"', we land at src/LyXRC.cpp:464
Changing as attached, cures it
On 25.07.2017 07:49, Scott Kostyshak wrote:
On Sat, Jul 22, 2017 at 07:41:32PM +1000, racoon wrote:
On 22.07.2017 08:38, Scott Kostyshak wrote:
No, sorry. Most importantly, I do not understand what the debug messages
mean. Unfortunately, I also do not have much time at my hands at the moment
On Sat, Jul 22, 2017 at 07:41:32PM +1000, racoon wrote:
> On 22.07.2017 08:38, Scott Kostyshak wrote:
> No, sorry. Most importantly, I do not understand what the debug messages
> mean. Unfortunately, I also do not have much time at my hands at the moment
> either. I am happy to help though, if som
Preferences shows current zoom instead of preference's default zoom
(#10455)
- Adds a currentZoom variable which holds the current zoom level.
- The zoom stored in preferences is used as default zoom level (default binding:
M+0).
- The currentZoom is save
On Tue, Jul 18, 2017 at 04:43:44AM -0400, Scott Kostyshak wrote:
> On Sun, May 07, 2017 at 02:18:41PM +0200, Guillaume MM wrote:
> > commit 4183a9f4dc9bc0893fc59cd7e31db9bc7e52eea9
> > Author: Daniel Ramöller
> > Date: Sat Oct 29 10:28:34 2016 +0200
> >
> >
On Sun, May 07, 2017 at 02:18:41PM +0200, Guillaume MM wrote:
> commit 4183a9f4dc9bc0893fc59cd7e31db9bc7e52eea9
> Author: Daniel Ramöller
> Date: Sat Oct 29 10:28:34 2016 +0200
>
> Preferences shows current zoom instead of preference's default zoom
> (#10455
On Thu, Jun 08, 2017 at 04:54:25PM +0200, Jean-Marc Lasgouttes wrote:
> Sctott,
>
> Do you plan to make these files available somewhere ? For example I am
> curious about macro editing mode.
Sure. I only received one private email, and the user gave permission
for it to be made public. I forward
Le 01/06/2017 à 22:07, Scott Kostyshak a écrit :
Dear all,
There are many different preferences that the user can customize. It is
difficult to think about what is the best default preferences for the
most amount of users. One way I've thought of to get an idea of this is
to start colle
As someone who actually met José, I can testify that he actually _is_ a smiley.
JMarc
Le 13 mai 2017 12:32:33 GMT+02:00, "José Abílio Matos" a
écrit :
>On Saturday, 13 May 2017 10.50.10 WEST Stephan Witt wrote:
>> Yes, I put in in. (And you luckily hit a Friday to place your smiley
>)
>
>That
e footsteps, some of the other parents said
> that never saw them not smiling in the morning. That is obviously an
> exaggeration but the point remains. :-)
>
>> I’m not so easy with your proposal to remove the error handler.
>> I think we have a real problem here: the en
ing. That is obviously an
exaggeration but the point remains. :-)
> I’m not so easy with your proposal to remove the error handler.
> I think we have a real problem here: the encoding of the path names
> in preferences is undefined if I’m not mistaken.
I understand and share your con
)
I’m not so easy with your proposal to remove the error handler.
I think we have a real problem here: the encoding of the path names
in preferences is undefined if I’m not mistaken.
Of course we have to fix it in some way - but I don’t know enough
of python (obviously) to make the r
Le 10/05/2017 à 07:11, Stephan Witt a écrit :
On Mac the preferences are in a separate directory for every major release too.
2014 I added the feature to create a copy of previous major releases
automatically if they’re present as first step of the configure process. Not
all developers were
On Thursday, 11 May 2017 14.26.37 WEST Jürgen Spitzmüller wrote:
> 2017-05-11 12:51 GMT+02:00 José Abílio Matos :
> > I will look into this problem if we have a bug report for it and a simple
> > example file.
>
> http://www.lyx.org/trac/ticket/10660
>
> Jürgen
>
> > --
> > José Abílio
Thank yo
2017-05-11 12:51 GMT+02:00 José Abílio Matos :
> I will look into this problem if we have a bug report for it and a simple
> example file.
>
http://www.lyx.org/trac/ticket/10660
Jürgen
> --
> José Abílio
>
On Tuesday, 9 May 2017 12.08.31 WEST Jürgen Spitzmüller wrote:
> We (José and Enrico) fixed a similar problem with encodings in layouts in
> lyx2lyx, so I suppose prefs2prefs can be fixed as well.
>
> Jürgen
I agree with your point of view. :-)
OTOH the difference between lyx2lyx and prefs2prefs
Am 10.05.2017 um 02:27 schrieb Uwe Stöhr :
>
> El 08.05.2017 a las 16:42, Scott Kostyshak escribió:
>
>> On Mon, May 08, 2017 at 06:39:38PM +1200, Andrew Parsloe wrote:
>
>>> alpha1-1 installed on windows 7. I can't remember if preferences are
>>&g
El 08.05.2017 a las 16:42, Scott Kostyshak escribió:
On Mon, May 08, 2017 at 06:39:38PM +1200, Andrew Parsloe wrote:
alpha1-1 installed on windows 7. I can't remember if preferences are
supposed to migrate on a major release.
They won't be migrated. The idea is to be able to
2017-05-09 13:03 GMT+02:00 Scott Kostyshak:
> Nice work! I have no idea how to improve our read of different
> encodings. I'm guessing this issue is not so rare for users who manually
> edit the preferences files with various text editors that for some
> reason do not preserve
guessing this issue is not so rare for users who manually
edit the preferences files with various text editors that for some
reason do not preserve encodings. If you happen to have your old
preferences file, or can recreate the situation, you might want to post
a bug report with a small preferences file.
Scott
signature.asc
Description: PGP signature
On 9/05/2017 2:42 a.m., Scott Kostyshak wrote:
On Mon, May 08, 2017 at 06:39:38PM +1200, Andrew Parsloe wrote:
alpha1-1 installed on windows 7. I can't remember if preferences are
supposed to migrate on a major release. They didn't. I renamed my LyX2.2
folder LyX2.3 and then had t
On Mon, May 08, 2017 at 06:39:38PM +1200, Andrew Parsloe wrote:
> alpha1-1 installed on windows 7. I can't remember if preferences are
> supposed to migrate on a major release. They didn't. I renamed my LyX2.2
> folder LyX2.3 and then had to manually increment the format number
alpha1-1 installed on windows 7. I can't remember if preferences are
supposed to migrate on a major release. They didn't. I renamed my LyX2.2
folder LyX2.3 and then had to manually increment the format numbers of
the files in bind and ui.
Andrew
---
This email has been checked for
header to define the new
currentZoom variable. Any recommendations?
- It will be saved via QSettings (highest hirachy). The alternative to
save it to the preferences does not seem right since preferences are
normally only saved when the settings are manually saved. However, the
currentZoom should be
Am Freitag, 21. April 2017 um 11:28:12, schrieb Stephan Witt
> commit a91402dc64cb6c73b355465ec11868cf1d0a443d
> Author: Stephan Witt
> Date: Tue Apr 18 09:32:22 2017 +0200
>
> use examples folder setting from preferences
> ---
> src/frontends/qt4/GuiView.cpp | 10
Am 23.01.2017 um 15:06 schrieb Guenter Milde :
>
> On 2017-01-22, Stephan Witt wrote:
>> Am 11.01.2017 um 21:57 schrieb Guenter Milde :
>
>>> I added some X-Apps just behind their anchestors (GNOME equivalents) to
>>> configure.py.
>
> ...
>
>> What if some command in this list does different t
On 2017-01-22, Stephan Witt wrote:
> Am 11.01.2017 um 21:57 schrieb Guenter Milde :
>> I added some X-Apps just behind their anchestors (GNOME equivalents) to
>> configure.py.
...
> What if some command in this list does different things on different
> platforms?
In case of a program name belon
Am 11.01.2017 um 21:57 schrieb Guenter Milde :
>
> Dear LyX developers,
>
> I added some X-Apps just behind their anchestors (GNOME equivalents) to
> configure.py.
>
> However, there are open points from the discussion:
>
> On 2017-01-08, Paul A. Rubin wrote:
>
>> My default text editor would
On 01/11/2017 04:46 PM, Paul A. Rubin wrote:
> On 01/11/2017 03:57 PM, Guenter Milde wrote:
>>
>> I propose to place "notepad" at the end of the text editor selection
>> list:
>>
>> checkViewerEditor('a text editor',
>> ['xemacs', 'gvim', 'kedit', 'kwrite', 'kate',
>> - 'ned
On 01/11/2017 03:57 PM, Guenter Milde wrote:
I propose to place "notepad" at the end of the text editor selection list:
checkViewerEditor('a text editor',
['xemacs', 'gvim', 'kedit', 'kwrite', 'kate',
- 'nedit', 'gedit', 'notepad',
- 'geany', 'leafpad', 'mousepad
Dear LyX developers,
I added some X-Apps just behind their anchestors (GNOME equivalents) to
configure.py.
However, there are open points from the discussion:
On 2017-01-08, Paul A. Rubin wrote:
> My default text editor would be
> notepad, which would require running the Wine emulator.
I pro
On Fri, Dec 02, 2016 at 07:01:51PM +0100, Kornel Benko wrote:
> Like the attached. (prefTest.pl.in goes into lib/scripts, executable flags
> should be set)
I just took a quick look, but it looks good to me. Thanks for working on
this.
Scott
signature.asc
Description: PGP signature
refTest.pl ...
> > # ctest ... (this is the same as prefTest.pl with previous params)
> > # ctest ...
> > ...
> > # prefTest.pl (with new values)
> > # ctest ...
>
> Ah I see. So by default we would configure CMake to automatically run
>
; # ctest ...
> ...
> # prefTest.pl (with new values)
> # ctest ...
Ah I see. So by default we would configure CMake to automatically run
prefTest.pl to point to the preferences file that allows knitr to run
without error. So we would still be able to do:
cmake
make
cte
On Wed, Nov 30, 2016 at 04:21:52PM +0100, Tommaso Cucinotta wrote:
> On 30/11/2016 11:12, Kornel Benko wrote:
> > Am Mittwoch, 30. November 2016 um 00:06:59, schrieb Scott Kostyshak
> >
> > > Do we currently have a way of specifying preferences when running
> > >
On 30/11/2016 11:12, Kornel Benko wrote:
Am Mittwoch, 30. November 2016 um 00:06:59, schrieb Scott Kostyshak
Do we currently have a way of specifying preferences when running
ctests? I think after Tommaso's security improvements, we need to put
the following in the Testing/.lyx/prefer
all
> > tests ATM.
> > Think how to use different dirs needs to recreate also their contents.
>
> Ah I did not think about this problem.
>
> > Right, we don't have it yet.
> > One way would be to prepare the preferences _before_ starting ctest.
> > For
tents.
Ah I did not think about this problem.
> Right, we don't have it yet.
> One way would be to prepare the preferences _before_ starting ctest.
> For instance with a perl script passing unused parameters to ctest?
>
> #prefTest.pl preferences=xyz -L export
> Start
Am Mittwoch, 30. November 2016 um 00:06:59, schrieb Scott Kostyshak
> Do we currently have a way of specifying preferences when running
> ctests? I think after Tommaso's security improvements, we need to put
> the following in the Testing/.lyx/preferences:
>
> \use_converte
Do we currently have a way of specifying preferences when running
ctests? I think after Tommaso's security improvements, we need to put
the following in the Testing/.lyx/preferences:
\use_converter_needauth_forbidden false
\use_converter_needauth false
It might also be nice to have an eas
variable. Any recommendations?
- It will be saved via QSettings (highest hirachy). The alternative to
save it to the preferences does not seem right since preferences are
normally only saved when the settings are manually saved. However, the
currentZoom should be saved whenever LyX is quit.
- Basically
be saved via QSettings (highest hirachy). The alternative to
save it to the preferences does not seem right since preferences are
normally only saved when the settings are manually saved. However, the
currentZoom should be saved whenever LyX is quit.
- Basically this variable is needed everywhere
hirachy). The alternative to
save it to the preferences does not seem right since preferences are
normally only saved when the settings are manually saved. However, the
currentZoom should be saved whenever LyX is quit.
- Basically this variable is needed everywhere where now there is
lyxrc.zoom
Am 24.01.2016 um 22:02 schrieb Georg Baum:
It is not new. It has been there since at least 15 years, but the UI was in
the printing tab before http://www.lyx.org/trac/changeset/3c2b3e69/lyxgit.
Many thanks! I am good at searching but not in finding ;-)
I updated the docs accordingly.
regards
Uwe Stöhr wrote:
> While updating the UserGuide I noticed a new preferences setting under
> Outputs->General
>
> "DVI-PS Options"
>
> What feature of LyX is using this and where can I find a list of
> possible options?
These are options passed to dvip
Am 19.01.2016 um 02:34 schrieb Uwe Stöhr:
Ping!
While updating the UserGuide I noticed a new preferences setting under
Outputs->General
"DVI-PS Options"
What feature of LyX is using this and where can I find a list of
possible options?
This new feature should be added to
http:/
While updating the UserGuide I noticed a new preferences setting under
Outputs->General
"DVI-PS Options"
What feature of LyX is using this and where can I find a list of
possible options?
This new feature should be added to
http://wiki.lyx.org/LyX/NewInLyX22
if possible.
thank
Guillaume Munch wrote:
> We could leave this aside for the moment no? Are you afraid that it would
> cast the situation in stone and somebody who comes up with a good solution
> won't be able to implement it anymore?
I was just sharing my thoughts.
Pavel
Le 30/11/2015 01:15, Pavel Sanda a écrit :
Guillaume Munch wrote:
You describe a method for this, above, but to me it sounds like a
cumbersome way to force-record the state of an inset (for instance, it
I agree it is cumbersome, my reasoning was that I would rather impose this
complexity on us
Guillaume Munch wrote:
> You describe a method for this, above, but to me it sounds like a
> cumbersome way to force-record the state of an inset (for instance, it
I agree it is cumbersome, my reasoning was that I would rather impose this
complexity on user who is using git & CT than complicating
not store user preferences in the file"
(store-preferences for short). However, I feel that it still requires
some reflection about giving the user the possibility of force-saving
the open/closed status, and provide feedback about this state. It is a
needed functionality, because otherwise if w
have another candidate here as well - not storing opening/closing
>> insets.
>
> So essentially a single setting for all user-like document settings.
>
> You had convinced me with your "open/closed inset" point that actually LyX
> records more than I previously
d so far can also be a problem without VCS, so I think
solving
them on a case by case basis helps more users.
To be clearer, I did not literally mean a "git mode". Rather, a "do not
write user preferences to file" per-document setting similarly to
LibreOffice. I would rather avoid
mode, in which case it would be good to add
>>> the setting before 2.2, even if it does not encompass everything right
>>> from the start. Either suit me; it's a matter of LyX's philosophy as
>>> per
>>> my other message.
>>
>> I am not sure wheth
more users.
To be clearer, I did not literally mean a "git mode". Rather, a "do not
write user preferences to file" per-document setting similarly to
LibreOffice. I would rather avoid a catch-all option whose effect is
unclear to the user.
Ping me if you finall
Guillaume Munch wrote:
> Le 08/11/2015 16:16, Georg Baum a écrit :
>>
>> If I understood Vincent correctly then it would not be a file format
>> change IMHO:
>>
>> As I understood it, he referred to the suggestion that the "track
>> changes" button would be decoupled from \track_changes in the fil
Le 08/11/2015 16:16, Georg Baum a écrit :
Richard Heck wrote:
On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:
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 stil
I have another candidate here as well - not storing opening/closing insets.
So essentially a single setting for all user-like document settings.
You had convinced me with your "open/closed inset" point that actually
LyX records more than I previously thought the current state of user
p
On 2015-11-07, Pavel Sanda wrote:
> Guillaume Munch wrote:
>> 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 b
On 11/08/2015 11:16 AM, Georg Baum wrote:
Richard Heck wrote:
On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:
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
Richard Heck wrote:
> On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:
>>
>> 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
>> min
Le 07/11/2015 22:17, Richard Heck a écrit :
On 11/07/2015 04:46 PM, Jean-Marc Lasgouttes wrote:
Le 7 novembre 2015 02:02:27 GMT+01:00, Guillaume Munch a
écrit :
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 t
On 11/07/2015 04:46 PM, Jean-Marc Lasgouttes wrote:
Le 7 novembre 2015 02:02:27 GMT+01:00, Guillaume Munch a écrit :
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 releasin
On 11/07/2015 12:36 AM, Vincent van Ravesteijn wrote:
> 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
> controversa
Le 7 novembre 2015 02:02:27 GMT+01:00, Guillaume Munch a écrit :
>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
Guillaume Munch wrote:
> 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, pe
> 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 potenti
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
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
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 th
thing 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
>> preferen
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
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
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 i
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
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
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
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
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 p
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,
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 i
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.
Not sure I am following what you propose.
under_version_control is related to our VCS mach
Op 6 nov. 2015 05:44 schreef "Pavel Sanda" :
>
> 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
>
1 - 100 of 681 matches
Mail list logo
