> Sure, how's this?
> http://www.lyx.org/trac/attachment/ticket/6043/multimediakeys3.diff
I verified that this patch also works on trunk.
Multimedia keys do work in Document - Settings, and Tools -
Preferences, but don't work in File - Open. I wonder if I missed a
QKeyEvent somewhere. However,
On Tue, Jun 30, 2009 at 8:07 PM, Ben M. wrote:
> Well, almost. Is there a good reason automake 1.11 isn't supported?
Nice changeset.
> On Tue, Jun 30, 2009 at 6:04 PM, Enrico Forestieri wrote:
>> As regards the extra cygwin stuff, I am going to commit something
>> to development/cygwin, such tha
On Tue, Jun 30, 2009 at 6:04 PM, Enrico Forestieri wrote:
> Note that those three lines are actually what is necessary to compile
> and install LyX provided that 1) you set the QT4DIR environment variable
> to the directory where you installed Qt4, and 2) you use the gcc3 compiler.
Well, almost.
On Wed, Jul 01, 2009 at 01:28:49AM +0200, for...@lyx.org wrote:
> Author: forenr
> Date: Wed Jul 1 01:28:48 2009
> New Revision: 30327
> URL: http://www.lyx.org/trac/changeset/30327
>
> Log:
> Add some cygwin stuff.
>
> Added:
>lyx-devel/trunk/development/cygwin/ (props changed)
>lyx-d
On Mon, Jun 29, 2009 at 11:39:03PM -0400, Ben M. wrote:
> On Mon, Jun 29, 2009 at 11:14 AM, Enrico Forestieri wrote:
> > Would you be interested in maintaining the official LyX/Cygwin package?
>
> I'm honored by your recommendation. I'm interested in helping to
> automate the maintenance of LyX/C
On Tue, Jun 30, 2009 at 5:12 AM, Jean-Marc Lasgouttes wrote:
> What I would like (but I have not understood yet where to do that) is to
> use reject() only when we have an unknown keysym. We should not reject
> events because M-C-j is not bound currently, but because a given
> multimedia key is not
Hi Vincent, hi Pavel,
as a user with high interest in mouseless working I would greatly
appreciate an lfun of that kind useable in some form also for me as user
;-))
That would increase my produtivity with LyX one more important step.
Apart from some rare exceptions in my commercial context, L
Pavel Sanda wrote:
> there is hard to get any consensus on those issues and thats why we have
> "limit text width" checkbox in preferences which you are probably not
> aware of.
> pavel
No Thanks, it is all I need !
Sorry for the noise.
Charles
--
http://www.kde-france.org
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
Charles de Miramon wrote:
> If there is consensus on this wish, I'll file an enhencement request in
> Trac.
there is hard to get any consensus on those issues and thats why we have
"limit text width" checkbox in preferences which you are probably not
aware of.
pavel
Jean-Marc Lasgouttes wrote:
> Therefore I would use something like
> (env.has_key('assertions') and env['assertions']) or (!
> env.has_key('assertions') and mode == 'debug') (assuming the code above is
> working python and env.has_key tells me about command line options.
Good question. I'm not s
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
Jürgen Spitzmüller writes:
> I think assertions should always be disabled if the build_mode is "release".
> Until now, they were only disabled if the version contained no "svn" tag
> (i.e., devel_version == False). So if you wanted to use the 1.6.4svn branch
> with disabled assertions, you coul
Hello,
I have updated to 1.6.3 and the full screen mode works much better. Thanks
for the work.
But after working a full day in full screen mode on an 17" monitor my eyes
were strained because lines of text are much too wide if you cannot resize
the window.
Fullscreen wordprocessors tend to d
Uwe Stöhr wrote:
> > So LyX crashes on windows even though assertions are disabled. I have
> > tested SCons on Linux, and I get no crash with the same settings. So
> > maybe MSVC is to blame?
>
> It seems so indeed.
Can you try the attached?
Jürgen
Index: src/support/lassert.cpp
=
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
Jean-Marc Lasgouttes wrote:
> > The attached patch is needed nevertheless. It disabled assertions for me
> > with mode=release. Jean-Marc, does it make sense?
>
> Well, I tried to understand how SConstruct works when you posted thqt on
> trac, but I failed. Could you describe in a few words what yo
Vincent van Ravesteijn wrote:
> - Do we really want an lfun that cannot be used by the user as he will not
> know the necessary paragraph-ids ?
actually we already have such lfuns. the fact that it is not to be used by users
is done by simply avoiding string identifier.
pavel
diff --git a/src/Ly
Kenneth Gilbert writes:
> Here is my request: Make it possible to better format the export to
> latex. Right now things like \begin{equation} are not always set off
> on separate lines. That is equations are often written as part of the
> text, which makes the exported latex harder to read. When
Jürgen Spitzmüller writes:
> The attached patch is needed nevertheless. It disabled assertions for me with
> mode=release. Jean-Marc, does it make sense?
Well, I tried to understand how SConstruct works when you posted thqt on
trac, but I failed. Could you describe in a few words what you do?
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
Jürgen Spitzmüller schrieb:
So LyX crashes on windows even though assertions are disabled. I have tested
SCons on Linux, and I get no crash with the same settings. So maybe MSVC is to
blame?
It seems so indeed.
regards Uwe
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
Uwe Stöhr wrote:
> No, but I have this in the config.h for boost.
I thin the file in boost is the relevant one here.
> There are two config.h files, one for src and one for boost. Both are
> attached.
>
> ENABLE_ASSERTIONS is not defined anywhere.
So LyX crashes on windows even though assertions
Jean-Marc Lasgouttes writes:
> What I would like (but I have not understood yet where to do that) is to
> use reject() only when we have an unknown keysym. We should not reject
ignore()
> events because M-C-j is not bound currently, but because a given
> multimedia key is not handled by
Jean-Marc Lasgouttes schrieb:
And do you have the following at the end of config.h?
#if !defined(ENABLE_ASSERTIONS)
# define BOOST_DISABLE_ASSERTS 1
#endif
#define BOOST_ENABLE_ASSERT_HANDLER 1
No, but I have this in the config.h for boost.
There are two config.h files, one for src and one
"Ben M." writes:
> According to
> http://doc.trolltech.com/3.3/qkeyevent.html#details
> "Key events for multi media keys are ignored by default. You should
> call QKeyEvent::accept() if your widget handles those events."
Very good detective work (although you should point to the 4.2
documentati
Uwe Stöhr writes:
> The generated config.h doesn't contain a statement for
>
> ENABLE_ASSERTIONS
>
> So I guess that assertions are not enabled.
And do you have the following at the end of config.h?
#if !defined(ENABLE_ASSERTIONS)
# define BOOST_DISABLE_ASSERTS 1
#endif
#define BOOST_ENABLE_ASS
Uwe Stöhr wrote:
> The generated config.h doesn't contain a statement for
>
> ENABLE_ASSERTIONS
>
> So I guess that assertions are not enabled.
Could you post that file, please?
Jürgen
Jürgen Spitzmüller schrieb:
and ENABLE_ASSERTIONS is really commented out in the config.h file that is
generated by SCons?
The generated config.h doesn't contain a statement for
ENABLE_ASSERTIONS
So I guess that assertions are not enabled.
regards Uwe
Abdelrazak Younes writes:
>> In the default setting, this is the file default.ui, which is
>> changed rather seldomly.
>
> Should work. Good idea.
+1
JMarc
Uwe Stöhr wrote:
> > What console output?
>
> D:\LyXSVN\LyX1.6.x\src\support\lassert.cpp(21): ASSERTION anchor_.depth()
> >= depth() VIOLATED IN D:\LyXSVN\LyX1.6.x\src\Cursor.cpp:928
and ENABLE_ASSERTIONS is really commented out in the config.h file that is
generated by SCons?
Jürgen
LyX Ticket Tracker schrieb:
What console output?
D:\LyXSVN\LyX1.6.x\src\support\lassert.cpp(21): ASSERTION anchor_.depth() >= depth() VIOLATED IN
D:\LyXSVN\LyX1.6.x\src\Cursor.cpp:928
regards Uwe
35 matches
Mail list logo
