Hi!
Maybe that was discussed before... I was wondering about those ugly
parenthesis in LyX formulas. While text is nicely antialiased
nowadays all hand drawn math objects are not. Qt has a "renderhint"
for antialiasing (see http://doc.trolltech.com/4.2/
qpainter.html#RenderHint-enum). Turn
Richard Heck wrote:
OK, now I've learned about mutable. This seems to be a better patch for
3109. Comments
requested before I commit.
This one is better ;-)
The issue was that the newcolors_ were being checked against prefcolors_
to make sure the color had changed, but prefcolors_ contained
Anders Ekberg a écrit :
On 27 mar 2007, at 21.13, Bennett Helm wrote:
On Mar 27, 2007, at 2:50 PM, Anders Ekberg wrote:
I am trying to compile the svn version of LyX with QT4.3beta on Mac
PPC (OS X 10.4.8). During the configuration phase the qt-library is
not detected (using the configuratio
On 3/28/07, Bo Peng <[EMAIL PROTECTED]> wrote:
Most people dislike the current bookmark behavior so I have restored
the old one. Please test.
BTW, I changed a shortcut in aqua.bind so the maintainer of this file
should have a look.
Cheers,
Bo
Most people dislike the current bookmark behavior so I have restored
the old one. Please test.
Comparing to lyx-1.4.x,
1. add menu item bookmark clear
2. only display valid bookmark-goto, in the form of idx: filename
3. shortcuts allow bookmark-save 1-9 and bookmark-goto 1-9.
4. bookmark-goto is
OK, now I've learned about mutable. This seems to be a better patch for
3109. Comments
requested before I commit.
The issue was that the newcolors_ were being checked against prefcolors_
to make sure the color had changed, but prefcolors_ contained the colors
from the preferences file and was not
The attached patch addresses bug 3109: Preferences do not take effect
immediately. Comments requested before I commit.
The issue was that the newcolors_ were being checked against prefcolors_
to make sure the color had changed, but prefcolors_ contained the colors
from the preferences file and wa
On Wednesday 28 March 2007 8:01:18 pm Andre Poenitz wrote:
> Sure, and there's nothing wrong with that. It's just that the rpms not
> necessarily have to be build from the srpm as long as the result is the
> same. Even in C++ there is the "as-if" rule...
And you apply them in the same machine yo
On Wed, Mar 28, 2007 at 11:33:32PM +0200, Peter Kümmel wrote:
> perl on windows would be hard.
Perl works just fine on Windows, and this can be redone in Python or
even C++.
Andre'
Andre Poenitz wrote:
> On Wed, Mar 28, 2007 at 09:26:38PM +0200, Peter Kümmel wrote:
>> Andre Poenitz wrote:
>>> On Tue, Mar 27, 2007 at 08:31:33PM +0200, Peter Kümmel wrote:
OK, I've committed.
>>> Incidently,
>>>
>>> if(release)
>>> - set(CMAKE_BUILD_TYPE Release)
>>> + set(CMAK
On Wed, Mar 28, 2007 at 09:34:01PM +0200, Peter Kümmel wrote:
> Here other ideas to reduce the compile time:
>
> http://lists.kde.org/?l=kde-core-devel&m=117507518026184&w=2
I use 'make foo.o && make' regularily.
Andre'
On Wed, Mar 28, 2007 at 03:27:03PM -0400, Richard Heck wrote:
>
> So what, if anything, do we all need to do to get fast builds out of this?
I am afraid this is still not ready for "public" use.
Andre'
On Wed, Mar 28, 2007 at 09:26:38PM +0200, Peter Kümmel wrote:
> Andre Poenitz wrote:
> > On Tue, Mar 27, 2007 at 08:31:33PM +0200, Peter Kümmel wrote:
> >> OK, I've committed.
> >
> > Incidently,
> >
> > if(release)
> > - set(CMAKE_BUILD_TYPE Release)
> > + set(CMAKE_BUILD_TYPE Relea
Michael Gerz wrote:
Abdelrazak Younes schrieb:
Michael Gerz wrote:
Abdel,
when inserting a glossary entry or a URL, the input field in the
corresponding dialog doesn't get focus.
I remember that you fixed a similar problem with the find&replace
dialog. Could you please have a look?
Done.
Abdelrazak Younes schrieb:
Michael Gerz wrote:
Abdel,
when inserting a glossary entry or a URL, the input field in the
corresponding dialog doesn't get focus.
I remember that you fixed a similar problem with the find&replace
dialog. Could you please have a look?
Done.
Great!
Michael
Michael Gerz wrote:
Abdel,
when inserting a glossary entry or a URL, the input field in the
corresponding dialog doesn't get focus.
I remember that you fixed a similar problem with the find&replace
dialog. Could you please have a look?
Done.
Abdel.
Abdel,
when inserting a glossary entry or a URL, the input field in the
corresponding dialog doesn't get focus.
I remember that you fixed a similar problem with the find&replace
dialog. Could you please have a look?
Thanks in advance!!
Michael
Richard Heck wrote:
> So what, if anything, do we all need to do to get fast builds out of this?
Sorry, do you ask how to use cmake with this build trick enabled?
cmake ..\development\cmake -Dmerge=1 -Ddebug=1
>
> Peter Kümmel wrote:
>> Andre Poenitz wrote:
>>
>>> On Tue, Mar 27, 2007 at 08
Here other ideas to reduce the compile time:
http://lists.kde.org/?l=kde-core-devel&m=117507518026184&w=2
Peter
So what, if anything, do we all need to do to get fast builds out of this?
Peter Kümmel wrote:
> Andre Poenitz wrote:
>
>> On Tue, Mar 27, 2007 at 08:31:33PM +0200, Peter Kümmel wrote:
>>
>>> OK, I've committed.
>>>
>> Incidently,
>>
>> if(release)
>> - set(CMAKE_BUILD_TYPE
Andre Poenitz wrote:
> On Tue, Mar 27, 2007 at 08:31:33PM +0200, Peter Kümmel wrote:
>> OK, I've committed.
>
> Incidently,
>
> if(release)
> - set(CMAKE_BUILD_TYPE Release)
> + set(CMAKE_BUILD_TYPE Release CACHE TYPE STRING FORCE)
> set(release)
> endif(release)
> if(debug
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > But your want the srpm anyway...
|
| Sure, and there's nothing wrong with that. It's just that the rpms not
| necessarily have to be build from the srpm as long as the result is the
| same. Even in C++ there is the "as-if" rule...
But you have to do
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Mar 27, 2007 at 07:24:36PM +0100, José Matos wrote:
| > On Monday 26 March 2007 4:47:24 pm Andre Poenitz wrote:
| > >
| > > There is no need for an srpm when building an rpm. One can
| > > put arbitrary files in the %files section of the spec fil
On Wed, Mar 28, 2007 at 08:55:28PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Mon, Mar 26, 2007 at 03:54:17PM +0100, José Matos wrote:
> | > On Monday 26 March 2007 3:43:42 pm Andre Poenitz wrote:
> | > > Quick full build is btw what is needed for the rp
José Matos <[EMAIL PROTECTED]> writes:
| On Monday 26 March 2007 4:47:24 pm Andre Poenitz wrote:
| >
| > There is no need for an srpm when building an rpm. One can
| > put arbitrary files in the %files section of the spec file,
| > including binaries.
|
| So you are proposing to package the fin
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Mar 26, 2007 at 03:54:17PM +0100, José Matos wrote:
| > On Monday 26 March 2007 3:43:42 pm Andre Poenitz wrote:
| > > Quick full build is btw what is needed for the rpmdist target
| >
| > I agree.
| >
| > > [If we stick to the "pristine sourc
Andre Poenitz <[EMAIL PROTECTED]> writes:
| So _not_ using external symbols seems to be worth a try, too.
| Of course that'd mean 'static func()' instead of 'namespace { func() }'
| and that seems to be close blasphemy in this world as well...
Yes. And with the next version of gcc f.ex. anon name
On Tue, 27 Mar 2007, Bennett Helm wrote:
I am puzzled as to how a professor of Philosophy can program so well ;-)
Abdel.
Shall I take personal offense at that? ;)
Wow... this means there's (at least) two professors of philosophy among
the LyX developers!?!?
Some day when I actually have
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I see. But then it is kind of global property "singleton",
Andre> nothing that needs to be replicated in the "cosmetic cursors"
Andre> used e.g. for iteration.
Yes.
JMarc
On Wed, Mar 28, 2007 at 06:04:22PM +0200, Abdelrazak Younes wrote:
> Bernhard Roider wrote:
> >
> >Here it is
> >
> >For the log i think my comment from the original mail would be ok:
>
> OK, committed. Please close the bugzilla entry. If you don't have the
> right, please ask JMarc.
>
> Abdel.
On Wed, Mar 28, 2007 at 05:53:20PM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> I agree this would be the right thing to do. Or rather move the
> >> current font to the cursor.
>
> Andre> Why do we need to cache the current font at all? I
Bernhard Roider wrote:
Here it is
For the log i think my comment from the original mail would be ok:
OK, committed. Please close the bugzilla entry. If you don't have the
right, please ask JMarc.
Abdel.
PS: Same question as to Richard: where are you with SVN access? You two
guys are prod
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> It is not caching. If I select Emph, I change current_font_ (for
>> the next insertion), not anything in the paragraph (this is how I
>> understand it in any case).
Bo> So, setCurrentFont should be applied at each text cursor move, not
Bo> mous
It is not caching. If I select Emph, I change current_font_ (for the
next insertion), not anything in the paragraph (this is how I
understand it in any case).
So, setCurrentFont should be applied at each text cursor move, not
mouse move. Either we add a mouse-move-version of editXY, or separate
Richard Heck wrote:
The attached is intended to resolve bug 3246: "OK" button disabled when
selecting cross ref with keyboard. A similar problem affected the
TeXInfo dialog, and I have fixed that one, too. My fix is essentially
the same as in the Thesaurus dialog, which did not suffer from this
p
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> I agree this would be the right thing to do. Or rather move the
>> current font to the cursor.
Andre> Why do we need to cache the current font at all? I recreating
Andre> it so expensive?
It is not caching. If I select Emph, I change
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> As there is no reaction and Richard seems to be confident
Abdelrazak> enough, I've committed the patch. Richard, please close
Abdelrazak> the bugzilla entry.
Good. The only think I wonder about (as already said) is wh
The attached is intended to resolve bug 3246: "OK" button disabled when
selecting cross ref with keyboard. A similar problem affected the
TeXInfo dialog, and I have fixed that one, too. My fix is essentially
the same as in the Thesaurus dialog, which did not suffer from this
problem (though it cou
Jean-Pierre Chrétien wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Jean-Pierre Chrétien wrote:
I don't understand why bug:2529 and bug:2995 do not appear in
the list. These regressions are targeted to 1.4.x, is it the reason ?
[...]
Have you tried the beta 1? Maybe the situation is
Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
Bernhard Roider wrote:
Hello!
The crash happens on alt+up and alt+down if the position of the cursor
in the moved paragraph is beyond the length of the target paragraph.
To avoid it the Position of the iterators for the tar
As there is no reaction and Richard seems to be confident enough, I've
committed the patch. Richard, please close the bugzilla entry.
Abdel.
Abdelrazak Younes wrote:
Richard Heck wrote:
Index: text3.C
===
--- text3.C(revision
On Tue, Mar 27, 2007 at 08:31:33PM +0200, Peter Kümmel wrote:
> OK, I've committed.
Incidently,
if(release)
- set(CMAKE_BUILD_TYPE Release)
+ set(CMAKE_BUILD_TYPE Release CACHE TYPE STRING FORCE)
set(release)
endif(release)
if(debug)
- set(CMAKE_BUILD_TYPE Debug)
+
On Wed, Mar 28, 2007 at 09:06:43AM -0500, Bo Peng wrote:
> >I meant that changes of inset button behaviour looked straightforward
> >enough, but the devil is in the details.
>
> I plead guilty, but, :-)
>
> The devils lie in the fact that lyx kernel can not handle mouse
> movement well. The kerne
On Wed, Mar 28, 2007 at 10:53:08AM +0200, Jean-Marc Lasgouttes wrote:
> > "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
>
> Richard> I suppose that's possible, but the problem seems to me to be
> Richard> the opposite. The way the code was, editXY was being called
> Richard> in BufferV
On Tue, Mar 27, 2007 at 07:24:36PM +0100, José Matos wrote:
> On Monday 26 March 2007 4:47:24 pm Andre Poenitz wrote:
> >
> > There is no need for an srpm when building an rpm. One can
> > put arbitrary files in the %files section of the spec file,
> > including binaries.
>
> So you are proposin
I meant that changes of inset button behaviour looked straightforward
enough, but the devil is in the details.
I plead guilty, but, :-)
The devils lie in the fact that lyx kernel can not handle mouse
movement well. The kernel is designed around text cursor which is
deeply entangled with lyxtext
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>>
Georg> Yes, this is correct, although I would move the std::hex out of
Georg> the loop. Unfortunately I keep forgetting which modifiers are
Georg>
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> Yes, this is correct, although I would move the std::hex out of
> Georg> the loop. Unfortunately I keep forgetting which modifiers are
> Georg> permanent and which ones only affect the ne
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> - I did not keep the 0/1 value, because I do not think it is
>> useful.
Georg> IMHO it is. Otherwise it is not possible to "undefine" such a
Georg> feature that comes from a .inc file (this is used in
Georg> ijmpc.layout).
These uses ar
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>> Georg, does the following patch look right? Without it, all
>> integers are in hex in lyxerr output, which is a real pain.
Georg> Yes, this is correct, although I would move the std::hex out of
Georg> th
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> But we are adding yet another way to find insets,
Abdelrazak> I know but I want to get rid of the other ones (not now)
Abdelrazak> because they have nothing to do in the LyXText class. I
Abdelrazak> will add some comments to
Georg Baum wrote:
Abdelrazak Younes wrote:
Bernhard Roider wrote:
Hello!
The crash happens on alt+up and alt+down if the position of the cursor
in the moved paragraph is beyond the length of the target paragraph.
To avoid it the Position of the iterators for the target paragraph must
be corr
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>>> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
>>
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code was, editXY was
Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code was, editXY was being called
Richard> in BufferView::workAreaDispatch for the sole purpose of
Richard>
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code was, editXY was being called
Richard> in BufferView::workAreaDispatch for the sole purpose of
Richard> finding the deepest inset
Bernhard Roider wrote:
> A test here gives the same result. It seems that there is no other
> influence on the behavior of the file save dialog.
> I wonder what you led you to that change ;-)
It was introoduced recently, and there was a discusion on the list, it had
something to do with showing d
Abdelrazak Younes wrote:
> Bernhard Roider wrote:
>> Hello!
>>
>> The crash happens on alt+up and alt+down if the position of the cursor
>> in the moved paragraph is beyond the length of the target paragraph.
>>
>> To avoid it the Position of the iterators for the target paragraph must
>> be cor
Bernhard Roider wrote:
>> Yes. We need to convert all file tools to docstring. The only reason why
>> it has not happened so far is that we need the string versions in some
>> parts of the code that cannot be changed to docstring because of regexes
>> (some bibtex stuff).
>>
>
> Is it really nee
59 matches
Mail list logo
