Pavel Sanda wrote:
> i must admit of having no idea what Abdel was refering to. but its true
> that i do changes in default.ui which change is still correctly detected
> after your patch.
OK, then I backport.
Jürgen
Jürgen Spitzmüller wrote:
> Abdel told me he introduced the reset because "some people (Pavel among them
> IIRC) complained that they want their hand-made changes to the ui file WRT to
> default windows and toolbars position to not be ignored".
>
> Since you seem to be among those, could you try
Pavel Sanda wrote:
> > Did you also check whether the original problem (for which Abdel added
> > the method) came back?
>
> no. what should i try? if you mean touching stdtoolbars.inc, nothing is
> reseted.
Abdel told me he introduced the reset because "some people (Pavel among them
IIRC) compla
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > > Pavel, please test and report back, then I'll backport.
> >
> > works here. thanks for fixing this.
>
> Did you also check whether the original problem (for which Abdel added the
> method) came back?
no. what should i try? if you mean touching
Pavel Sanda wrote:
> > Pavel, please test and report back, then I'll backport.
>
> works here. thanks for fixing this.
Did you also check whether the original problem (for which Abdel added the
method) came back?
Jürgen
Jürgen Spitzmüller wrote:
> I've commited to trunk.
>
> Pavel, please test and report back, then I'll backport.
works here. thanks for fixing this.
pavel
Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes writes:
> >> In the default setting, this is the file default.ui, which is
> >> changed rather seldomly.
> >
> > Should work. Good idea.
>
> +1
I've commited to trunk.
Pavel, please test and report back, then I'll backport.
Jürgen
Abdelrazak Younes writes:
>> In the default setting, this is the file default.ui, which is
>> changed rather seldomly.
>
> Should work. Good idea.
+1
JMarc
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
You mean parsing the files at every startup or preference change and
comparing the parsed value and the default saved value each time?
Attached is an alternative approach. Since we parse the files anyway in
readUIFile, we can just rem
Abdelrazak Younes wrote:
> For the ui toolbar and menu definitions yes. But not for everthing else
> related to geometry and/or visibility settings.
that woul be bad...
pavel
Abdelrazak Younes wrote:
> You mean parsing the files at every startup or preference change and
> comparing the parsed value and the default saved value each time?
Attached is an alternative approach. Since we parse the files anyway in
readUIFile, we can just remember which of the files has the c
Pavel Sanda wrote:
Abdelrazak Younes wrote:
You mean parsing the files at every startup or preference change and
comparing the parsed value and the default saved value each time? Yes that
would be an option indeed. But that would mean that we save the default
values along the current ones.
Abdelrazak Younes wrote:
> You mean parsing the files at every startup or preference change and
> comparing the parsed value and the default saved value each time? Yes that
> would be an option indeed. But that would mean that we save the default
> values along the current ones. As if we do that
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
In this case nothing. The problem is mainly on toolbar settings AFAIR.
So the easy solution is to remove "stdcontext.inc" and other files from
the test in the uifiles loop. You cannot ignore all include file because
the user may have defined
Abdelrazak Younes wrote:
> In this case nothing. The problem is mainly on toolbar settings AFAIR.
> So the easy solution is to remove "stdcontext.inc" and other files from
> the test in the uifiles loop. You cannot ignore all include file because
> the user may have defined a specific name for his
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
AFAIR some people (Pavel among them IIRC) complained that they want
their hand-made changes to the ui file WRT to default windows and
toolbars position to not be ignored. The best solution would be to have
these default values in a QSettings
Abdelrazak Younes wrote:
> AFAIR some people (Pavel among them IIRC) complained that they want
> their hand-made changes to the ui file WRT to default windows and
> toolbars position to not be ignored. The best solution would be to have
> these default values in a QSettings based class which the us
Abdelrazak Younes wrote:
> So the question now is why are these file touched at all? If you don't
> touch it by hand which program does it? Maybe it's a problem of "make
> install"?
touching any ui files happens quite regularly in trunk, thats why the
reset is done regularly too. maybe to enable
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
I found a recipe which lets me reproduce the toolbar problem reliably:
Just touch any of the ui files (e.g. stdcontext.inc). After the next
restart, the toolbar settings are lost.
good detective work :)
And some luck :-)
The reason
Pavel Sanda wrote:
> > I found a recipe which lets me reproduce the toolbar problem reliably:
> > Just touch any of the ui files (e.g. stdcontext.inc). After the next
> > restart, the toolbar settings are lost.
>
> good detective work :)
And some luck :-)
The reason for this specific behaviour r
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > i need to reestablish my settings every other day in trunk which version
> > doesn't change at all. i thought that touch configure.py && make do the
> > trick but no, something more is needed it seems.
>
> I found a recipe which lets me reproduce
Pavel Sanda wrote:
> i need to reestablish my settings every other day in trunk which version
> doesn't change at all. i thought that touch configure.py && make do the
> trick but no, something more is needed it seems.
I found a recipe which lets me reproduce the toolbar problem reliably:
Just to
Jürgen Spitzmüller wrote:
I believe one cause of the problems we have with settings that get lost after
reconfigure is the following:
The settings are saved by Qt in a config file that is named from the LyX
version. Thus we get a new, empty config file after every version change, and
thus the
Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > I believe one cause of the problems we have with settings that get lost
> > after reconfigure is the following:
>
> nothing against this patch, but i think the root of the problems is
> elsewhere;
I believe the problem has multiple causes. This is
Jürgen Spitzmüller wrote:
> I believe one cause of the problems we have with settings that get lost after
> reconfigure is the following:
nothing against this patch, but i think the root of the problems is elsewhere;
i need to reestablish my settings every other day in trunk which version
doesn'
Le 28 juin 09 à 15:37, Jürgen Spitzmüller a écrit :
I think it would make more sense to use the PACKAGE variable, i.e.
lyx[-version-suffix], as a config file name. Then session parameters
would
persist over minor and even major version changes, and one still
would have
separated configuration
I believe one cause of the problems we have with settings that get lost after
reconfigure is the following:
The settings are saved by Qt in a config file that is named from the LyX
version. Thus we get a new, empty config file after every version change, and
thus the toolbar changes etc. are l
27 matches
Mail list logo
