Am Samstag 08 August 2009 schrieb Abdelrazak Younes:
> On 08/08/2009 19:18, Kornel Benko wrote:
> > Cannot compile.
>
> Sorry, should be fixed now.
It is.
And is working. And fast!
The path for dictionaries is the same as for thesaurus (on ubuntu).
> Thanks,
> Abdel.
Nice work.
But calling
On 08/08/2009 19:18, Kornel Benko wrote:
Cannot compile.
Sorry, should be fixed now.
Thanks,
Abdel.
Am Samstag 08 August 2009 schrieb you...@lyx.org:
> Author: younes
> Date: Sat Aug 8 19:05:31 2009
> New Revision: 30927
> URL: http://www.lyx.org/trac/changeset/30927
>
> Log:
> Minimal support for hunspell. Spellchecking works but not suggestion, at
> least on Win/MSVC.
Cannot compile.
...
/usr
On 08/08/2009 03:09 AM, Jürgen Spitzmüller wrote:
rgheck wrote:
This doesn't change functionality, so I'm figuring it doesn't need
status.16x.
I think something like
- Fix occasional wrong occurrence of theorem style (bug 6036).
would be appropriate.
Didn't know it had a numb
What were they trying to do here ? They know about the problem then if
they tinker with this ?
Vincent
http://qt.gitorious.org/+openbossa-developers/qt/openbossa-clone/commit/ffbb3c1a2aee4134dce80cd144a26bf32865b698?diffmode=sidebyside
Vincent
Andre Poenitz schreef:
On Sat, Aug 08, 2009 at 02:24:57PM +0200, Vincent van Ravesteijn wrote:
Andre Poenitz schreef:
On Sat, Aug 08, 2009 at 01:46:05PM +0200, Jürgen Spitzmüller wrote:
Vincent van Ravesteijn wrote:
That'd probably mean I'd have to start debugg
On Sat, Aug 08, 2009 at 02:24:57PM +0200, Vincent van Ravesteijn wrote:
> Andre Poenitz schreef:
>> On Sat, Aug 08, 2009 at 01:46:05PM +0200, Jürgen Spitzmüller wrote:
>>
>>> Vincent van Ravesteijn wrote:
>>>
That'd probably mean I'd have to start debugging Qt somehow, and find
ou
I forgot to say that I think that the current workaround should go to branch too for now since it
doesn't hardcode a certain value:
http://www.lyx.org/trac/changeset/30919
regards Uwe
Andre Poenitz schreef:
On Sat, Aug 08, 2009 at 01:46:05PM +0200, Jürgen Spitzmüller wrote:
Vincent van Ravesteijn wrote:
That'd probably mean I'd have to start debugging Qt somehow, and find
out the problem myself (but I don't want to).
I can understand that.
Other than t
On Sat, Aug 08, 2009 at 01:46:05PM +0200, Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn wrote:
> > That'd probably mean I'd have to start debugging Qt somehow, and find
> > out the problem myself (but I don't want to).
>
> I can understand that.
>
> > Other than that, I really don't have a c
> I would very much prefer if you could bring the issue to the list instead.
> I'll care about the status file if necessary.
OK, reverted my commit now.
regards Uwe
Uwe Stöhr wrote:
> As you noticed, the crash can occur with different scalings in combination
> with the image size, I guess also with 60 or 40%. Fixing one value out of
> hundred is therefore not the real solution (that doesn't mean that the
> current workaround should be removed).
Granted, but
> Also, the comment you removed still was valid: the crash was fixed for the
> scaling value "50%", the new testcase used "25%".
As you noticed, the crash can occur with different scalings in combination with the image size, I
guess also with 60 or 40%. Fixing one value out of hundred is therefo
Vincent van Ravesteijn wrote:
> You added some localization for the representation of lenghts in the
> gui, but this gives problems in the Graphics dialog. Sizes large than
> 1000 in pixels are now shown as 1,820x3,200.
> First, I even don't like to
> see the comma's, second it confuses me, third
Vincent van Ravesteijn wrote:
> That'd probably mean I'd have to start debugging Qt somehow, and find
> out the problem myself (but I don't want to).
I can understand that.
> Other than that, I really don't have a clue how to gain more info.
Hassle Qt?
Jürgen
There are already several reports about this, and not everybody is using
qt4.5 yet. Moreover, most people will use percentage like 50, 25% so we
have to do something and Qt is not in a hurry to confirm my bug report.
Yes, sure, we have to resolve this for 1.6.4. But instead of shooting in
Le 08/08/2009 09:29, Jürgen Spitzmüller a écrit :
Vincent van Ravesteijn wrote:
This fixes it (I hope),
Jean-Marc, can you onfirm this?
I'll tell you on monday
JMarc
Vincent van Ravesteijn wrote:
> I have no idea what surprises there may be. I could only reproduce the
> crash with 50% for somewhat larger sizes. Uwe had a very large figure
> and now it could be reproduced with 25%. Maybe next time someone comes
> with a figure that will crash with 20% and so for
Juergen,
You added some localization for the representation of lenghts in the
gui, but this gives problems in the Graphics dialog. Sizes large than
1000 in pixels are now shown as 1,820x3,200. First, I even don't like to
see the comma's, second it confuses me, third (the most important) the
v
To Vincent: Do we really need to alter every scale value? What happens, BTW,
if I use a scale value of 49.%?
I have no idea what surprises there may be. I could only reproduce the
crash with 50% for somewhat larger sizes. Uwe had a _very_ large figure
and now it could be reproduced with
Vincent van Ravesteijn wrote:
> This fixes it (I hope),
Jean-Marc, can you onfirm this?
Jürgen
Uwe Stöhr wrote:
> > Please don't start undoing someone's work. I can do it myself.
>
> Why are you grumpy? I haven't undone anything, I only removed the status16
> entry. This has been the usual way in the past when it appears that a bug
> is not fixed. This assures that it won't accidentally slip
rgheck wrote:
> This doesn't change functionality, so I'm figuring it doesn't need
> status.16x.
I think something like
- Fix occasional wrong occurrence of theorem style (bug 6036).
would be appropriate.
Jürgen
23 matches
Mail list logo
