On 10/26/07, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
> > I have tested your patch. I think the new feature you added (display
> > Alt ... if Alt is pressed) is useless
>
>
In the mean time, I do not really care.
> the important thing that i added is that now you can enter shortc
Bo Peng wrote:
I have tested your patch. I think the new feature you added (display
Alt ... if Alt is pressed) is useless
the important thing that i added is that now you can enter shortcuts
that are not taken by the dialog
, and I can not enter shortcuts
with more than one KeySymbol (e.g
> attached the latest version of the shortcut edit widget. it provides
> visual feedback when inputting, overrides shortcuts in the dialog (took
> me a lot of trial and error to figure this out. it works on windows but
> it would be nice if other people try it as well)
I have tested your patch. I
> Since we are at CustomizedWidgets.h: Is there a reason that this
> is not in namespace lyx::frontend.
Because the namespaces will cause trouble in the ui file. Maybe I used
the wrong method though.
> Also, the only _needed_ #include thre is QLineEdit.
At least QtCloseEvent is needed.
Bo
Am I right that with the recent changes to InsetIndex, GuiIndex is now
non-functional and could be removed?
rh
Only for information: http://thread.gmane.org/gmane.comp.tex.ctan.announce/6045
* listingsutf8 v1.0
Package `listings' does not support files with multi-byte
encodings such as UTF-8. In case of \lstinputlisting a simple
workaround is possible if an one-byte encoding exists that the file
> Pavel Sanda wrote:
>
> > well for the basic checks i usually see in Andre's syntax warnings we
> > really dont need any third party code. few lines of greping will do. as my
> > python skills are very limited i can write some set of tests in bash, but
> > that will unusable for ms folks.
>
> Wh
Juergen Spitzmueller schrieb:
3172 maj lyxsum doesn't work on Windows
(We need a Windows user for bug hunting)
fixed in trunk: http://www.lyx.org/trac/changeset/21211
The file must be opened in binary mode; otherwise the iteration of for_each
stops really early for binary files (e.g. after
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 04:47:17PM -0400, Richard Heck wrote:
vitual CommandInfo const * findInfo(std::string const & cmdName) = 0;
I didn't do that because it needs, at least in the base classes, to
be static, and I wanted to indicate here that it needed to
On Thu, Oct 25, 2007 at 04:47:17PM -0400, Richard Heck wrote:
> vitual CommandInfo const * findInfo(std::string const & cmdName) = 0;
> >>>I didn't do that because it needs, at least in the base classes, to
> >>>be static, and I wanted to indicate here that it needed to be
> >>>implemented as
Andre Poenitz wrote:
Ugh. So you are planning to reintroduce back pointers?
I am not sure about the whole thing.
If so, it would be something that wouldn't change during an inset's
lifetime, so it should be conceptionally simpler to handle than we had
we the inset parent.
But as I said
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 04:17:27PM +0200, Pavel Sanda wrote:
hi,
dont know whether this is according to last changesets or the fact i tried to
use monolithic compilation.
make[6]: Entering directory
`/home/installer/lyx/trunk_disable/src/frontends/qt4'
/bin/sh ../../..
Richard Heck wrote:
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 09:26:31AM -0400, Richard Heck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
+ /// Return parameter information for command cmdName.
+ /// Not implemented here. Must be implemented in derived class.
+ static CommandIn
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 09:26:31AM -0400, Richard Heck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
+/// Return parameter information for command cmdName.
+/// Not implemented here. Must be implemented in derived class.
+static Comman
Pavel Sanda wrote:
> well for the basic checks i usually see in Andre's syntax warnings we
> really dont need any third party code. few lines of greping will do. as my
> python skills are very limited i can write some set of tests in bash, but
> that will unusable for ms folks.
Why bother with sc
> > which brings me to the idea used in gentoo - before you commit some ebuild
> > into the tree you call the python beast called repoman, which out of other
> > things controls syntactic & whitespace violations of rules and spits on you
> > nice and colorful abuses :)
>
> I have tried this but th
On Mon, Oct 22, 2007 at 08:33:16AM +0200, Lars Gullik Bjønnes wrote:
> OTOH boost have a pretty good track record in this respect, quite a
> few of the boost libraries and boost initiated changes will be in the
> next version of the standard.
Speaking of boost and standardization:
Index: support
On Thu, Oct 25, 2007 at 12:18:51PM -0500, Bo Peng wrote:
> > ok, i'll have a look. thanks.
> >
> > (i still prefer the Shift+ style though...)
>
> Because ShortcutLineEdit keeps KeySequence, you can return it
> directly. Therefore, you do not have to use KeySequence::BindFile
> format to display t
Juergen Spitzmueller wrote:
Jean-Marc Lasgouttes wrote:
With other wordprocessors you can highlight text with a different
background. Isn't that something that we want to support?
First, I am not sure at all that there is a proper stable package for
doing that in LaTeX (colors are horrible in
Abdelrazak Younes wrote:
> So it seems rather easy, doesn't it?
Sort of. Soul has some limitations, and we need to test this carefully. For
instance, it doesn't work with utf8 (however, Heiko Oberdiek just released
a supplement package that fixes this particular issue).
Jürgen
> ok, i'll have a look. thanks.
>
> (i still prefer the Shift+ style though...)
Because ShortcutLineEdit keeps KeySequence, you can return it
directly. Therefore, you do not have to use KeySequence::BindFile
format to display them. (Change to KeySequence::Portable in line 1872
of GuiPrefs.cpp),
T
On Thu, Oct 25, 2007 at 09:26:31AM -0400, Richard Heck wrote:
> Abdelrazak Younes wrote:
> >[EMAIL PROTECTED] wrote:
> >>+/// Return parameter information for command cmdName.
> >>+/// Not implemented here. Must be implemented in derived class.
> >>+static CommandInfo const * findInfo(s
On Thu, Oct 25, 2007 at 10:13:56AM +0200, Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
> >Andre Poenitz wrote:
> >
> >>>That might be enough. But it's not clear to me if this causes problems
> >>>with cut and paste.
> >>Sure there will problems, but right now we already have special handlin
On Thu, Oct 25, 2007 at 12:41:06PM -, [EMAIL PROTECTED] wrote:
> URL:
> http://www.lyx.org/trac/file/lyx-devel/trunk/src/mathed/InsetMathFrameBox.cpp?rev=21198
> ==
> --- lyx-devel/trunk/src/mathed/InsetMathFrameBox.cp
On Thu, Oct 25, 2007 at 04:17:27PM +0200, Pavel Sanda wrote:
> hi,
> dont know whether this is according to last changesets or the fact i tried to
> use monolithic compilation.
>
> make[6]: Entering directory
> `/home/installer/lyx/trunk_disable/src/frontends/qt4'
> /bin/sh ../../../libtool --ta
On 10/25/07, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> > Couldn't we try to stick to the rules at least for new code?
Fixed.
> which brings me to the idea used in gentoo - before you commit some ebuild
> into the tree you call the python beast called repoman, which out of other
> things controls s
On Thu, Oct 25, 2007 at 09:56:33AM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> That might be enough. But it's not clear to me if this causes problems
> >> with cut and paste.
> >
> > Sure there will problems, but right now we already have special handling
> > for e.g. and three
Enrico Forestieri wrote:
On Thu, Oct 25, 2007 at 03:55:50PM +0200, Enrico Forestieri wrote:
I really wonder why lyx 1.5.2 (official installer) is even faster than
1.6 on Windows, whereas the Cygwin version suffers the same problem as
on *nix. I'll try to build 1.5 using mingw and report back.
Pavel Sanda wrote:
Are you sure you disabled stdlib-debug?
yes, tuning ./configure helped. :)
Good :-)
btw next pagination miracle in 1.6: try to select text via shift+arrow inside
the box
and then press pg-up - the cursor moves, but the selection does not disappear.
I'll check this ou
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Second, I do not see anything common between your desire of painting
nicely and the support for this new feature. We already suffer from
the merging of two different concepts (GUI color and LaTeX-level
color). There is no
Juergen Spitzmueller wrote:
Jean-Marc Lasgouttes wrote:
With other wordprocessors you can highlight text with a different
background. Isn't that something that we want to support?
First, I am not sure at all that there is a proper stable package for
doing that in LaTeX (colors are horrible in
Jean-Marc Lasgouttes wrote:
LyX' keysequence object already has support for displaying sequences
using Qt scheme. You could use a KeySequence object instead of a
QKeySequence object and have proper display. There is no reason to be
force to use the LyX internal representation for display.
ok, i
On Thu, Oct 25, 2007 at 03:55:50PM +0200, Enrico Forestieri wrote:
> I really wonder why lyx 1.5.2 (official installer) is even faster than
> 1.6 on Windows, whereas the Cygwin version suffers the same problem as
> on *nix. I'll try to build 1.5 using mingw and report back.
A mingw build of 1.5.3
On Thu, Oct 25, 2007 at 04:50:15PM +0200, Juergen Spitzmueller wrote:
> Enrico Forestieri wrote:
>
> > I committed it, and also sent an email to the latex2rtf developers list.
>
> I guess this also applies to branch. If so, please commit.
Done.
--
Enrico
On Thu, Oct 25, 2007 at 02:19:50PM +, Wilfried Hennings wrote:
> There is no easy solution because on English and US Windows, the programs
> folder is "C:\Program Files\" while e.g. on German Windows it's
> "C:\Programme",
> and under DOS there is no programs folder at all. So the default i
> Are you sure you disabled stdlib-debug?
yes, tuning ./configure helped. :)
btw next pagination miracle in 1.6: try to select text via shift+arrow inside
the box
and then press pg-up - the cursor moves, but the selection does not disappear.
p
> hi,
> dont know whether this is according to last changesets or the fact i tried to
> use monolithic compilation.
removing --enable-monolithic-frontend-qt4 helped.
p
Edwin Leuven <[EMAIL PROTECTED]> writes:
> for now it simply spits out qt's portable string representation of
> shortcuts. i like these better than lyx's since they are more verbose
> so personally i would have lyx switch those. you can of course return
> a QKeySequence instead and translate them
Jean-Marc Lasgouttes wrote:
>> With other wordprocessors you can highlight text with a different
>> background. Isn't that something that we want to support?
>
> First, I am not sure at all that there is a proper stable package for
> doing that in LaTeX (colors are horrible in LaTeX because they
Enrico Forestieri wrote:
> I committed it, and also sent an email to the latex2rtf developers list.
I guess this also applies to branch. If so, please commit.
Jürgen
Bo Peng wrote:
But how to clear the 'search ...' text when the lineedit gets focus? I
think we need some initial text in this lineedit, like what firefox
does to its search box.
not sure i follow this
better is use qt's model/view framework ...
Frankly, I have no idea what you (and Andre) a
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Second, I do not see anything common between your desire of painting
>> nicely and the support for this new feature. We already suffer from
>> the merging of two different concepts (GUI color and LaTeX-level
>> color). There is no need to add to thi
Andreas Karlsson <[EMAIL PROTECTED]> writes:
> Considering the difficulties to install latex2rtf and get it to work from
> inside LyX (see below), wouldn't it be a good idea to handle latex2rtf like
> e.g. the Aspell dictionaries, i.e. automatically download,
> install and configure it during th
hi,
dont know whether this is according to last changesets or the fact i tried to
use monolithic compilation.
make[6]: Entering directory
`/home/installer/lyx/trunk_disable/src/frontends/qt4'
/bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../../src -DQT_CLEAN_
>> not problem for 1.6 though.
>> 2) 1.6 - again open all insets. go with the cursor to the spaces between
>> first and second box. try pg-down and only view changes, cursor stand
>> where has previously been.
>
> Really? I cannot reproduce that... weird... Are you sure you aren't mixing
> up wi
On Thu, Oct 25, 2007 at 03:33:53PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > On Thu, Oct 25, 2007 at 02:30:47PM +0200, Pavel Sanda wrote:
> >> No, I see absolutely no delay and the cpu remains low. But I see some
> >> drawing mistakes in the right box when I type: the
Pavel Sanda wrote:
1.5.2 - cpu usage 87%, but the speed is much better, you wont recognize it in
normal typing.
generally editing the box on this faster machine is ok, selectnig text
via arrow keys is slightly slower.
arrow/wheel motion on one page is ok, redraw to the next is ok.
On Thu, Oct 25, 2007 at 02:41:58PM +0200, Jean-Marc Lasgouttes wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> > On Thu, Oct 25, 2007 at 12:13:45PM +0200, Enrico Forestieri wrote:
> >
> >> In conclusion, both configure.py (IMO) and latex2rtf need to be fixed.
> >> Doing that, using late
Alfredo Braunstein wrote:
Andre Poenitz wrote:
That might be enough. But it's not clear to me if this causes problems
with cut and paste.
Sure there will problems, but right now we already have special handling
for e.g. and three hundred inset function or so taking a buffer
An
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
URL: http://www.lyx.org/trac/changeset/21194
+CommandInfo const * InsetBibitem::findInfo(std::string const & /*
cmdName */)
+{
+static const char * const paramnames[] = {"label", "key", ""};
+static const bool isoptional[] = {true, fals
Abdelrazak Younes wrote:
Something like the attached, unfinished, patch
Thanks for these ideas. They'll be useful.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
=
> 1.5.2 - cpu usage 87%, but the speed is much better, you wont recognize it in
> normal typing.
> generally editing the box on this faster machine is ok, selectnig text
> via arrow keys is slightly slower.
>
> arrow/wheel motion on one page is ok, redraw to the next is ok.
have tri
Enrico Forestieri wrote:
On Thu, Oct 25, 2007 at 02:30:47PM +0200, Pavel Sanda wrote:
No, I see absolutely no delay and the cpu remains low. But I see some
drawing mistakes in the right box when I type: the corresponding line
disappears...
Now this is funny. I see the same problem as Pavel bot
On Thu, Oct 25, 2007 at 02:30:47PM +0200, Pavel Sanda wrote:
> > > > > No, I see absolutely no delay and the cpu remains low. But I see some
> > > > > drawing mistakes in the right box when I type: the corresponding line
> > > > > disappears...
> > > >
> > > > Now this is funny. I see the same p
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
+/// Return parameter information for command cmdName.
+/// Not implemented here. Must be implemented in derived class.
+static CommandInfo const * findInfo(std::string const & cmdName);
So make it pure virtual:
vitual CommandInfo
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 04:13:58AM -, [EMAIL PROTECTED] wrote:
+ICPInfo::ICPInfo(std::string const & s, bool b)
+ : paramName(s), optional(b)
+{}
+
+
+void ICPList::addParam(std::string const & s, bool b) {
+ plist_.push_back(ICPInfo(s, b));
+}
+
+
+bool I
Pavel Sanda wrote:
- when editing two Boxes placed side by side, which have already some more text
inside one gets quite amount of CPU work (no grahics, no maths involved) and
editing speed is slow. Selecting block of text has even worse latencies.
this behaviour seems to be dependent on h
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I do not think it belongs to font,
With other wordprocessors you can highlight text with a different
background. Isn't that something that we want to support?
First, I am not sure at all that there is a proper stable pa
> > - when editing two Boxes placed side by side, which have already some more
> > text
> > inside one gets quite amount of CPU work (no grahics, no maths involved)
> > and
> > editing speed is slow. Selecting block of text has even worse latencies.
> > this behaviour seems to be dependent
Andre Poenitz wrote:
Can everybody interested please state his preference wrt to
the cosmetics of enum types and 'members'? Name casing e.g.
I have no strong opinion on that other than that I like to
have some more uniform style than what we have now.
I have no strong opinion WRT enums but I j
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> On Thu, Oct 25, 2007 at 12:13:45PM +0200, Enrico Forestieri wrote:
>
>> In conclusion, both configure.py (IMO) and latex2rtf need to be fixed.
>> Doing that, using latex2rtf on Windows will be quite simple.
>
> Here is the fix for configure.py. If th
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> I do not think it belongs to font,
>
> With other wordprocessors you can highlight text with a different
> background. Isn't that something that we want to support?
First, I am not sure at all that there is a proper stable package for
doing that in
On Thu, Oct 25, 2007 at 12:13:45PM +0200, Enrico Forestieri wrote:
> In conclusion, both configure.py (IMO) and latex2rtf need to be fixed.
> Doing that, using latex2rtf on Windows will be quite simple.
Here is the fix for configure.py. If there are no objections, I am
going to commit it.
--
En
> > > > No, I see absolutely no delay and the cpu remains low. But I see some
> > > > drawing mistakes in the right box when I type: the corresponding line
> > > > disappears...
> > >
> > > Now this is funny. I see the same problem as Pavel both on Solaris
> > > and Windows when using a gcc buil
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
One simple solution would be to add a backgoundColor() member to Font
and to update that when we pass PainterInfo at draw(). Is that
acceptable? I personnally think it is and this new information could
be useful for other
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> One simple solution would be to add a backgoundColor() member to Font
> and to update that when we pass PainterInfo at draw(). Is that
> acceptable? I personnally think it is and this new information could
> be useful for other needs anyway.
I do no
On Thu, Oct 25, 2007 at 10:43:27AM +0200, Andreas Karlsson wrote:
>
> Considering the difficulties to install latex2rtf and get it to
> work from inside LyX (see below), wouldn't it be a good idea to
> handle latex2rtf like e.g. the Aspell dictionaries, i.e.
> automatically download, install and c
Abdelrazak Younes wrote:
Juergen Spitzmueller wrote:
In this first status update, I don't want to come up with an extensive
bug
list, but rather outline some main goals I have in mind for the next
release, and list some of the really important bugs (please fill in).
As far as 1.5.2 is concerne
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Thu Oct 25 06:13:56 2007
New Revision: 21194
URL: http://www.lyx.org/trac/changeset/21194
Log:
Move the findInfo() and defaultCommand() routines out of InsetCommand
and into its subclasses, so that the subclasses know what
On Thu, 25 Oct 2007 10:01:21 +0200
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> > Done, see attached.
>
> Very good.
>
> JMarc
It's committed, thanks.
- Martin
On Thu, Oct 25, 2007 at 10:20:19AM +0200, Kai Johannes Keller wrote:
> Hello Enrico,
>
> the script works perfect. Many thanks for the fast response.
>
> Greets
>
> Kai
Happy it helped. However, I am not sure that this cannot be regarded
as a bug. Rather, I think it is a bug.
--
Enrico
> please file bug reports for these to remind us. I'll be busy next week.
> - when deleting first few lines of text inside Box in the way that there
> remains empty line, the cursor movement outside of Box does not make that
> empty line vanish. the same at the end of Box. is this behaviour in
> * Pavel reported some regressions. We should check if Abdel's wide patch
> solves them.
no. report by Enrico its fixed in 1.6 though.
pavel
Considering the difficulties to install latex2rtf and get it to work from
inside LyX (see below), wouldn't it be a good idea to handle latex2rtf like
e.g. the Aspell dictionaries, i.e. automatically download, install and
configure it during the installation process, if the user selects this opt
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Yes. The interface should allow reading, inserting and deleting
>> strings and ct should be transparent. There is not a need for much
>> more than that (actually, I understand things are more complicated,
>> but it could be a goal of some sort).
>
>
> Couldn't we try to stick to the rules at least for new code?
which brings me to the idea used in gentoo - before you commit some ebuild
into the tree you call the python beast called repoman, which out of other
things controls syntactic & whitespace violations of rules and spits on you
nice and
Alfredo Braunstein wrote:
Andre Poenitz wrote:
That might be enough. But it's not clear to me if this causes problems
with cut and paste.
Sure there will problems, but right now we already have special handling
for e.g. and three hundred inset function or so taking a buffer
And what's the re
Juergen Spitzmueller wrote:
In this first status update, I don't want to come up with an extensive bug
list, but rather outline some main goals I have in mind for the next
release, and list some of the really important bugs (please fill in).
As far as 1.5.2 is concerned, we seemed to have made a
Andre Poenitz wrote:
>> That might be enough. But it's not clear to me if this causes problems
>> with cut and paste.
>
> Sure there will problems, but right now we already have special handling
> for e.g. and three hundred inset function or so taking a buffer
And what's the real problem with th
Juergen Spitzmueller wrote:
> * some (Mac) users reported that the temporary directory could not be
> deleted (cf.
>
http://www.mail-archive.com/[EMAIL PROTECTED]/msg59368.html)
Sorry, that's
http://marc.info/?l=lyx-users&m=119320011726222&w=2
Jürgen
Martin Vermeer <[EMAIL PROTECTED]> writes:
> Done, see attached.
Very good.
JMarc
Jean-Marc Lasgouttes wrote:
Andre Poenitz <[EMAIL PROTECTED]> writes:
But change tracking should be as much as possible internal to
Paragraph IMO.
That's what I was suggesting. Giving public low level access to
Paragraph data should be avoided to prevent problems with
change tracking.
Yes.
In this first status update, I don't want to come up with an extensive bug
list, but rather outline some main goals I have in mind for the next
release, and list some of the really important bugs (please fill in).
As far as 1.5.2 is concerned, we seemed to have made a huge progress in
terms of sta
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
So why are you disputing the benefice of my new
Paragraph::changeCase()? This thing do _touch_ change tracking ;-P
No, this things inserts and deletes stuff. Change tracking should not
be relevant here.
But it is:
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> But change tracking should be as much as possible internal to
>> Paragraph IMO.
>
> That's what I was suggesting. Giving public low level access to
> Paragraph data should be avoided to prevent problems with
> change tracking.
Yes. The interface shoul
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> So why are you disputing the benefice of my new
> Paragraph::changeCase()? This thing do _touch_ change tracking ;-P
No, this things inserts and deletes stuff. Change tracking should not
be relevant here.
JMarc
Abdelrazak Younes wrote:
> Sorry Juergen I committed this mechanically without recalling that this
> was 1.5...
It's OK.
Jürgen
On a Linux box:
valgrind --leak-check=full src/lyx
Open up the Users' Guide using the menu "Help>Users' Guide"
Wait some time...
Close LyX with "File>Exit"
That produces the rather disturbing report. This is with a bang-up-to-date
check out.
--
Angus
valgrind_report.txt.gz
Description: GNU Zip
88 matches
Mail list logo
