Re: [patch] allow to assign several extensions to a file format

[Andre Poenitz]

On Wed, Sep 07, 2011 at 11:06:04AM -0400, Richard Heck wrote:
 -std::string const  extension() const { return extension_; }
 +std::string const  extension() const { return extension_list_[0]; }
 
 and extension_list_[0] would be an invalid address otherwise.
 
 return extension_list_.empty() ?  : extension_list_[0]?

That would return a dangling reference in this particular case.

So either

std::string extension() const
{
return extension_list_.empty() ?  : extension_list_[0];
}

or the moral equivalent of

std::string const  extension() const
{
static std::string dummy;
return extension_list_.empty() ? dummy : extension_list_[0];
}

Andre'

Re: [patch] allow to assign several extensions to a file format

[Andre Poenitz]

On Wed, Sep 07, 2011 at 11:06:04AM -0400, Richard Heck wrote:
> >-std::string const & extension() const { return extension_; }
> >+std::string const & extension() const { return extension_list_[0]; }
> >
> >and extension_list_[0] would be an invalid address otherwise.
> >
> return extension_list_.empty() ? "" : extension_list_[0]?

That would return a dangling reference in this particular case.

So either

std::string extension() const
{
return extension_list_.empty() ? "" : extension_list_[0];
}

or the moral equivalent of

std::string const & extension() const
{
static std::string dummy;
return extension_list_.empty() ? dummy : extension_list_[0];
}

Andre'

Re: Preventing newline after a LatexType = Command line

[Andre Poenitz]

On Wed, Jun 22, 2011 at 08:47:08AM -0400, Richard Heck wrote:
 At the very end of Text::getStatus(), we have:
 
   if (code != NO_CODE
(cur.empty()
 || !cur.inset().insetAllowed(code)
 || cur.paragraph().layout().pass_thru))
 enable = false;
 
 This obviously disables everything Text handles in PassThru layouts.

Each time I see this I have to cry.

Could this, please, please, pretty please, get a 'ough' at the end?

Even if this is super cool, American, patriotic, informal, and cute,
will save the world and revive the dodo, it is so terribly wrong
in my little universe that I am even tempted to find out how to 
make patches for LyX nowadays.

Andre'

Re: Preventing newline after a LatexType = Command line

[Andre Poenitz]

On Wed, Jun 22, 2011 at 08:47:08AM -0400, Richard Heck wrote:
> At the very end of Text::getStatus(), we have:
> 
>   if (code != NO_CODE
>   && (cur.empty()
> || !cur.inset().insetAllowed(code)
> || cur.paragraph().layout().pass_thru))
> enable = false;
> 
> This obviously disables everything Text handles in PassThru layouts.

Each time I see this I have to cry.

Could this, please, please, pretty please, get a 'ough' at the end?

Even if this is super cool, American, patriotic, informal, and cute,
will save the world and revive the dodo, it is so terribly wrong
in my little universe that I am even tempted to find out how to 
make patches for LyX nowadays.

Andre'

Re: lyx math autocorrection

[Andre Poenitz]

On Mon, Jun 20, 2011 at 08:21:03PM +0300, Martin Vermeer wrote:
  We'd have to look at mailing list discussions around this date to
  understand whether this was fixing a real need or just being overly
  cautious. André, do you remember about it?
  
  JMarc
 
 (Overly?) cautious, I think. Someone (André?) turned it off because there
 were still some warts. I turned it conditionally on again because I judged
 it useful in spite of this.

I seem to remember real problems near math macros. Nothing concrete,
though.

Andre'

Re: lyx math autocorrection

[Andre Poenitz]

On Mon, Jun 20, 2011 at 08:21:03PM +0300, Martin Vermeer wrote:
> > We'd have to look at mailing list discussions around this date to
> > understand whether this was fixing a real need or just being overly
> > cautious. André, do you remember about it?
> > 
> > JMarc
> 
> (Overly?) cautious, I think. Someone (André?) turned it off because there
> were still some warts. I turned it conditionally on again because I judged
> it useful in spite of this.

I seem to remember real problems near math macros. Nothing concrete,
though.

Andre'

Re: epstopdf fails with 2.0.1svn

[Andre Poenitz]

On Wed, Jun 15, 2011 at 12:29:00AM +0200, Enrico Forestieri wrote:
 On Tue, Jun 14, 2011 at 08:58:08PM +0200, Andre Poenitz wrote:
  On Tue, Jun 14, 2011 at 08:16:49PM +0200, Enrico Forestieri wrote:
   No, I didn't find anything specific but it is clear that using the QtCore
   library is not advisable for this task.
   
PS I can do the recommit to branch, once it's in trunk.
   
   I committed the fix at r39049. However, I think that the reversion of
   r38746 was not necessary given that a patch had been already devised.
  
  I wonder whether it might be possible for you to file
  a proper bug report for that, i.e. some minimal, but
  complete, reproducible example that exhibits that problem
  on bugreports.qt.nokia.com, product Qt, component
  core: i/o (or whatever is close).
 
 I don't have an account (and don't want to have one), so I cannot report
 the bug. Maybe someone with an account could do that.

I guess I could do that.

 I attach here a simple test case exhibiting the problem.
 
 Problem: When setting the environment of QProcess, a script without
 a shebang line fails to execute.
 
 How to reproduce:
 1) Save the myprog perl script and test-env.cpp in the same directory.
 2) Make executable myprog by chmod 755 myprog.
 3) Compile test-env.cpp without defining SETENV.
 4) Launch the just compiled executable and verify that the the script is
actually executed.
 5) Now compile test-env.cpp by using -DSETENV.
 6) Launch again the executable and verify that it now fails to execute.
 
 -- 
 Enrico

 eval '(exit $?0)'  eval 'exec perl -S $0 ${1+$@}'  eval 'exec perl -S 
 $0 $argv:q'
   if 0;
 
 print it works;
 exit(0);

 #include QProcess
 #include QDebug
 #include QtCore
 
 int main()
 {
 QProcess *proc = new QProcess();
 #ifdef SETENV
 proc-setEnvironment(QProcess::systemEnvironment());
 #endif
 proc-setProcessChannelMode(QProcess::MergedChannels);
 proc-start(./myprog);
 if (proc-waitForFinished())
   qDebug()  Output:  proc-readAll();
 else
   qDebug()  Fail:  proc-errorString();
 proc-close();
 delete proc;
 return 0;
 }

Ok, that would certainly be detailed enough for a bug report.

The path with environment ends up in execve(), the other one in
execvp(). execve() requires a shebang line or a binary, execvp()
is more forgiving. I admit that this is ... underdocumented.

The visible difference here seems to be triggered by the missing
shebang line in the script. Is that intentional?

Andre'

Re: epstopdf fails with 2.0.1svn

[Andre Poenitz]

On Wed, Jun 15, 2011 at 12:29:00AM +0200, Enrico Forestieri wrote:
> On Tue, Jun 14, 2011 at 08:58:08PM +0200, Andre Poenitz wrote:
> > On Tue, Jun 14, 2011 at 08:16:49PM +0200, Enrico Forestieri wrote:
> > > No, I didn't find anything specific but it is clear that using the QtCore
> > > library is not advisable for this task.
> > > 
> > > > PS I can do the recommit to branch, once it's in trunk.
> > > 
> > > I committed the fix at r39049. However, I think that the reversion of
> > > r38746 was not necessary given that a patch had been already devised.
> > 
> > I wonder whether it might be possible for you to file
> > a proper bug report for that, i.e. some minimal, but
> > complete, reproducible example that exhibits that problem
> > on bugreports.qt.nokia.com, product "Qt", component
> > "core: i/o" (or whatever is close).
> 
> I don't have an account (and don't want to have one), so I cannot report
> the bug. Maybe someone with an account could do that.

I guess I could do that.

> I attach here a simple test case exhibiting the problem.
> 
> Problem: When setting the environment of QProcess, a script without
> a shebang line fails to execute.
> 
> How to reproduce:
> 1) Save the myprog perl script and test-env.cpp in the same directory.
> 2) Make executable myprog by "chmod 755 myprog".
> 3) Compile test-env.cpp without defining SETENV.
> 4) Launch the just compiled executable and verify that the the script is
>actually executed.
> 5) Now compile test-env.cpp by using -DSETENV.
> 6) Launch again the executable and verify that it now fails to execute.
> 
> -- 
> Enrico

> eval '(exit $?0)' && eval 'exec perl -S $0 ${1+"$@"}' && eval 'exec perl -S 
> $0 $argv:q'
>   if 0;
> 
> print "it works";
> exit(0);
>
> #include 
> #include 
> #include 
> 
> int main()
> {
> QProcess *proc = new QProcess();
> #ifdef SETENV
> proc->setEnvironment(QProcess::systemEnvironment());
> #endif
> proc->setProcessChannelMode(QProcess::MergedChannels);
> proc->start("./myprog");
> if (proc->waitForFinished())
>   qDebug() << "Output:" << proc->readAll();
> else
>   qDebug() << "Fail:" << proc->errorString();
> proc->close();
> delete proc;
> return 0;
> }

Ok, that would certainly be detailed enough for a bug report.

The path with environment ends up in execve(), the other one in
execvp(). execve() requires a shebang line or a binary, execvp()
is more forgiving. I admit that this is ... underdocumented.

The visible difference here seems to be triggered by the "missing"
"shebang line" in the script. Is that intentional?

Andre'

Re: r38969 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Tue, Jun 07, 2011 at 03:06:30PM +0200, Enrico Forestieri wrote:
 On Tue, Jun 07, 2011 at 02:43:47PM +0200, Jean-Marc Lasgouttes wrote:
 
  How portable is this in your opinion?
 
 It assumes a bourne compatible shell, but that assumption is made
 in so many places that I think it's very safe.
 
 The only problem that I foresee is when one of the minor numbers
 in the Qt version is greater than 9. For example, it will fail
 for Qt 4.10.0 (in its present form), but it can be complicated
 a bit to also account for that.

There won't be a Qt 4.10.

Andre'

Re: r38997 - lyx-devel/trunk

[Andre Poenitz]

On Thu, Jun 09, 2011 at 01:00:28AM +0200, kor...@lyx.org wrote:
 Date: Thu Jun  9 01:00:28 2011
 New Revision: 38997
 URL: http://www.lyx.org/trac/changeset/38997
 
 Log:
 Use decimal representation of QT_VERSION for moc-run in cmake build to match 
 the qglobal.h computation
 
 Modified:
lyx-devel/trunk/CMakeLists.txt
 
 Modified: lyx-devel/trunk/CMakeLists.txt
 ==
 --- lyx-devel/trunk/CMakeLists.txtWed Jun  8 22:22:27 2011(r38996)
 +++ lyx-devel/trunk/CMakeLists.txtThu Jun  9 01:00:28 2011(r38997)
 @@ -618,8 +618,7 @@
  
  # Compute qt4-version from ${QTVERSION}
  if(QTVERSION MATCHES ^([0-9]+)\\.([0-9]+)\\.([0-9]+).*)
 - MATH(EXPR QT4_VERSIONNUM 
 ${CMAKE_MATCH_1}*1+${CMAKE_MATCH_2}*100+${CMAKE_MATCH_3})
 - set(QT4_VERSION 0x${QT4_VERSIONNUM})
 + MATH(EXPR QT4_VERSION 
 (${CMAKE_MATCH_1}16)|(${CMAKE_MATCH_2}8)|${CMAKE_MATCH_3})
  endif()
  
  add_subdirectory(src ${TOP_BINARY_DIR}/src)


Wasn't the original problem that QPropertyAnimation was new in 4.7?

If that's the case why not #if QT_VERSION-guard the #include
QPropertyAnimation and the body of the not-so-important function
IconButton::animateShow() which seems to be the only use
QPropertyAnimation? Or even remove that entirely?

Mutilating the rest of the class and fixing the Three Favourite Build
Systems does not seem to be warranted by that kind of problem, does it?

Andre'

Re: r38969 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Tue, Jun 07, 2011 at 03:06:30PM +0200, Enrico Forestieri wrote:
> On Tue, Jun 07, 2011 at 02:43:47PM +0200, Jean-Marc Lasgouttes wrote:
> 
> > How portable is this in your opinion?
> 
> It assumes a bourne compatible shell, but that assumption is made
> in so many places that I think it's very safe.
> 
> The only problem that I foresee is when one of the minor numbers
> in the Qt version is greater than 9. For example, it will fail
> for Qt 4.10.0 (in its present form), but it can be complicated
> a bit to also account for that.

There won't be a Qt 4.10.

Andre'

Re: r38997 - lyx-devel/trunk

[Andre Poenitz]

On Thu, Jun 09, 2011 at 01:00:28AM +0200, kor...@lyx.org wrote:
> Date: Thu Jun  9 01:00:28 2011
> New Revision: 38997
> URL: http://www.lyx.org/trac/changeset/38997
> 
> Log:
> Use decimal representation of QT_VERSION for moc-run in cmake build to match 
> the qglobal.h computation
> 
> Modified:
>lyx-devel/trunk/CMakeLists.txt
> 
> Modified: lyx-devel/trunk/CMakeLists.txt
> ==
> --- lyx-devel/trunk/CMakeLists.txtWed Jun  8 22:22:27 2011(r38996)
> +++ lyx-devel/trunk/CMakeLists.txtThu Jun  9 01:00:28 2011(r38997)
> @@ -618,8 +618,7 @@
>  
>  # Compute qt4-version from ${QTVERSION}
>  if(QTVERSION MATCHES "^([0-9]+)\\.([0-9]+)\\.([0-9]+).*")
> - MATH(EXPR QT4_VERSIONNUM 
> "${CMAKE_MATCH_1}*1+${CMAKE_MATCH_2}*100+${CMAKE_MATCH_3}")
> - set(QT4_VERSION "0x${QT4_VERSIONNUM}")
> + MATH(EXPR QT4_VERSION 
> "(${CMAKE_MATCH_1}<<16)|(${CMAKE_MATCH_2}<<8)|${CMAKE_MATCH_3}")
>  endif()
>  
>  add_subdirectory(src "${TOP_BINARY_DIR}/src")


Wasn't the original problem that QPropertyAnimation was new in 4.7?

If that's the case why not #if QT_VERSION-guard the #include
 and the body of the not-so-important function
IconButton::animateShow() which seems to be the only use
QPropertyAnimation? Or even remove that entirely?

Mutilating the rest of the class and fixing the Three Favourite Build
Systems does not seem to be warranted by that kind of problem, does it?

Andre'

Re: Lyx 2.0.0 OSX Coca version cursor problems (was OSX crashes)

[Andre Poenitz]

On Mon, Jun 06, 2011 at 09:02:08PM +0200, Stephan Witt wrote:
 Am 06.06.2011 um 17:54 schrieb Murat Yildizoglu:
 
  Just to refresh this thread, I have reinstalled the standard Lyx 2
  OSX build and the cursor problem has been corrected.  So it seems
  that this problem comes from the Cocoa QT version. Has anybody else
  observed this problem with the experimental version proposed by
  Stephan?
 
 I'm almost sure it's Cocoa based Qt that makes the problem. Until your
 report I thought it's the Qt-version what matters.  See the ticket
 http://www.lyx.org/trac/ticket/6920 and the discussion here
 http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg164633.html
 
 Unfortunately we have a real Scylla versus Charybdis scenario here.

What was the reason to not use QFontMetrics to compute the size of
a full word and interpolate the cursor inbetween (or compute the
size of the word left of the cursor), as Jean-Marc proposed?

Andre'

Re: Qt books

[Andre Poenitz]

On Mon, Jun 06, 2011 at 03:18:01PM -0700, Xu Wang wrote:
 Hi, I would like to learn Qt. I learn much better from physical books than
 online resources, although I've heard the Qt manual is very good.
 
 Does anyone have suggestions for me?

Your question is a bit off-topic here. Try qt-inter...@qt.nokia.com
or something similar.

Google's first hit for qt books is http://developer.qt.nokia.com/books
which happens to be the official site. The first one (Blanchette/
Summerfield) is a very good start.

 How much does Qt change from year to year? I am trying to figure out how new
 the book that I look for should be.

It should be Qt _4_. There's about one minor release per year, but 
currently Qt 5 is being discussed. This will still take a while though,
and people try fairly hard to keep incompatibilities small, certainly
less than the Qt 3 - Qt 4 jump six years ago.

 Is there any chance that LyX will stop using Qt in the recent future?

Unlikely from my point of view, given that there are no serious
alternatives for the kind of cross-platformness LyX exhibits.

Andre' 

Re: Lyx 2.0.0 OSX Coca version cursor problems (was OSX crashes)

[Andre Poenitz]

On Mon, Jun 06, 2011 at 09:02:08PM +0200, Stephan Witt wrote:
> Am 06.06.2011 um 17:54 schrieb Murat Yildizoglu:
> 
> > Just to refresh this thread, I have reinstalled the standard Lyx 2
> > OSX build and the cursor problem has been corrected.  So it seems
> > that this problem comes from the Cocoa QT version. Has anybody else
> > observed this problem with the experimental version proposed by
> > Stephan?
> 
> I'm almost sure it's Cocoa based Qt that makes the problem. Until your
> report I thought it's the Qt-version what matters.  See the ticket
> http://www.lyx.org/trac/ticket/6920 and the discussion here
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg164633.html
> 
> Unfortunately we have a real Scylla versus Charybdis scenario here.

What was the reason to not use QFontMetrics to compute the size of
a full word and interpolate the cursor inbetween (or compute the
size of the "word" left of the cursor), as Jean-Marc proposed?

Andre'

Re: Qt books

[Andre Poenitz]

On Mon, Jun 06, 2011 at 03:18:01PM -0700, Xu Wang wrote:
> Hi, I would like to learn Qt. I learn much better from physical books than
> online resources, although I've heard the Qt manual is very good.
> 
> Does anyone have suggestions for me?

Your question is a bit off-topic here. Try qt-inter...@qt.nokia.com
or something similar.

Google's first hit for "qt books" is http://developer.qt.nokia.com/books
which happens to be the "official" site. The first one (Blanchette/
Summerfield) is a very good start.

> How much does Qt change from year to year? I am trying to figure out how new
> the book that I look for should be.

It should be Qt _4_. There's about one minor release per year, but 
currently Qt 5 is being discussed. This will still take a while though,
and people try fairly hard to keep incompatibilities small, certainly
less than the Qt 3 -> Qt 4 jump six years ago.

> Is there any chance that LyX will stop using Qt in the recent future?

Unlikely from my point of view, given that there are no serious
alternatives for the kind of cross-platformness LyX exhibits.

Andre' 

Re: Too much options in LyX

[Andre Poenitz]

On Tue, May 17, 2011 at 08:11:29AM +0200, Peter Kümmel wrote:
 On 16.05.2011 23:54, venom00 wrote:
 Vincent or someone else, can you tell me if it's OK to include a pair
 of files directly from the Qt Creator code?  Just a quick reply so I
 can go on with the patch.
 
 Isn't QtCreator LGPL? Then it would be ok.

Most of it. There are a few 3-clause BSD and a handful other files.
The files have fat comments in the beginning stating under which 
license they are. Any of them should be compatible with LyX.

Andre'

Re: Too much options in LyX

[Andre Poenitz]

On Tue, May 17, 2011 at 08:11:29AM +0200, Peter Kümmel wrote:
> On 16.05.2011 23:54, venom00 wrote:
> >Vincent or someone else, can you tell me if it's OK to include a pair
> >of files directly from the Qt Creator code?  Just a quick reply so I
> >can go on with the patch.
> 
> Isn't QtCreator LGPL? Then it would be ok.

Most of it. There are a few 3-clause BSD and a handful other files.
The files have fat comments in the beginning stating under which 
license they are. Any of them should be compatible with LyX.

Andre'

Re: LyX console warnings in LyX 2.0.0

[Andre Poenitz]

On Sun, May 15, 2011 at 06:59:38PM +0200, Vincent van Ravesteijn wrote:
 On Sun, May 15, 2011 at 6:53 PM, Uwe Stöhr uwesto...@web.de wrote:
 
  With LyX 2.0.0
  - open the Tutorial
  - insert there a new table
  - set the cursor into the new table
 
  In the LyX console window I then get these messages:
 
   QWidget::repaint: Recursive repaint detected
   QPainter::begin: Paint device returned engine == 0, type: 1
   QPainter::setPen: Painter not active
 
  What about them?

 That's a Qt problem.

LyX still uses repaint() instead of update(), doesn't it?

Andre'

Re: LyX console warnings in LyX 2.0.0

[Andre Poenitz]

On Sun, May 15, 2011 at 06:59:38PM +0200, Vincent van Ravesteijn wrote:
> On Sun, May 15, 2011 at 6:53 PM, Uwe Stöhr  wrote:
> 
> > With LyX 2.0.0
> > - open the Tutorial
> > - insert there a new table
> > - set the cursor into the new table
> >
> > In the LyX console window I then get these messages:
> >
> >  QWidget::repaint: Recursive repaint detected
> >  QPainter::begin: Paint device returned engine == 0, type: 1
> >  QPainter::setPen: Painter not active
> >
> > What about them?
>
> That's a Qt problem.

LyX still uses repaint() instead of update(), doesn't it?

Andre'

Re: r38620 - www-user/trunk/misc/archaeology

[Andre Poenitz]

On Sun, May 08, 2011 at 05:36:24PM +0200, Kornel wrote:
   Lars only until 1.1.3 Lars for devel and JMarc for stable starting
   with 1.1.4fix1
  
  till 0.10 (~1996) announce is always from D.L. Johnson, with lines
  author:Matthias, Maintenance: DL Johnson. 0.12 (~1998) announce is
  M.  Shigeru and Lars is first in credits, while Matthias has thanks
  for starting the project. so i would conclude that with 0.12 he was
  taking the care...
 
 Yes, that's my memory too. I think, at the time klyx was created,
 Mathias was already outside.

klyx was 0.10. Matthias claims Lars officially took over as maintainer
a long time before he retired. So that would fit the picture, but it
could also mean 0.8.

We are clearly in a state now where real archeologists are needed ;-)

Andre'

Re: r38620 - www-user/trunk/misc/archaeology

[Andre Poenitz]

On Sun, May 08, 2011 at 05:36:24PM +0200, Kornel wrote:
> > > Lars only until 1.1.3 Lars for devel and JMarc for stable starting
> > > with 1.1.4fix1
> > 
> > till 0.10 (~1996) announce is always from D.L. Johnson, with lines
> > author:Matthias, Maintenance: DL Johnson. 0.12 (~1998) announce is
> > M.  Shigeru and Lars is first in credits, while Matthias has thanks
> > for starting the project. so i would conclude that with 0.12 he was
> > taking the care...
> 
> Yes, that's my memory too. I think, at the time klyx was created,
> Mathias was already outside.

klyx was 0.10. Matthias claims Lars officially took over as maintainer
"a long time" before he retired. So that would fit the picture, but it
could also mean 0.8.

We are clearly in a state now where real archeologists are needed ;-)

Andre'

Re: Directory cleanup

[Andre Poenitz]

On Thu, May 12, 2011 at 05:53:28AM +0200, Peter Kümmel wrote:
 On 11.05.2011 20:19, Pavel Sanda wrote:
 Abdelrazak Younes wrote:
 Side notes:
 1: we should really get rid of boost source.
 2: we should really get rid of boost using code
 
 whats your solution the problems with tr1::regexp in gcc discussed last time?
 
 We could switch to QRegEx. But it's not a 100% drop it.

/me personally does not like it.

Surprised?

Not exactly fast, and broken interface...

I am, however, definitely in favour of 1: and 2: above.

Andre'

Re: Directory cleanup

[Andre Poenitz]

On Thu, May 12, 2011 at 05:53:28AM +0200, Peter Kümmel wrote:
> On 11.05.2011 20:19, Pavel Sanda wrote:
> >Abdelrazak Younes wrote:
> >>Side notes:
> >>1: we should really get rid of boost source.
> >>2: we should really get rid of boost using code
> >
> >whats your solution the problems with tr1::regexp in gcc discussed last time?
> 
> We could switch to QRegEx. But it's not a 100% drop it.

/me personally does not like it.

Surprised?

Not exactly fast, and broken interface...

I am, however, definitely in favour of 1: and 2: above.

Andre'

Re: Scripting vs plugins

[Andre Poenitz]

On Fri, May 06, 2011 at 07:33:35PM +, Guenter Milde wrote:
 On 2011-05-06, venom00 wrote:
   Lua
  + small and fast,
  + used in LuaTeX, so it will become more common and known in the
TeX community,
  + a Lua interpreter can be embedded in LyX with minimal 
  impact on
the binary size.
 
   Wasn't there another thread with the result that LyX is not 
   bloated enough?
 
 Actually this was a response to the allow plug-ins sub-thread of
 the goals for 2.1. The idea was to reduce the memory footprint by a
 plugin system.

But honestly, the memory footprint of LyX is really not a problem.
We are talking about a 8.5 stripped binary. Some screensavers have
more fat. It's really not worth even _thinking_ about a plugin system
to reduce binary size.

 [...]
 With an embedded Lua interpreter, OTOH the impact on performance will be
 small for tasks like writing/parsing config files, lyx2lyx, tex2lyx etc.
 The intelligence can be stored in scripts that do not bloat the main
 binary.

What bloat, please?

Andre'

Re: Scripting vs plugins

[Andre Poenitz]

On Fri, May 06, 2011 at 07:33:35PM +, Guenter Milde wrote:
> On 2011-05-06, venom00 wrote:
> >> >> Lua
> >> >>+ small and fast,
> >> >>+ used in LuaTeX, so it will become more common and known in the
> >> >>  TeX community,
> >> >>+ a Lua interpreter can be embedded in LyX with minimal 
> >> impact on
> >> >>  the binary size.
> 
> >> > Wasn't there another thread with the result that LyX is not 
> >> > bloated enough?
> 
> Actually this was a response to the "allow plug-ins" sub-thread of
> the "goals for 2.1". The idea was to reduce the memory footprint by a
> plugin system.

But honestly, the memory footprint of LyX is really not a problem.
We are talking about a 8.5 stripped binary. Some screensavers have
more fat. It's really not worth even _thinking_ about a plugin system
to reduce binary size.

> [...]
> With an embedded Lua interpreter, OTOH the impact on performance will be
> small for tasks like writing/parsing config files, lyx2lyx, tex2lyx etc.
> The "intelligence" can be stored in scripts that do not bloat the main
> binary.

What bloat, please?

Andre'

Re: Development of a development model

[Andre Poenitz]

On Thu, May 05, 2011 at 11:24:13PM +0200, Peter Kümmel wrote:
  [..]
 That's not a joke, it's not made up. I am honestly not aware
 of any single operation, not even artificial scenarios, where
 git performs worse than svn.
 
 Maybe this one:
 
 time svn co svn://svn.lyx.org/lyx/lyx-devel/trunk
 real  0m27.906s
 user  0m4.120s
 sys   0m5.120s
 
 time git clone git://gitorious.org/lyx/lyx.git
 real  2m41.146s
 user  0m34.820s
 sys   0m29.320s

Ok, I have to admit that I never timed that. 
 
 OK, we have the complete history with git, but often this
 isn't of interest:
 
 time git clone --depth 1 git://gitorious.org/lyx/lyx.git
 real  0m15.568s
 user  0m1.960s
 sys   0m3.230s
 
 Is it possible to push/pull from such a clone?

Not sure, I never used --depth, according to the man page it's not
possible to pull/push, but it also says it's sufficient to create
patches from it, so this would be even a theoretical option for
people without commit rights. I doubt that's a good trade-off, though.

Andre'

Re: Development of a development model

[Andre Poenitz]

On Thu, May 05, 2011 at 11:24:13PM +0200, Peter Kümmel wrote:
> > [..]
> >That's not a joke, it's not made up. I am honestly not aware
> >of any single operation, not even artificial scenarios, where
> >git performs worse than svn.
> 
> Maybe this one:
> 
> time svn co svn://svn.lyx.org/lyx/lyx-devel/trunk
> real  0m27.906s
> user  0m4.120s
> sys   0m5.120s
> 
> time git clone git://gitorious.org/lyx/lyx.git
> real  2m41.146s
> user  0m34.820s
> sys   0m29.320s

Ok, I have to admit that I never timed that. 
 
> OK, we have the complete history with git, but often this
> isn't of interest:
> 
> time git clone --depth 1 git://gitorious.org/lyx/lyx.git
> real  0m15.568s
> user  0m1.960s
> sys   0m3.230s
> 
> Is it possible to push/pull from such a clone?

Not sure, I never used --depth, according to the man page it's not
possible to pull/push, but it also says it's sufficient to create
patches from it, so this would be even a theoretical option for
people without commit rights. I doubt that's a good trade-off, though.

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Wed, May 04, 2011 at 12:43:05PM +0200, Pavel Sanda wrote:
 Vincent van Ravesteijn wrote:
   anyone around strongly against 100-char wide rule?
  
  YES, me !
 
 hmm, i should also count caps lock and exclamation marks when doing
 next emoticons statistics... :)
 
  Normal Code please, so don't come up with 20 connects beneath each other
  or the like.
 
 i admit that this thread is not spin off from normal code. i just dont 
 recognize how: 
 
 LYXERR(level, blabla  x-variable  blablabla
y-var  blabla  z-variable);
 
 is more readable than
 
 LYXERR(level, blabla  x-variable  blablabla  y-var  blabla  
 z-variable);

Ok. This shows here as:

--  snip ---
 i admit that this thread is not spin off from normal code. i just dont recogn
ize how: 


LYXERR(level, blabla  x-variable  blablabla
 y-var  blabla  z-variable);

is more readable than

LYXERR(level, blabla  x-variable  blablabla  y-var  blabla 
z-variable);
--  snip ---

Including the break within recognize.

Given that kind of context, would you accept that the first version is
preferable?

 that said if you agree on those few exception from 80 rule then i'll be
 satisfied with such outcome of our flame.

Exempting certain constructs from the rule seems to be more platable 
then to drop the rule completely...

Andre'

Re: Development of a development model

[Andre Poenitz]

On Wed, May 04, 2011 at 04:16:13PM +0200, Vincent van Ravesteijn wrote:
 On Wed, May 4, 2011 at 2:13 PM, Pavel Sanda sa...@lyx.org wrote:
 
  Andre Poenitz wrote:
   Close to the current svn model, but allow people to use branches for
   non-trivial feature sets if they like?
 
  +1
 
 
 Then we can just as well stay with svn.

I don't think the following are equivalent:

...  cd ~/lyx/trunk ; time svn log  /dev/null
real4m28.451s
user0m1.112s
sys 0m0.268s

...  cd ~/lyx-git ; time git log  /dev/null 
real0m2.128s
user0m1.264s
sys 0m0.080s

Yes. That's a factor of 130, and the respective outputs (if
not redirected to /dev/null...) contain similar information.

And it's similar for blame, diff, and any other operation
that does not work on the local copy only.

That's not a joke, it's not made up. I am honestly not aware
of any single operation, not even artificial scenarios, where
git performs worse than svn.

For me the major selling point for git is not that it enables
fancy workflows beyond what is possible with svn (which it
obviously does) but that it can do whatever svn can do, only
_much_ better.

Andre'

Re: Goals for 2.1

[Andre Poenitz]

On Wed, May 04, 2011 at 05:27:36PM +0200, Tommaso Cucinotta wrote:
 Il 04/05/2011 17:16, Rob Oakes ha scritto:
 
 Software bloat is a term used to describe the tendency of newer computer
 programs to have a larger installation footprint, or have many unnecessary
 features that are not used by end users, or just generally use more system
 resources than necessary, while offering little or no benefit to its users.
 [...]
 But I'm all for helping to reduce the memory footprint and optimizing code, 
 but I think we should think carefully before removing existing features.
 
 On a related note, does anyone know how much bloating effect comes
 from the use of more and more recent Qt (or other libraries, i..e,
 boost) versions :-) ?

Most certainly not.

And the minimum requirements of LyX on both are not even
remotely recent.

 Also, if really we have too many features, what about trying to
 embed some modularity in LyX and make them dynamically loadable
 on-demand ?

Overengineered extra code to maintain.

Plugin systemis only (or rather, at most) make sense if there's
a decent chance to have third parties creating plugins that are
not maintained/distributed with the main product.

For LyX, assuming a probability of zero for that case seems to be
a good first approximation.

 (i.e., dynamically linked libraries/plugins loaded on
 demand) Or, confine some features into external tools launched on
 demand, as opposed to have it integrated into the main code ? (e.g.,
 what is the current implementation model for the Compare Document
 feature ? Is it integrated in LyX, or does it call an external
 program ?)

The maintenance effort will outweigh any potential benefits by
several orders of magnitude.

 But, first of all maybe we need clear measurements for assessing
 whether or not any of the above is really necessary.

I don't think it's worthwhile to spend time to come to obvious
conclusions, but I certainly won't stop anyone doing that.

Andre'

Re: SVN mirror of git

[Andre Poenitz]

On Wed, May 04, 2011 at 09:45:04AM -0600, Rob Oakes wrote:

 With all that said, I did have a question regarding our existing
 infrastructure. Whatever model we end up settling on, would it be
 possible to mirror the git master branch to SVN? (Basically the same
 thing we do for the git users, except in reverse.)

git-svn exists, and works sufficiently well to handle mirror
repositories.

However, I personally think of it as a means to lower psychological
barriers, allowing to postpone the personal mental switch or to 
overcome technical or political restrictions like the ones you
mentioned, but not as a long-term prefered way of working.

Andre'

Re: Goals for 2.1

[Andre Poenitz]

On Wed, May 04, 2011 at 07:45:44PM +0200, Peter Kümmel wrote:
 On 04.05.2011 14:26, Abdelrazak Younes wrote:
 On 04/05/2011 00:50, Vincent van Ravesteijn wrote:
 Hi everyone,
 As a typical start of a new release cycle I want to poll
 - what features are a must in the next release;
 
 Features:
 * Git based Embedded LyX.
 
 Couldn't we somehow re-use QtCreators plugins? They have
 a nice plugin-system. Looks a bit inspired by OSGi. Maybe
 Andre is willed and allowed to talk about it.

I can certainly talk about it, and it would be hard to hide
anything anyway. It's Open Source after all ;-}

I think it is conceptually possible to re-use the plugin loader
(just a few hundred lines of code after all), but I would not
recommend it in general, and certainly not for LyX, mainly for
two reason:

  - LyX architecture is still a bit unusual, insofar as the
core drives the gui, not the other way round, so it does
not fit too well into alien MVC setups.

  - I don't think there is any need to split LyX into plugins.

Reusing the git plugin code on a conceptual level might be in
possible in theory, but given that the implementation only calls
the command line tool, I am fairly sure there won't be much more
practical reuse than the lines containing the opening and
closing braces of function bodies in the end ;-}

Sorry to spoil the fun here.

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Wed, May 04, 2011 at 12:43:05PM +0200, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
> > > anyone around strongly against 100-char wide rule?
> > 
> > YES, me !
> 
> hmm, i should also count caps lock and exclamation marks when doing
> next emoticons statistics... :)
> 
> > "Normal Code" please, so don't come up with 20 connects beneath each other
> > or the like.
> 
> i admit that this thread is not spin off from normal code. i just dont 
> recognize how: 
> 
> LYXERR(level, "blabla" << x->variable << "blablabla"
>   << y->var << "blabla" << z->variable);
> 
> is more readable than
> 
> LYXERR(level, "blabla" << x->variable << "blablabla" << y->var << "blabla" << 
> z->variable);

Ok. This shows here as:

--  snip ---
> i admit that this thread is not spin off from normal code. i just dont recogn
ize how: 
>

LYXERR(level, "blabla" << x->variable << "blablabla"
<< y->var << "blabla" << z->variable);

is more readable than

LYXERR(level, "blabla" << x->variable << "blablabla" << y->var << "blabla" <<
z->variable);
--  snip ---

Including the break within "recognize".

Given that kind of context, would you accept that the first version is
"preferable"?

> that said if you agree on those few exception from 80 rule then i'll be
> satisfied with such outcome of our flame.

Exempting certain constructs from the rule seems to be more platable 
then to drop the rule completely...

Andre'

Re: Development of a development model

[Andre Poenitz]

On Wed, May 04, 2011 at 04:16:13PM +0200, Vincent van Ravesteijn wrote:
> On Wed, May 4, 2011 at 2:13 PM, Pavel Sanda <sa...@lyx.org> wrote:
> 
> > Andre Poenitz wrote:
> > > Close to the current svn model, but allow people to use branches for
> > > non-trivial feature sets if they like?
> >
> > +1
> >
> 
> Then we can just as well stay with svn.

I don't think the following are equivalent:

... > cd ~/lyx/trunk ; time svn log > /dev/null
real4m28.451s
user0m1.112s
sys 0m0.268s

... > cd ~/lyx-git ; time git log > /dev/null 
real0m2.128s
user0m1.264s
sys 0m0.080s

Yes. That's a factor of 130, and the respective outputs (if
not redirected to /dev/null...) contain similar information.

And it's similar for blame, diff, and any other operation
that does not work on the local copy only.

That's not a joke, it's not made up. I am honestly not aware
of any single operation, not even artificial scenarios, where
git performs worse than svn.

For me the major selling point for git is not that it enables
fancy workflows beyond what is possible with svn (which it
obviously does) but that it can do whatever svn can do, only
_much_ better.

Andre'

Re: Goals for 2.1

[Andre Poenitz]

On Wed, May 04, 2011 at 05:27:36PM +0200, Tommaso Cucinotta wrote:
> Il 04/05/2011 17:16, Rob Oakes ha scritto:
> >
> >>Software bloat is a term used to describe the tendency of newer computer
> >>programs to have a larger installation footprint, or have many unnecessary
> >>features that are not used by end users, or just generally use more system
> >>resources than necessary, while offering little or no benefit to its users.
> [...]
> >But I'm all for helping to reduce the memory footprint and optimizing code, 
> >but I think we should think carefully before removing existing features.
> 
> On a related note, does anyone know how much "bloating" effect comes
> from the use of more and more recent Qt (or other libraries, i..e,
> boost) versions :-) ?

Most certainly not.

And the minimum requirements of LyX on both are not even
remotely "recent".

> Also, if really we have too many features, what about trying to
> embed some modularity in LyX and make them dynamically loadable
> on-demand ?

Overengineered extra code to maintain.

Plugin systemis only (or rather, "at most") make sense if there's
a decent chance to have third parties creating plugins that are
not maintained/distributed with the main product.

For LyX, assuming a probability of zero for that case seems to be
a good first approximation.

> (i.e., dynamically linked libraries/plugins loaded on
> demand) Or, confine some features into external tools launched on
> demand, as opposed to have it integrated into the main code ? (e.g.,
> what is the current implementation model for the "Compare Document"
> feature ? Is it "integrated" in LyX, or does it call an external
> program ?)

The maintenance effort will outweigh any potential benefits by
several orders of magnitude.

> But, first of all maybe we need clear measurements for assessing
> whether or not any of the above is really necessary.

I don't think it's worthwhile to spend time to come to obvious
conclusions, but I certainly won't stop anyone doing that.

Andre'

Re: SVN mirror of git

[Andre Poenitz]

On Wed, May 04, 2011 at 09:45:04AM -0600, Rob Oakes wrote:

> With all that said, I did have a question regarding our existing
> infrastructure. Whatever model we end up settling on, would it be
> possible to mirror the git master branch to SVN? (Basically the same
> thing we do for the git users, except in reverse.)

git-svn exists, and works sufficiently well to handle "mirror"
repositories.

However, I personally think of it as a means to lower psychological
barriers, allowing to postpone the personal mental switch or to 
overcome technical or political restrictions like the ones you
mentioned, but not as a long-term prefered way of working.

Andre'

Re: Goals for 2.1

[Andre Poenitz]

On Wed, May 04, 2011 at 07:45:44PM +0200, Peter Kümmel wrote:
> On 04.05.2011 14:26, Abdelrazak Younes wrote:
> >On 04/05/2011 00:50, Vincent van Ravesteijn wrote:
> >>Hi everyone,
> >>As a typical start of a new release cycle I want to poll
> >>- what features are a must in the next release;
> >
> >Features:
> >* Git based Embedded LyX.
> 
> Couldn't we "somehow" re-use QtCreators plugins? They have
> a nice plugin-system. Looks a bit inspired by OSGi. Maybe
> Andre is willed and allowed to talk about it.

I can certainly talk about it, and it would be hard to hide
anything anyway. It's Open Source after all ;-}

I think it is conceptually possible to re-use the plugin loader
(just a few hundred lines of code after all), but I would not
recommend it in general, and certainly not for LyX, mainly for
two reason:

  - LyX architecture is still a bit unusual, insofar as the
core drives the gui, not the other way round, so it does
not fit too well into "alien" MVC setups.

  - I don't think there is any need to split LyX into plugins.

"Reusing" the git plugin code on a conceptual level might be in
possible in theory, but given that the implementation only calls
the command line tool, I am fairly sure there won't be much more
practical "reuse" than the lines containing the opening and
closing braces of function bodies in the end ;-}

Sorry to spoil the fun here.

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Tue, May 03, 2011 at 07:23:50PM +0200, Pavel Sanda wrote:
 venom00 wrote:
   The patch looks pretty good now, so I'll put it in my testing tree.
  
  I'm not completely sure of the red highlighting. Red is a color for errors, 
  I'll
  try green, yellow and maybe bold.
  Moreover I want to add the rubber button.
   
   Just a last nitpick: we try to keep the lines shorter than 80 
   characters.
 
 btw is it still worth to keep this rule as the displays are wider and wider?
 what was the rationale behind?

To enable working on the code without line wrapping.

And I think it still makes a lot of sense, as people are known to place
several editor side by side to use the full width of their new screens...

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Tue, May 03, 2011 at 08:43:07PM +0200, Pavel Sanda wrote:
 José Matos wrote:
  There are several reasons associated, we should avoid to nest too much our 
  code, if we have a 5 nested levels it becomes increasingly difficult to 
  read 
  the code.
 
 i didnt want to use 5 nested levels.
 
  With widespread pages it is difficult to read any text, be it code or 
  literature.
  
 
 well i dont read the code as a text. for example the second case
 looks much more usefull for me, since its 2x smaller in vertical
 sense and my eyes go through the code faster.
 
 compare these two:
   connect(table, SIGNAL(rowsChanged(int)),
   rowsSB, SLOT(setValue(int)));
   connect(table, SIGNAL(colsChanged(int)),
   columnsSB, SLOT(setValue(int)));
   connect(rowsSB, SIGNAL(valueChanged(int)),
   table, SLOT(setNumberRows(int)));
   connect(columnsSB, SIGNAL(valueChanged(int)),
   table, SLOT(setNumberColumns(int)));
   connect(rowsSB, SIGNAL(valueChanged(int)),
   this, SLOT(change_adaptor()));
   connect(columnsSB, SIGNAL(valueChanged(int)),
   this, SLOT(columnsChanged(int)) );
   connect(valignCO, SIGNAL(highlighted(QString)),
   this, SLOT(change_adaptor()));
   connect(halignED, SIGNAL(textChanged(QString)),
   this, SLOT(change_adaptor()));
   connect(decorationCO, SIGNAL(activated(int)),
   this, SLOT(decorationChanged(int)));
 
 and
 
   connect(table, SIGNAL(rowsChanged(int)), rowsSB, SLOT(setValue(int)));
   connect(table, SIGNAL(colsChanged(int)), columnsSB, 
 SLOT(setValue(int)));
   connect(rowsSB, SIGNAL(valueChanged(int)), table, 
 SLOT(setNumberRows(int)));
   connect(columnsSB, SIGNAL(valueChanged(int)), table, 
 SLOT(setNumberColumns(int)));
   connect(rowsSB, SIGNAL(valueChanged(int)), this, 
 SLOT(change_adaptor()));
   connect(columnsSB, SIGNAL(valueChanged(int)), this, 
 SLOT(columnsChanged(int)) );
   connect(valignCO, SIGNAL(highlighted(QString)), this, 
 SLOT(change_adaptor()));
   connect(halignED, SIGNAL(textChanged(QString)), this, 
 SLOT(change_adaptor()));
   connect(decorationCO, SIGNAL(activated(int)), this, 
 SLOT(decorationChanged(int)));

Five out of the last seven lines wrap for me even when reading mail.
That makes reading patches harder (and that's even something I still do)

The last three would not if 'this, ' were omitted (that works)

[...and none would be needed if it were written as

connect(table, 2rowsChanged(int), rowsSB, 1setValue(int));
connect(table, 2colsChanged(int), columnsSB, 1setValue(int));
connect(rowsSB, 2valueChanged(int), table, 1setNumberRows(int));
connect(columnsSB, 2valueChanged(int), table, 
1setNumberColumns(int));
connect(rowsSB, 2valueChanged(int), this, 1change_adaptor());
connect(columnsSB, 2valueChanged(int), this, 1columnsChanged(int));
connect(valignCO, 2highlighted(QString),  this, 
1change_adaptor());
connect(halignED, 2textChanged(QString),  this, 
1change_adaptor());
connect(decorationCO, 2activated(int), this, 
1decorationChanged(int));

- but I guess I'd better not propose that ;-)]

  I don't care so much about the 80 chars limit but certainly we should set 
  on 
  some limit and try to follow for the reasons above.
 
 100? :)

Qt has 100.

I personally still prefer to have two editors side-by-side on the laptop and
three on the normal screen.

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Tue, May 03, 2011 at 09:43:40PM +0200, venom00 wrote:
 We need a limit, 100 is perfect IMSO [1].
 
 venom00 (is sure someone here is still developing on terminal)

Terminal or not (which I do use around 50% of the time) is not the full
picture, as one can have split editors in some IDEs, too (and that's
perhaps 20% of the remaining 50% for me...)

Anyway, 100 is probably fine, I lost that kind of battle already in
other places ;-|

Andre'

PS:

 [1] In My Selfish Opinion, that is, given my IDE configuration.

/me mumbles something gloomy about if, strncmp, getlogin, venom, 5,
displaysettingspage.cpp, m_page, wrapColumn, setMaximum, and 80...

*mwuahaha*



[Sorry, could not resist. It just came over me ;-)]

Re: Development for LyX 2.1

[Andre Poenitz]

On Tue, May 03, 2011 at 10:10:40PM +0200, Tommaso Cucinotta wrote:
 Il 03/05/2011 16:03, Richard Heck ha scritto:
 On 05/03/2011 09:25 AM, Abdelrazak Younes wrote:
 On 03/05/2011 10:20, Edwin Leuven wrote:
 so let's decide to move to git (we loose nothing and gain some),
 
 Probably unimportant, we just lost some disk space (+30.8% space
 needed for sources)
 
 $ git clone git://gitorious.org/lyx/lyx.git
 $ du -sh lyx
 267Mlyx
 
 $ svn co svn://svn.lyx.org/lyx/lyx-devel/tags/lyx_2_0_0/
 $ du -sh lyx_2_0_0/
 204Mlyx_2_0_0/

*gosh*

So you really payed 63 MB for the full history of LyX sources since
Sep 27, 1999, that historical moment when Lars said New repository
initialized by cvs2svn, giving you the ability to do all your history
browsing, comparing, blaming, ... off-line, and bound only by the speed
of your disk I/O, on a disk that's able to hold at least 460 MB of
data for a build of LyX on top of 200 MB sources?

Let me think...

...harder...

...really hard...


Poof.


Well.

If I were you I'd try to get my money back.

Seriously.


And maybe ask someone to setup a repo without local history, to
recreate the full svn experience. That would come at 123 MB in
total i.e. at a cost of -81 MB for you. 

 [...] Also probably unimportant, is the possible lack of integration with 
 IDEs.

The _POSSIBLE_ lack?

Andre'

PS: Someone who knows a good dentist who can unplug a few teeth from a
table top and re-fit them into a mouth?

Re: Development of a development model

[Andre Poenitz]

On Wed, May 04, 2011 at 01:00:16AM +0200, Vincent van Ravesteijn wrote:
 Hi all,
 
 I think that there is a large enough support for the new development model
 and/or introduction of git to think about how to make things more concrete.
 
 I'm aware there might be some learning curve for developers who are not used
 to git yet, so I'll not rush things.
 
 My plans are to first find out:

First approximations and bold guesses:
 
 - a suitable development model,

Close to the current svn model, but allow people to use branches for
non-trivial feature sets if they like?

 - the place to store the git repo,

Same place as now? Or gitorious?

 - how Trac can be used with the git repo,

No idea. Google finds http://trac-hacks.org/wiki/GitPlugin
I haven't used it.

 - how to organize the cvslog,

Depends on the requirements. Might be not more then a cronjob.

 - how LyX developers can get familiar to the workflow and/or the use of git.

Looks like some are already familiar with it. There are tons of
tutorials like

   http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

I think it's not even worth the effort to have a list of them in
the wiki or such.

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Tue, May 03, 2011 at 07:23:50PM +0200, Pavel Sanda wrote:
> venom00 wrote:
> > > The patch looks pretty good now, so I'll put it in my testing tree.
> > 
> > I'm not completely sure of the red highlighting. Red is a color for errors, 
> > I'll
> > try green, yellow and maybe bold.
> > Moreover I want to add the "rubber" button.
> >  
> > > Just a last nitpick: we try to keep the lines shorter than 80 
> > > characters.
> 
> btw is it still worth to keep this rule as the displays are wider and wider?
> what was the rationale behind?

To enable working on the code without line wrapping.

And I think it still makes a lot of sense, as people are known to place
several editor side by side to use the full width of their new screens...

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Tue, May 03, 2011 at 08:43:07PM +0200, Pavel Sanda wrote:
> José Matos wrote:
> > There are several reasons associated, we should avoid to nest too much our 
> > code, if we have a 5 nested levels it becomes increasingly difficult to 
> > read 
> > the code.
> 
> i didnt want to use 5 nested levels.
> 
> > With widespread pages it is difficult to read any text, be it code or 
> > literature.
> > 
> 
> well i dont read the code as a text. for example the second case
> looks much more usefull for me, since its 2x smaller in vertical
> sense and my eyes go through the code faster.
> 
> compare these two:
>   connect(table, SIGNAL(rowsChanged(int)),
>   rowsSB, SLOT(setValue(int)));
>   connect(table, SIGNAL(colsChanged(int)),
>   columnsSB, SLOT(setValue(int)));
>   connect(rowsSB, SIGNAL(valueChanged(int)),
>   table, SLOT(setNumberRows(int)));
>   connect(columnsSB, SIGNAL(valueChanged(int)),
>   table, SLOT(setNumberColumns(int)));
>   connect(rowsSB, SIGNAL(valueChanged(int)),
>   this, SLOT(change_adaptor()));
>   connect(columnsSB, SIGNAL(valueChanged(int)),
>   this, SLOT(columnsChanged(int)) );
>   connect(valignCO, SIGNAL(highlighted(QString)),
>   this, SLOT(change_adaptor()));
>   connect(halignED, SIGNAL(textChanged(QString)),
>   this, SLOT(change_adaptor()));
>   connect(decorationCO, SIGNAL(activated(int)),
>   this, SLOT(decorationChanged(int)));
> 
> and
> 
>   connect(table, SIGNAL(rowsChanged(int)), rowsSB, SLOT(setValue(int)));
>   connect(table, SIGNAL(colsChanged(int)), columnsSB, 
> SLOT(setValue(int)));
>   connect(rowsSB, SIGNAL(valueChanged(int)), table, 
> SLOT(setNumberRows(int)));
>   connect(columnsSB, SIGNAL(valueChanged(int)), table, 
> SLOT(setNumberColumns(int)));
>   connect(rowsSB, SIGNAL(valueChanged(int)), this, 
> SLOT(change_adaptor()));
>   connect(columnsSB, SIGNAL(valueChanged(int)), this, 
> SLOT(columnsChanged(int)) );
>   connect(valignCO, SIGNAL(highlighted(QString)), this, 
> SLOT(change_adaptor()));
>   connect(halignED, SIGNAL(textChanged(QString)), this, 
> SLOT(change_adaptor()));
>   connect(decorationCO, SIGNAL(activated(int)), this, 
> SLOT(decorationChanged(int)));

Five out of the last seven lines wrap for me even when reading mail.
That makes reading patches harder (and that's even something I still do)

The last three would not if 'this, ' were omitted (that works)

[...and none would be needed if it were written as

connect(table, "2rowsChanged(int)", rowsSB, "1setValue(int)");
connect(table, "2colsChanged(int)", columnsSB, "1setValue(int)");
connect(rowsSB, "2valueChanged(int)", table, "1setNumberRows(int)");
connect(columnsSB, "2valueChanged(int)", table, 
"1setNumberColumns(int)");
connect(rowsSB, "2valueChanged(int)", this, "1change_adaptor()");
connect(columnsSB, "2valueChanged(int)", this, "1columnsChanged(int)");
connect(valignCO, "2highlighted(QString)",  this, 
"1change_adaptor()");
connect(halignED, "2textChanged(QString)",  this, 
"1change_adaptor()");
connect(decorationCO, "2activated(int)", this, 
"1decorationChanged(int)");

- but I guess I'd better not propose that ;-)]

> > I don't care so much about the 80 chars limit but certainly we should set 
> > on 
> > some limit and try to follow for the reasons above.
> 
> 100? :)

Qt has 100.

I personally still prefer to have two editors side-by-side on the laptop and
three on the normal screen.

Andre'

Re: 80 chars rule (was: Too much options in LyX)

[Andre Poenitz]

On Tue, May 03, 2011 at 09:43:40PM +0200, venom00 wrote:
> We need a limit, 100 is perfect IMSO [1].
> 
> venom00 (is sure someone here is still developing on terminal)

Terminal or not (which I do use around 50% of the time) is not the full
picture, as one can have split editors in some IDEs, too (and that's
perhaps 20% of the remaining 50% for me...)

Anyway, 100 is probably fine, I lost that kind of battle already in
other places ;-|

Andre'

PS:

> [1] In My Selfish Opinion, that is, given my IDE configuration.

/me mumbles something gloomy about if, strncmp, getlogin, venom, 5,
displaysettingspage.cpp, m_page, wrapColumn, setMaximum, and 80...

*mwuahaha*



[Sorry, could not resist. It just came over me ;-)]

Re: Development for LyX 2.1

[Andre Poenitz]

On Tue, May 03, 2011 at 10:10:40PM +0200, Tommaso Cucinotta wrote:
> Il 03/05/2011 16:03, Richard Heck ha scritto:
> >On 05/03/2011 09:25 AM, Abdelrazak Younes wrote:
> >>On 03/05/2011 10:20, Edwin Leuven wrote:
> >>>so let's decide to move to git (we loose nothing and gain some),
> 
> Probably unimportant, we just lost some disk space (+30.8% space
> needed for sources)
> 
> $ git clone git://gitorious.org/lyx/lyx.git
> $ du -sh lyx
> 267Mlyx
> 
> $ svn co svn://svn.lyx.org/lyx/lyx-devel/tags/lyx_2_0_0/
> $ du -sh lyx_2_0_0/
> 204Mlyx_2_0_0/

*gosh*

So you really payed 63 MB for the full history of LyX sources since
Sep 27, 1999, that historical moment when Lars said "New repository
initialized by cvs2svn", giving you the ability to do all your history
browsing, comparing, blaming, ... off-line, and bound only by the speed
of your disk I/O, on a disk that's able to hold at least 460 MB of
data for a build of LyX on top of 200 MB sources?

Let me think...

...harder...

...really hard...


Poof.


Well.

If I were you I'd try to get my money back.

Seriously.


And maybe ask someone to setup a repo without local history, to
recreate the full svn experience. That would come at 123 MB in
total i.e. at a cost of -81 MB for you. 

> [...] Also probably unimportant, is the possible lack of integration with 
> IDEs.

The _POSSIBLE_ lack?

Andre'

PS: Someone who knows a good dentist who can unplug a few teeth from a
table top and re-fit them into a mouth?

Re: Development of a development model

[Andre Poenitz]

On Wed, May 04, 2011 at 01:00:16AM +0200, Vincent van Ravesteijn wrote:
> Hi all,
> 
> I think that there is a large enough support for the new development model
> and/or introduction of git to think about how to make things more concrete.
> 
> I'm aware there might be some learning curve for developers who are not used
> to git yet, so I'll not rush things.
> 
> My plans are to first find out:

First approximations and bold guesses:
 
> - a suitable development model,

Close to the current svn model, but allow people to use branches for
non-trivial feature sets if they like?

> - the place to store the git repo,

Same place as now? Or gitorious?

> - how Trac can be used with the git repo,

No idea. Google finds http://trac-hacks.org/wiki/GitPlugin
I haven't used it.

> - how to organize the cvslog,

Depends on the requirements. Might be not more then a cronjob.

> - how LyX developers can get familiar to the workflow and/or the use of git.

Looks like some are already familiar with it. There are tons of
tutorials like

   http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

I think it's not even worth the effort to have a list of them in
the wiki or such.

Andre'

Re: Development for LyX 2.1

[Andre Poenitz]

On Mon, May 02, 2011 at 08:46:49AM +0200, Vincent van Ravesteijn wrote:
 On 2-5-2011 3:15, Andre Poenitz wrote:
  On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
  [...]
  my fear is also that while the extensive branch usage is superior from
  the geeky point of view, its hindrance for people not so technically
  skilled. do we want only geeks to be around?
  [...]
 
 
 I don't really get this. When used to it, I don't think it is
 technically a very difficult workflow. Second, does that mean
 that the less skilled developers are only allowed to do small
 things and refrain from the larger features because they don't
 know how to use the branches ?

Well, the part I don't get is why suddenly using a version control
system is considered rocket science. It is not. Anybody reading
here will survive.
 
  Very good point. I don't think that's wanted, and I think it would not
  harm if any new workflow wouldn't deviate _needlessly_ from what seemed
  to have worked reasonably well for the project in the past. So even if
  there are new bells and whistles in a potential new tool there is no
  need to require their use on a but we can! base.
 
 I don't propose this based on a because it can base. I saw
 that even a lot of small commits, were either corrected adjusted
 etc. several times.

Indeed. And I think we agree that the ratio of imperfect commits typically
sinks when patches are allowed to mature locally for a day or two
before being published. With svn there's not much choice but to commit
early, in order to be ready for the next hunk of work. With git one can
only commit locally and fix commits later if needed, even after other
local commits. Or just work exactly the same way as with svn...

 How are we gonna decide which feature deserves
 a branch and which doesn't ?

As usual? I.e. the developer who does the work has some say in how
it is done?

[My personal cut-off point for 'normal patches vs branches' in git is
typically around the point where applying the patches creates conflicts
that are not automatically resolved]

 I also don't see how this much deviates from the good old svn
 workflow.

In my opinion not much, if at all, and that's also a reason why I
don't understand the fuzz.

Andre'

Re: Development for LyX 2.1

[Andre Poenitz]

On Mon, May 02, 2011 at 09:04:58AM +, Guenter Milde wrote:
 Do I undestand right, that with Git it would be possible to do this
 corrections/adjustments without spoiling the history -- also if no
 branches are used?

As long as the commits are held locally, you can reorder/merge/split
them at will. Only when you push to the public repository, history
will be set in stone (more or less...).

When using branches (which you are not forced to, unless the global
policy makers dictate it...) you can rearrange pretty much in all
the ways you can think of. Cut bits from one branch, put into onto
another, merge branches, re-order the loose ends, whatever. You can,
it's really useful, but you are not _forced_ to use it.

All in all it's basically a set of parallel worlds. Anything you do
locally is independent of the rest of the world. When you push or pull
you synchronize parts of the universes. One universe might even be
called trunk and look like an svn repo...

 Then, moving to Git would be helpfull even without
 changing the rest of the workflow.

Indeed. As you can pretty much mimic svn behaviour in the global
repo and are locally free to use it like svn, or git without anybody
else noticing, it's uniformally better then svn. 

Andre'

Re: Development for LyX 2.1

[Andre Poenitz]

On Mon, May 02, 2011 at 08:46:49AM +0200, Vincent van Ravesteijn wrote:
> On 2-5-2011 3:15, Andre Poenitz wrote:
> > On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
> >> [...]
> >> my fear is also that while the extensive branch usage is superior from
> >> the geeky point of view, its hindrance for people not so technically
> >> skilled. do we want only geeks to be around?
> >> [...]
> 
> 
> I don't really get this. When used to it, I don't think it is
> technically a very difficult workflow. Second, does that mean
> that the less skilled developers are only allowed to do small
> things and refrain from the larger features because they don't
> know how to use the branches ?

Well, the part I don't get is why suddenly using a version control
system is considered rocket science. It is not. Anybody reading
here will survive.
 
> > Very good point. I don't think that's wanted, and I think it would not
> > harm if any new workflow wouldn't deviate _needlessly_ from what seemed
> > to have worked reasonably well for the project in the past. So even if
> > there are new bells and whistles in a potential new tool there is no
> > need to require their use on a "but we can!" base.
> 
> I don't propose this based on a "because it can" base. I saw
> that even a lot of small commits, were either corrected adjusted
> etc. several times.

Indeed. And I think we agree that the ratio of imperfect commits typically
sinks when patches are allowed to "mature" locally for a day or two
before being "published". With svn there's not much choice but to commit
early, in order to be ready for the next hunk of work. With git one can
only commit locally and fix commits later if needed, even after other
local commits. Or just work exactly the same way as with svn...

> How are we gonna decide which feature deserves
> a branch and which doesn't ?

As usual? I.e. the developer who does the work has some say in how
it is done?

[My personal cut-off point for 'normal patches vs branches' in git is
typically around the point where applying the patches creates conflicts
that are not automatically resolved]

> I also don't see how this much deviates from the good old svn
> workflow.

In my opinion "not much, if at all", and that's also a reason why I
don't understand the fuzz.

Andre'

Re: Development for LyX 2.1

[Andre Poenitz]

On Mon, May 02, 2011 at 09:04:58AM +, Guenter Milde wrote:
> Do I undestand right, that with Git it would be possible to do this
> corrections/adjustments without spoiling the history -- also if no
> branches are used?

As long as the commits are held locally, you can reorder/merge/split
them at will. Only when you "push" to the public repository, history
will be set in stone (more or less...).

When using branches (which you are not forced to, unless the global
policy makers dictate it...) you can rearrange pretty much in all
the ways you can think of. Cut bits from one branch, put into onto
another, merge branches, re-order the loose ends, whatever. You can,
it's really useful, but you are not _forced_ to use it.

All in all it's basically a set of parallel worlds. Anything you do
locally is independent of the rest of the world. When you push or pull
you synchronize parts of the universes. One universe might even be
called "trunk" and look like an svn repo...

> Then, moving to Git would be helpfull even without
> changing the rest of the workflow.

Indeed. As you can pretty much mimic svn behaviour in the global
repo and are locally free to use it like svn, or git without anybody
else noticing, it's uniformally better then svn. 

Andre'

Re: Some stats for 2.0 development

[Andre Poenitz]

On Sat, Apr 30, 2011 at 02:41:55PM +0200, Pavel Sanda wrote:
 hi all,
 
 some stats for 2.0 development.
 (you will need mail client with fixed chars  proper tabs handling).
 
 * commit activity:
 
 Trunk 2.0:   ...
 
 ... 
 [...]
 ... 38 ...
 ...

*gosh*

This makes the release look _really_ ancient.

Andre'

PS: No smiley, in order to not challenge José's claims...

Re: Goals and Milestones for LyX3.0

[Andre Poenitz]

On Mon, May 02, 2011 at 12:58:53AM +0200, Pavel Sanda wrote:
 Peter Kümmel wrote:
  - Less noise in commits: a new feature in SVN sometimes comprises over 20
  commits in
 ..
  The commits are the beats of LyX's development heart, so why kill them.
 
 there is actually something on this.
 
 its good idea that having some final tree where 1 feature=1 commit.

 its blessing when you dig out something in history. it would spare amounts
 of my time when bisecting history to find regression culprits.

For bisecting I found it really useful to have not-so-fat commits. The
bisecting itself is only logarithmic in the number of commits and
automatable, whereas finding the actual bug in the faulty commit is
linear in the size of the commit and typically manual.
 
I don't think there's something wrong with having a big feature in a
dozen commits, as long as all of the intermediate versions are working,
and preferably if the version represent logical steps.

Prepering some infrastructure, maybe some refactoring, the actual
feature work and finally enabling it is not an uncommon pattern. 

By separating the final enabling part from the infrastructure work
which might be directly or indireactly used later use cases like
temporary removal of a feature (testing purposes or whatever) are
covered, too.

So I would not be too restrictive when selecting the True Workflow.

 on the other i find the above beats important for life of the
 community around dev list, so whatever dev model we adopt some
 git-commit mailing list where things go imeddiately not waiting for
 some final merged or approval feature-commit is must-have imho.

That's starting to look a bit over-engineered and the need to implement
an out-of-band heartbeat notification scheme might be a problem of the
primary approach then. It's incidentally less prominent in a 1
feature = a reasonable smallish number of commits...

Andre'

Re: Development for LyX 2.1

[Andre Poenitz]

On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
 [...]
 my fear is also that while the extensive branch usage is superior from
 the geeky point of view, its hindrance for people not so technically
 skilled. do we want only geeks to be around?
 [...]

Very good point. I don't think that's wanted, and I think it would not
harm if any new workflow wouldn't deviate _needlessly_ from what seemed
to have worked reasonably well for the project in the past. So even if
there are new bells and whistles in a potential new tool there is no
need to require their use on a but we can! base.

Andre'

Re: Some stats for 2.0 development

[Andre Poenitz]

On Sat, Apr 30, 2011 at 02:41:55PM +0200, Pavel Sanda wrote:
> hi all,
> 
> some stats for 2.0 development.
> (you will need mail client with fixed chars & proper tabs handling).
> 
> * commit activity:
> 
> Trunk 2.0:   ...
> 
> ... 
> [...]
> ... 38 ...
> ...

*gosh*

This makes the release look _really_ ancient.

Andre'

PS: No smiley, in order to not challenge José's claims...

Re: Goals and Milestones for LyX3.0

[Andre Poenitz]

On Mon, May 02, 2011 at 12:58:53AM +0200, Pavel Sanda wrote:
> Peter Kümmel wrote:
> >> - Less noise in commits: a new feature in SVN sometimes comprises over 20
> >> commits in
> ..
> > The commits are the beats of LyX's development heart, so why kill them.
> 
> there is actually something on this.
> 
> its good idea that having some "final" tree where 1 feature=1 commit.

> its blessing when you dig out something in history. it would spare amounts
> of my time when bisecting history to find regression culprits.

For bisecting I found it really useful to have not-so-fat commits. The
bisecting itself is only logarithmic in the number of commits and
automatable, whereas finding the actual bug in the faulty commit is
linear in the size of the commit and typically manual.
 
I don't think there's something wrong with having a big feature in a
dozen commits, as long as all of the intermediate versions are working,
and preferably if the version represent "logical steps".

Prepering some infrastructure, maybe some refactoring, the actual
feature work and finally enabling it is not an uncommon pattern. 

By separating the final "enabling" part from the infrastructure work
which might be directly or indireactly used later use cases like
"temporary removal of a feature" (testing purposes or whatever) are
covered, too.

So I would not be too restrictive when selecting the "True Workflow".

> on the other i find the above "beats" important for life of the
> community around dev list, so whatever dev model we adopt some
> git-commit mailing list where things go imeddiately not waiting for
> some final merged or approval feature-commit is must-have imho.

That's starting to look a bit over-engineered and the need to implement
an "out-of-band heartbeat notification scheme" might be a problem of the
primary approach then. It's incidentally less prominent in a "1
feature = a reasonable smallish number of commits"...

Andre'

Re: Development for LyX 2.1

[Andre Poenitz]

On Mon, May 02, 2011 at 12:58:59AM +0200, Pavel Sanda wrote:
> [...]
> my fear is also that while the extensive branch usage is superior from
> the geeky point of view, its hindrance for people not so technically
> skilled. do we want only geeks to be around?
> [...]

Very good point. I don't think that's wanted, and I think it would not
harm if any new workflow wouldn't deviate _needlessly_ from what seemed
to have worked reasonably well for the project in the past. So even if
there are new bells and whistles in a potential new tool there is no
need to require their use on a "but we can!" base.

Andre'

Re: Development for LyX 2.1

[Andre Poenitz]

On Thu, Apr 28, 2011 at 04:31:08PM +0200, Tommaso Cucinotta wrote:
 Il 26/04/2011 20:14, Julien Rioux ha scritto:
 I don't feel the need to move to git. At all.
 
 I'm seeing 2 discussions merged, in this thread:
 1) what development model to use (how many branches, what  how
 often to commit where, what  how often to release, etc.)
 2) what development tools to use to implement (the proposed changes to) 1).
 
 AFAICS vfr is actually asking for a lower number of merges into
 trunk, with more testing made on alternate experimental branches,
 till the features are rock stable, then merge them as a single (or a
 reduced number of) commit. AFAICS, this can be done with svn as well
 as with git.

Can merges be done somehow with svn? - perhaps.

Can be done easily, as part of the normal workflow? - definitely not.

Anyway, I don't think heavy use of branches is required or needed with
git. I am currently involved with two largish projects using git, one
near the branches everywhere extreme and the other close to the
history should be linear end, and I pretty much prefer the latter, i.e.
we typically rebase small-to-medium-sized patch sets before pushing to
the 'master' repository, and only merge big stuff that cannot easily be
rebased or is a real merge with another public branch from the same
repository.

The big advantage of git for me is the ease with which local work is
handled, i.e. what happens in the n times 8/n hours between the n dayly
pushes, like work on X - see that an unrelated two-liner is needed
somewhere, stash, local commit, pop stash, go on with X. This saves so
much time that I have a hard time to see how anybody who has used svn
and git in earnest for a few days would vote svn in this kind of
discussion.

Andre'

Re: Too much options in LyX

[Andre Poenitz]

Hi.

On Wed, Apr 27, 2011 at 02:07:55PM +0200, venom00 wrote:
  +void GuiDocument::hideView() {
  +   Dialog::hideView();
  +   // Reset the search box
  +   this-docPS-resetSearch();
  +}

Style nits: { on a separate line for the function body, and this-
seems superfluous.

  +   // Configure tree
  list_-setRootIsDecorated(false);
  list_-setColumnCount(1);
  list_-header()-hide();
  @@ -43,14 +54,28 @@
  list_-header()-setStretchLastSection(false);
  list_-setMinimumSize(list_-viewport()-size());
   
  +
  connect(list_, SIGNAL(currentItemChanged(QTreeWidgetItem*,

Was the extra empty line intended?

  +void PanelStack::filterChanged(QString const  search) {
  +   bool enable_all = search.length() == 0;

Perhaps clearer:

bool enable_all = search.isEmpty();  

  +   // Try to cast to the most common widgets and
  looks in it's content by each
  +   // It's bad OOP, it would be nice to have a
  QWidget::toString() overloaded by
  +   // each widget, but this would require to change
  Qt or subclass each widget.

I think there's no need to add comments mentioning unfeasible approaches.

A helper function or two like

   bool matches(QString text)
   {
text.remove('');
return text.contains(search, Qt::CaseInsensitive);
   }

might help to make that block a bit more palatable.

  +void PanelStack::resetSearch() {
  +   this-search_-setText();
  +}

void PanelStack::resetSearch()
{
search_-setText(QString());
}

  ===
  --- src/frontends/qt4/PanelStack.h  (revisione 38474)
  +++ src/frontends/qt4/PanelStack.h  (copia locale)
  @@ -16,6 +16,7 @@
   #include QWidget
   #include QHash
   
  +class QLineEdit;
   class QTreeWidget;
   class QTreeWidgetItem;
   class QStackedWidget;

Someone before you fumbled with the alphabetic order here ;-}

Andre'

PS: Thanks for that other mail.

Re: Development for LyX 2.1

[Andre Poenitz]

On Thu, Apr 28, 2011 at 04:31:08PM +0200, Tommaso Cucinotta wrote:
> Il 26/04/2011 20:14, Julien Rioux ha scritto:
> >I don't feel the need to move to git. At all.
> 
> I'm seeing 2 discussions merged, in this thread:
> 1) what development model to use (how many branches, what & how
> often to commit where, what & how often to release, etc.)
> 2) what development tools to use to implement (the proposed changes to) 1).
> 
> AFAICS vfr is actually asking for a lower number of merges into
> trunk, with more testing made on alternate experimental branches,
> till the features are rock stable, then merge them as a single (or a
> reduced number of) commit. AFAICS, this can be done with svn as well
> as with git.

"Can merges be done somehow with svn"? - perhaps.

"Can be done easily, as part of the normal workflow"? - definitely not.

Anyway, I don't think heavy use of branches is required or needed with
git. I am currently involved with two largish projects using git, one
near the "branches everywhere" extreme and the other close to "the
history should be linear" end, and I pretty much prefer the latter, i.e.
we typically rebase small-to-medium-sized patch sets before pushing to
the 'master' repository, and only merge big stuff that cannot easily be
rebased or is a real merge with another public branch from the same
repository.

The big advantage of git for me is the ease with which "local" work is
handled, i.e. what happens in the n times 8/n hours between the n dayly
pushes, like work on X - see that an unrelated two-liner is needed
somewhere, stash, local commit, pop stash, go on with X. This saves so
much time that I have a hard time to see how anybody who has used svn
and git in earnest for a few days would vote svn in this kind of
discussion.

Andre'

Re: Too much options in LyX

[Andre Poenitz]

Hi.

On Wed, Apr 27, 2011 at 02:07:55PM +0200, venom00 wrote:
> > +void GuiDocument::hideView() {
> > +   Dialog::hideView();
> > +   // Reset the search box
> > +   this->docPS->resetSearch();
> > +}

Style nits: { on a separate line for the function body, and this->
seems superfluous.

> > +   // Configure tree
> > list_->setRootIsDecorated(false);
> > list_->setColumnCount(1);
> > list_->header()->hide();
> > @@ -43,14 +54,28 @@
> > list_->header()->setStretchLastSection(false);
> > list_->setMinimumSize(list_->viewport()->size());
> >  
> > +
> > connect(list_, SIGNAL(currentItemChanged(QTreeWidgetItem*,

Was the extra empty line intended?

> > +void PanelStack::filterChanged(QString const & search) {
> > +   bool enable_all = search.length() == 0;

Perhaps clearer:

bool enable_all = search.isEmpty();  

> > +   // Try to cast to the most common widgets and
> > looks in it's content by each
> > +   // It's bad OOP, it would be nice to have a
> > QWidget::toString() overloaded by
> > +   // each widget, but this would require to change
> > Qt or subclass each widget.

I think there's no need to add comments mentioning unfeasible approaches.

A helper function or two like

   bool matches(QString text)
   {
text.remove('&');
return text.contains(search, Qt::CaseInsensitive);
   }

might help to make that block a bit more palatable.

> > +void PanelStack::resetSearch() {
> > +   this->search_->setText("");
> > +}

void PanelStack::resetSearch()
{
search_->setText(QString());
}

> > ===
> > --- src/frontends/qt4/PanelStack.h  (revisione 38474)
> > +++ src/frontends/qt4/PanelStack.h  (copia locale)
> > @@ -16,6 +16,7 @@
> >  #include 
> >  #include 
> >  
> > +class QLineEdit;
> >  class QTreeWidget;
> >  class QTreeWidgetItem;
> >  class QStackedWidget;

Someone before you fumbled with the alphabetic order here ;-}

Andre'

PS: Thanks for that other mail.

Re: A basic requested feature

[Andre Poenitz]

On Fri, Apr 15, 2011 at 01:16:50AM +0200, Pavel Sanda wrote:
 let me guess, you still develop creator under vim and gdb ;)

For debugging I am really eating my own dog food. Editing is by now
about 50/50 real vim/fakevim, mostly depending on whether I expect
a lot of navigation, tendency falling. Funny times...

Andre'

Re: A basic requested feature

[Andre Poenitz]

On Fri, Apr 15, 2011 at 01:16:50AM +0200, Pavel Sanda wrote:
> let me guess, you still develop creator under vim and gdb ;)

For debugging I am really eating my own dog food. Editing is by now
about 50/50 real vim/fakevim, mostly depending on whether I expect
a lot of navigation, tendency falling. Funny times...

Andre'

Re: A basic requested feature

[Andre Poenitz]

On Thu, Apr 14, 2011 at 05:28:05PM +0200, Pavel Sanda wrote:
 Richard Heck wrote:
  On 04/14/2011 08:36 AM, venom00 wrote:
 
  Suggestion: use Qt Creator. I think it's the best solution.
 
  That's what I use, though under Linux, and it is very good indeed.
 
 and Andre will get drunken tonight ;) p

Whut diedh yu ssayh? Více pivo?

Andre'

Re: #7394, Crash in reverse serach

[Andre Poenitz]

On Fri, Apr 15, 2011 at 12:09:30AM +0200, Peter Kuemmel wrote:
 
  Original-Nachricht 
  Datum: Thu, 14 Apr 2011 23:58:57 +0200
  Von: Enrico Forestieri for...@lyx.org
  An: lyx-devel@lists.lyx.org
  Betreff: Re: #7394, Crash in reverse serach
 
  On Thu, Apr 14, 2011 at 09:53:46PM +0200, Peter Kuemmel wrote:
   This patch
   
   http://www.lyx.org/trac/attachment/ticket/7394/resetAnchor.patch
   
   fixes the crash in
   
   http://www.lyx.org/trac/ticket/7394
   
   But I don't know if it introduces any side effects.
  
  This is not the correct fix, and neither is removing anchor_.clear().
  For example, the assert is avoided but when you shift-click, the entire
  document from the beginning gets selected and not from the cursor
  position. Please, find attached the correct fix.
  
  -- 
 
 Good, you found a fix, could you commit.
 
 But 
   anchor_ = doc_iterator_begin(buffer());
   anchor_.clear();
 
 makes no sense anyway. (It was added by Andre 2008).

Might be equivalent to anchor_ = DocIterator(buffer(), buffer()-inset())?

Seems to have changed a few times:

  8472poenitz   clear();
 31795xxx   push_back(CursorSlice(buffer()-inset()));
 31795xxx   anchor_ = doc_iterator_begin(buffer());
 22898poenitz   anchor_.clear();

So at time 22898 it was not immediately obvious that someone would
touch some additional code in between at time 31795, and even now it's not
clear there was no code between line 3 and 4 at time 31795, after
all there could have been something that was removed later...

Also, 31795 seems innocent:
-   push_back(CursorSlice(inset));
-   anchor_ = doc_iterator_begin(inset.buffer(), inset);
+   push_back(CursorSlice(buffer()-inset()));
+   anchor_ = doc_iterator_begin(buffer());

Andre'

Re: A basic requested feature

[Andre Poenitz]

On Thu, Apr 14, 2011 at 05:28:05PM +0200, Pavel Sanda wrote:
> Richard Heck wrote:
> > On 04/14/2011 08:36 AM, venom00 wrote:
> >>
> >> Suggestion: use Qt Creator. I think it's the best solution.
> >>
> > That's what I use, though under Linux, and it is very good indeed.
> 
> and Andre will get drunken tonight ;) p

Whut diedh yu ssayh? Více pivo?

Andre'

Re: #7394, Crash in reverse serach

[Andre Poenitz]

On Fri, Apr 15, 2011 at 12:09:30AM +0200, Peter Kuemmel wrote:
> 
>  Original-Nachricht 
> > Datum: Thu, 14 Apr 2011 23:58:57 +0200
> > Von: Enrico Forestieri 
> > An: lyx-devel@lists.lyx.org
> > Betreff: Re: #7394, Crash in reverse serach
> 
> > On Thu, Apr 14, 2011 at 09:53:46PM +0200, Peter Kuemmel wrote:
> > > This patch
> > > 
> > > http://www.lyx.org/trac/attachment/ticket/7394/resetAnchor.patch
> > > 
> > > fixes the crash in
> > > 
> > > http://www.lyx.org/trac/ticket/7394
> > > 
> > > But I don't know if it introduces any side effects.
> > 
> > This is not the correct fix, and neither is removing anchor_.clear().
> > For example, the assert is avoided but when you shift-click, the entire
> > document from the beginning gets selected and not from the cursor
> > position. Please, find attached the correct fix.
> > 
> > -- 
> 
> Good, you found a fix, could you commit.
> 
> But 
>   anchor_ = doc_iterator_begin(buffer());
>   anchor_.clear();
> 
> makes no sense anyway. (It was added by Andre 2008).

Might be equivalent to anchor_ = DocIterator(buffer(), buffer()->inset())?

Seems to have changed a few times:

  8472poenitz   clear();
 31795xxx   push_back(CursorSlice(buffer()->inset()));
 31795xxx   anchor_ = doc_iterator_begin(buffer());
 22898poenitz   anchor_.clear();

So at time 22898 it was not immediately obvious that someone would
touch some additional code in between at time 31795, and even now it's not
clear there was no code between line 3 and 4 at time 31795, after
all there could have been something that was removed later...

Also, 31795 seems innocent:
-   push_back(CursorSlice(inset));
-   anchor_ = doc_iterator_begin((), );
+   push_back(CursorSlice(buffer()->inset()));
+   anchor_ = doc_iterator_begin(buffer());

Andre'

Re: compiler warnings in trunk

[Andre Poenitz]

On Sun, Apr 10, 2011 at 10:31:47AM -0400, Richard Heck wrote:
 On 04/09/2011 06:46 PM, Julien Rioux wrote:
 I always saw those two warnings (paraphrased):
 Lexer.cpp:197 anonymous may be used uninitialized

void Lexer::Pimpl::verifyTable()
{
// [...]
if (table -  this line?

Doesn't look like this can ever be uninitialized. But if so,
valgrind should be able to come up with more details.

 Server.cpp:1018 ignoring return value of write(...)

This maybe the result of someone turning on -Wunused-result
or someone adding __attribute__ ((warn_unused_result)) to
the write() declaration.

Checking the return value might actually be a good idea to make
sure all the data was actually written.

Andre'

Re: compiler warnings in trunk

[Andre Poenitz]

On Sun, Apr 10, 2011 at 10:31:47AM -0400, Richard Heck wrote:
> On 04/09/2011 06:46 PM, Julien Rioux wrote:
> >I always saw those two warnings (paraphrased):
> >Lexer.cpp:197  may be used uninitialized

void Lexer::Pimpl::verifyTable()
{
// [...]
if (table <-  this line?

Doesn't look like this can ever be uninitialized. But if so,
valgrind should be able to come up with more details.

> >Server.cpp:1018 ignoring return value of write(...)

This maybe the result of someone turning on -Wunused-result
or someone adding __attribute__ ((warn_unused_result)) to
the write() declaration.

Checking the return value might actually be a good idea to make
sure all the data was actually written.

Andre'

Re: LyX 2.0 and XeTeX: Floats (figures, etc) are not translated

[Andre Poenitz]

On Wed, Mar 23, 2011 at 09:50:25PM +0100, Georg Baum wrote:
 BTW do we have any german speaking mathematician on the list who knows
 how we should deal with the missing 'Satz' theorem (see 
 http://www.lyx.org/trac/ticket/7340)?

Depends a bit on what the actual problem is.

Usually I'd associate 'Satz' with (English) 'Theorem', but (German)
'Theorem' is also sometimes used, not uncommonly for an 'important'
Satz.

But if we just want to match the set {'proposition', 'theorem'} to the
set {'Satz', SomethingElse }, using SomethingElse = 'Theorem' and
matching translating 'Proposition' with 'Satz' does not look wrong.

I have to admit that the last time I read a math paper was a while
ago and the time span since then exceeds my typical span of attention
by a few orders of magnitude, but I don't think 'Proposition' is
heavily used in proper German math papers. I surely wouldn't use it.

Andre'

Re: LyX 2.0 and XeTeX: Floats (figures, etc) are not translated

[Andre Poenitz]

On Wed, Mar 23, 2011 at 09:50:25PM +0100, Georg Baum wrote:
> BTW do we have any german speaking mathematician on the list who knows
> how we should deal with the missing 'Satz' theorem (see 
> http://www.lyx.org/trac/ticket/7340)?

Depends a bit on what the actual problem is.

Usually I'd associate 'Satz' with (English) 'Theorem', but (German)
'Theorem' is also sometimes used, not uncommonly for an 'important'
"Satz".

But if we just want to match the set {'proposition', 'theorem'} to the
set {'Satz', SomethingElse }, using SomethingElse = 'Theorem' and
matching translating 'Proposition' with 'Satz' does not look wrong.

I have to admit that the last time I read a math paper was a while
ago and the time span since then exceeds my typical span of attention
by a few orders of magnitude, but I don't think 'Proposition' is
heavily used in "proper" German math papers. I surely wouldn't use it.

Andre'

Re: r37945 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Fri, Mar 18, 2011 at 09:45:32AM +0100, Jean-Marc Lasgouttes wrote:
 Le 18/03/2011 02:28, rgh...@lyx.org a écrit :
  availableLV-installEventFilter(this);
  selectedLV-installEventFilter(this);
 +selectedHasFocus_ = false;
   }
 
 Thanks. Note that, since this is a constructor, we are supposed to
 initialize this variable (and the others that predated your change)
 using the selectedHasFocus_(false) idiom. I am not sure what this
 buys us, though.

Nothing in case of simple types, as they won't be zero-initialized
before entering the constructor body. For complex types it saves
the cycles for the default-construction.

Andre'

Re: r37945 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Fri, Mar 18, 2011 at 09:45:32AM +0100, Jean-Marc Lasgouttes wrote:
> Le 18/03/2011 02:28, rgh...@lyx.org a écrit :
> > availableLV->installEventFilter(this);
> > selectedLV->installEventFilter(this);
> >+selectedHasFocus_ = false;
> >  }
> 
> Thanks. Note that, since this is a constructor, we are supposed to
> initialize this variable (and the others that predated your change)
> using the selectedHasFocus_(false) idiom. I am not sure what this
> buys us, though.

Nothing in case of simple types, as they won't be zero-initialized
before entering the constructor body. For complex types it saves
the cycles for the default-construction.

Andre'

Re: Conversion Error

[Andre Poenitz]

On Wed, Mar 16, 2011 at 08:06:10PM +0100, Kornel wrote:
 Am Mittwoch, 16. März 2011 schrieb Rob Oakes:
   What conversion is supposed to be happening in this case? Do you get any
   information on the terminal?
  
  Unfortunately, I haven't got a clue. I'm getting some very strange output
  in the terminal. When I try and convert a different file, I'm getting
  this:
  
  LyX: Unknown InsetLayout tag [around line 124 of file
  /var/folders/bz/bzPXBdDMFdGOuw0oPRPjUk+++TI/-Tmp-/lyx_tmpdir.L62279/conver
  t_layout.d62279 current token: 'charstyle' context: '']
  
  Followed by this:
  
  Error 92 returned from iconv when converting from UCS-4LE to ISO-8859-15:
  Illegal byte sequence
  
  and a long stream of hex:
  
  Converted input: 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b 0x0073 0x0069
  0x0064 0x0065 0x0077 0x0061 0x0079 0x0073 0x0066 0x0069 0x0067 0x0075
  0x0072 0x0065 0x007d 0x000a 0x000a 0x000a 0x0048 0x0061 0x006e 0x006e
  0x0069 0x0062 0x0061 0x006c 0x0020 0x0064 0x0065 0x0070 0x0061 0x0072
  0x0074 0x0065 0x0064 0x0020 0x0068 0x0069 0x0073 0x0020 0x0068 0x006f
  0x006d 0x0065 0x0020 0x0062 0x0061
 
 I cannot much help, but this one is ascii, reading
 
 \end{sidewaysfigure}

But the input seems to be two bytes per letter, so it's not UCS-4LE,
rather UTF-16 or such.

Andre'

Re: Conversion Error

[Andre Poenitz]

On Wed, Mar 16, 2011 at 08:06:10PM +0100, Kornel wrote:
> Am Mittwoch, 16. März 2011 schrieb Rob Oakes:
> > > What conversion is supposed to be happening in this case? Do you get any
> > > information on the terminal?
> > 
> > Unfortunately, I haven't got a clue. I'm getting some very strange output
> > in the terminal. When I try and convert a different file, I'm getting
> > this:
> > 
> > LyX: Unknown InsetLayout tag [around line 124 of file
> > /var/folders/bz/bzPXBdDMFdGOuw0oPRPjUk+++TI/-Tmp-/lyx_tmpdir.L62279/conver
> > t_layout.d62279 current token: 'charstyle' context: '']
> > 
> > Followed by this:
> > 
> > Error 92 returned from iconv when converting from UCS-4LE to ISO-8859-15:
> > Illegal byte sequence
> > 
> > and a long stream of hex:
> > 
> > Converted input: 0x000a 0x005c 0x0065 0x006e 0x0064 0x007b 0x0073 0x0069
> > 0x0064 0x0065 0x0077 0x0061 0x0079 0x0073 0x0066 0x0069 0x0067 0x0075
> > 0x0072 0x0065 0x007d 0x000a 0x000a 0x000a 0x0048 0x0061 0x006e 0x006e
> > 0x0069 0x0062 0x0061 0x006c 0x0020 0x0064 0x0065 0x0070 0x0061 0x0072
> > 0x0074 0x0065 0x0064 0x0020 0x0068 0x0069 0x0073 0x0020 0x0068 0x006f
> > 0x006d 0x0065 0x0020 0x0062 0x0061
> 
> I cannot much help, but this one is ascii, reading
> "
> \end{sidewaysfigure}

But the input seems to be two bytes per letter, so it's not UCS-4LE,
rather UTF-16 or such.

Andre'

Re: r37935 - lyx-devel/trunk/src/insets

[Andre Poenitz]

On Tue, Mar 15, 2011 at 05:28:05PM +0100, Jürgen Spitzmüller wrote:
 All right, but for sure we want to have some documentation in the header 
 files.

Having the documentation in the header is a pretty good way to make
sure it does not get updated. Nobody corrects minor issues in Inset.h
as this means recompilation of half of the project.

Andre'

Re: r37935 - lyx-devel/trunk/src/insets

[Andre Poenitz]

On Tue, Mar 15, 2011 at 05:55:16PM +0100, Jürgen Spitzmüller wrote:
 Vincent van Ravesteijn wrote:
  Usually the IDE has a pretty easy way of navigating to the declaration 
  of a function.
 
 I guess our coding workflow just differs. It is well possible that mine is 
 blatantly amateurish. I don't use an IDE, for example. I just use a (fairly 
 simple) text editor and a terminal. No specific reasons for this, this is 
 probably just the result of how I stumbled into coding.

Even non-IDEs sometimes have a way to set up macros or such. In vim e.g.
(see http://vim.wikia.com/wiki/Easily_switch_between_source_and_header_file)

 map F4 :e %:p:s,.h$,.X123X,:s,.cpp$,.h,:s,.X123X$,.cpp,CR

Slightly bizarre, admittedly...

Andre'

Re: r37935 - lyx-devel/trunk/src/insets

[Andre Poenitz]

On Tue, Mar 15, 2011 at 05:28:05PM +0100, Jürgen Spitzmüller wrote:
> All right, but for sure we want to have some documentation in the header 
> files.

Having the documentation in the header is a pretty good way to make
sure it does not get updated. Nobody corrects minor issues in Inset.h
as this means recompilation of half of the project.

Andre'

Re: r37935 - lyx-devel/trunk/src/insets

[Andre Poenitz]

On Tue, Mar 15, 2011 at 05:55:16PM +0100, Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn wrote:
> > Usually the IDE has a pretty easy way of navigating to the declaration 
> > of a function.
> 
> I guess our coding workflow just differs. It is well possible that mine is 
> blatantly amateurish. I don't use an IDE, for example. I just use a (fairly 
> simple) text editor and a terminal. No specific reasons for this, this is 
> probably just the result of how I stumbled into coding.

Even non-IDEs sometimes have a way to set up macros or such. In vim e.g.
(see http://vim.wikia.com/wiki/Easily_switch_between_source_and_header_file)

 map  :e %:p:s,.h$,.X123X,:s,.cpp$,.h,:s,.X123X$,.cpp,

Slightly bizarre, admittedly...

Andre'

Re: r37859 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Sat, Mar 05, 2011 at 02:45:39PM +0100, kuem...@lyx.org wrote:
 Author: kuemmel
 Date: Sat Mar  5 14:45:39 2011
 New Revision: 37859
 URL: http://www.lyx.org/trac/changeset/37859
 
 Log:
 compile. TODO: review default parameter for replace_all
 
 Modified:
lyx-devel/trunk/src/frontends/qt4/FindAndReplace.h
 
 Modified: lyx-devel/trunk/src/frontends/qt4/FindAndReplace.h
 ==
 --- lyx-devel/trunk/src/frontends/qt4/FindAndReplace.hSat Mar  5 
 12:10:35 2011(r37858)
 +++ lyx-devel/trunk/src/frontends/qt4/FindAndReplace.hSat Mar  5 
 14:45:39 2011(r37859)
 @@ -53,10 +53,14 @@
   );
  
   /// Perform the scope-related buffer switch while searching
 - void findAndReplaceScope(FindAndReplaceOptions  opt);
 + bool findAndReplaceScope(FindAndReplaceOptions  opt, bool replace_all);
  
   /// Collect options from the GUI elements, then perform the search
 - void findAndReplace(bool backwards, bool replace);
 + bool findAndReplace(bool backwards, bool replace, bool replace_all = 
 false);
 +
 + bool findAndReplace(bool casesensitive, bool matchword, bool backwards,
 + bool expandmacros, bool ignoreformat, bool replace,
 + bool keep_case, bool replace_all);

Shouldn't that be some kind of parameter stucture, instead of eight
booleans?

Andre'

Re: r37859 - lyx-devel/trunk/src/frontends/qt4

[Andre Poenitz]

On Sat, Mar 05, 2011 at 02:45:39PM +0100, kuem...@lyx.org wrote:
> Author: kuemmel
> Date: Sat Mar  5 14:45:39 2011
> New Revision: 37859
> URL: http://www.lyx.org/trac/changeset/37859
> 
> Log:
> compile. TODO: review default parameter for replace_all
> 
> Modified:
>lyx-devel/trunk/src/frontends/qt4/FindAndReplace.h
> 
> Modified: lyx-devel/trunk/src/frontends/qt4/FindAndReplace.h
> ==
> --- lyx-devel/trunk/src/frontends/qt4/FindAndReplace.hSat Mar  5 
> 12:10:35 2011(r37858)
> +++ lyx-devel/trunk/src/frontends/qt4/FindAndReplace.hSat Mar  5 
> 14:45:39 2011(r37859)
> @@ -53,10 +53,14 @@
>   );
>  
>   /// Perform the scope-related buffer switch while searching
> - void findAndReplaceScope(FindAndReplaceOptions & opt);
> + bool findAndReplaceScope(FindAndReplaceOptions & opt, bool replace_all);
>  
>   /// Collect options from the GUI elements, then perform the search
> - void findAndReplace(bool backwards, bool replace);
> + bool findAndReplace(bool backwards, bool replace, bool replace_all = 
> false);
> +
> + bool findAndReplace(bool casesensitive, bool matchword, bool backwards,
> + bool expandmacros, bool ignoreformat, bool replace,
> + bool keep_case, bool replace_all);

Shouldn't that be some kind of parameter stucture, instead of eight
booleans?

Andre'

Re: tabular*

[Andre Poenitz]

On Fri, Feb 04, 2011 at 11:27:22AM +0100, Enrico Forestieri wrote:
 On Fri, Feb 04, 2011 at 11:18:22AM +0100, Edwin Leuven wrote:
  Enrico Forestieri for...@lyx.org wrote:
   While you are at it, wouldn't it be better renaming widthED as
   columnWidthED, in order to avoid confusion, and tabularWidthL
   as tabularWidthLA, in order to conform to the naming scheme?
  
  mm, there is little consistency in naming, ComboBoxes are calles CB,
  just like CheckBoxes, sometimes ComboBoxes are called CO just like
  Labels
  
  i'll have a look...
 
 In src/frontends/qt4/README I see:
 
 Widgets should be named like fooXX, where XX is one of the following
 widget types :
 
 CB - check box
 CO - combo box
 ED - line edit
 GB - group box
 LA - label
 LC - LengthCombo
 LV - QListView
 ML - QTextBrowser
 PB - push button
 RB - radio button
 SB - spin box
 SL - slider
 TE - text edit
 TW - tree widget (FIXME: also TV in some files)

I wonder whether it would not save time to just use the expanded names
instead of the abbreviations.

I bet by now more characters have been typed for mails discussing the
topic then it would have taken to just type the names in full from the
beginning ;-}

Andre'

Re: tabular*

[Andre Poenitz]

On Fri, Feb 04, 2011 at 11:27:22AM +0100, Enrico Forestieri wrote:
> On Fri, Feb 04, 2011 at 11:18:22AM +0100, Edwin Leuven wrote:
> > Enrico Forestieri  wrote:
> > > While you are at it, wouldn't it be better renaming widthED as
> > > columnWidthED, in order to avoid confusion, and tabularWidthL
> > > as tabularWidthLA, in order to conform to the naming scheme?
> > 
> > mm, there is little consistency in naming, ComboBoxes are calles CB,
> > just like CheckBoxes, sometimes ComboBoxes are called CO just like
> > Labels
> > 
> > i'll have a look...
> 
> In src/frontends/qt4/README I see:
> 
> Widgets should be named like "fooXX", where XX is one of the following
> widget types :
> 
> CB - check box
> CO - combo box
> ED - line edit
> GB - group box
> LA - label
> LC - LengthCombo
> LV - QListView
> ML - QTextBrowser
> PB - push button
> RB - radio button
> SB - spin box
> SL - slider
> TE - text edit
> TW - tree widget (FIXME: also TV in some files)

I wonder whether it would not save time to just use the expanded names
instead of the abbreviations.

I bet by now more characters have been typed for mails discussing the
topic then it would have taken to just type the names in full from the
beginning ;-}

Andre'

Re: Global list-getters return a copy: example theConverters()

[Andre Poenitz]

On Thu, Jan 20, 2011 at 09:11:52AM -0500, Richard Heck wrote:
 On 01/20/2011 12:34 AM, Andre Poenitz wrote:
 On Thu, Jan 20, 2011 at 06:00:27AM +0100, Peter Kümmel wrote:
 Rich, you know the Graph code much better than me. Is it possible to have
 real const functions to get pathes, or it is necessary to always set
 the visited flag in vertices_. Couldn't the calculation be done in one
 function call which then would be more expensive as consequence.
 It's not needed, it's just a consequence of the current implementation
 IIRC. The 'visited' information should not be part of the 'static' data
 of the graph, but rather a separate temporary structure that's passed
 around as separate parameter.
 
 Unfortunately, we seem to use this as if it were static. This is why
 there is the clear_visited boolean that gets passed into routines
 like getReachable(). See e.g. Converters::importableFormats().
 Perhaps this is just some kind of optimization that could be
 removed? It would be less of an issue if the importableFormats were
 cached. I don't myself see why we shouldn't do that. We must decide
 what formats we can import over and over and over

There are two instances or so where it is called with clear_visited ==
true at the begin of a function and several times with ... == false
later in the same function. That looks like a case for a local
visited vector.

I haven't check whether there are more complicated occurences, but
if the pattern above is the only one used some refactoring seems in
order.

Andre'

Re: Global list-getters return a copy: example theConverters()

[Andre Poenitz]

On Thu, Jan 20, 2011 at 09:11:52AM -0500, Richard Heck wrote:
> On 01/20/2011 12:34 AM, Andre Poenitz wrote:
> >On Thu, Jan 20, 2011 at 06:00:27AM +0100, Peter Kümmel wrote:
> >>Rich, you know the Graph code much better than me. Is it possible to have
> >>real const functions to get pathes, or it is necessary to always set
> >>the visited flag in vertices_. Couldn't the calculation be done in one
> >>function call which then would be more expensive as consequence.
> >It's not needed, it's just a consequence of the current implementation
> >IIRC. The 'visited' information should not be part of the 'static' data
> >of the graph, but rather a separate temporary structure that's passed
> >around as separate parameter.
> >
> Unfortunately, we seem to use this as if it were static. This is why
> there is the clear_visited boolean that gets passed into routines
> like getReachable(). See e.g. Converters::importableFormats().
> Perhaps this is just some kind of optimization that could be
> removed? It would be less of an issue if the importableFormats were
> cached. I don't myself see why we shouldn't do that. We must decide
> what formats we can import over and over and over

There are two instances or so where it is called with clear_visited ==
true at the begin of a function and several times with ... == false
later in the same function. That looks like a case for a local
"visited" vector.

I haven't check whether there are more complicated occurences, but
if the pattern above is the only one used some refactoring seems in
order.

Andre'

Re: Global list-getters return a copy: example theConverters()

[Andre Poenitz]

On Thu, Jan 20, 2011 at 06:00:27AM +0100, Peter Kümmel wrote:
 Rich, you know the Graph code much better than me. Is it possible to have
 real const functions to get pathes, or it is necessary to always set
 the visited flag in vertices_. Couldn't the calculation be done in one
 function call which then would be more expensive as consequence.

It's not needed, it's just a consequence of the current implementation
IIRC. The 'visited' information should not be part of the 'static' data
of the graph, but rather a separate temporary structure that's passed
around as separate parameter.

Andre'

Re: Global list-getters return a copy: example theConverters()

[Andre Poenitz]

On Thu, Jan 20, 2011 at 06:00:27AM +0100, Peter Kümmel wrote:
> Rich, you know the Graph code much better than me. Is it possible to have
> real const functions to get pathes, or it is necessary to always set
> the visited flag in vertices_. Couldn't the calculation be done in one
> function call which then would be more expensive as consequence.

It's not needed, it's just a consequence of the current implementation
IIRC. The 'visited' information should not be part of the 'static' data
of the graph, but rather a separate temporary structure that's passed
around as separate parameter.

Andre'

Re: r37245 - in lyx-devel/trunk: . config

[Andre Poenitz]

On Tue, Jan 18, 2011 at 10:57:04AM +0100, lasgout...@lyx.org wrote:
 Author: lasgouttes
 Date: Tue Jan 18 10:57:03 2011
 New Revision: 37245
 URL: http://www.lyx.org/trac/changeset/37245
 
 Log:
 Rename --enable-profiling to --enable-gprof to pave the way for a configure 
 option for normal profiling
 
 Modified:
lyx-devel/trunk/INSTALL
lyx-devel/trunk/config/lyxinclude.m4
 
 Modified: lyx-devel/trunk/INSTALL
 ==
 --- lyx-devel/trunk/INSTALL   Mon Jan 17 22:49:28 2011(r37244)
 +++ lyx-devel/trunk/INSTALL   Tue Jan 18 10:57:03 2011(r37245)
 @@ -211,7 +211,7 @@
  
  The following options allow to tweak more precisely the generated code:
  
 -  o --enable-profiling instruments the code for use with the gprof
 +  o --enable-gprof instruments the code for use with the gprof
  profiler. The result are only meaningful in conjunction with
  --enable-build-type=release.

Does gprof support still makes much sense in the times of valgrind/callgrind?

Andre'

Re: r37245 - in lyx-devel/trunk: . config

[Andre Poenitz]

On Tue, Jan 18, 2011 at 10:57:04AM +0100, lasgout...@lyx.org wrote:
> Author: lasgouttes
> Date: Tue Jan 18 10:57:03 2011
> New Revision: 37245
> URL: http://www.lyx.org/trac/changeset/37245
> 
> Log:
> Rename --enable-profiling to --enable-gprof to pave the way for a configure 
> option for normal profiling
> 
> Modified:
>lyx-devel/trunk/INSTALL
>lyx-devel/trunk/config/lyxinclude.m4
> 
> Modified: lyx-devel/trunk/INSTALL
> ==
> --- lyx-devel/trunk/INSTALL   Mon Jan 17 22:49:28 2011(r37244)
> +++ lyx-devel/trunk/INSTALL   Tue Jan 18 10:57:03 2011(r37245)
> @@ -211,7 +211,7 @@
>  
>  The following options allow to tweak more precisely the generated code:
>  
> -  o --enable-profiling instruments the code for use with the gprof
> +  o --enable-gprof instruments the code for use with the gprof
>  profiler. The result are only meaningful in conjunction with
>  --enable-build-type=release.

Does gprof support still makes much sense in the times of valgrind/callgrind?

Andre'

Re: Font spacing issue again

[Andre Poenitz]

On Sat, Jan 15, 2011 at 11:35:14AM +0100, Jean-Marc Lasgouttes wrote:
 Le 13 janv. 2011 à 18:44, Andre Poenitz a écrit :
  1) compute the metrics 8 times for a word of 8 letters 2) draw
  letter by letter all the times.  3) or rely on more on Qt widgets
  (i.e. use QTextEdit) instead on doing our thing.
  
  4) Compute the metrics for a word twice, once as a whole, once by
  letter, and interpolate cursor position?
 
 I do not understand why we cannot only cache strings. If one needs to
 place the cursor after the t of metrics (which is not an operation
 repeated often anyway), just compute the length of met and place the
 cursor there. 
 
 What am I missing?

Nothing I think. I just didn't think to the end.

Andre'

Re: Font spacing issue again

[Andre Poenitz]

On Sat, Jan 15, 2011 at 11:35:14AM +0100, Jean-Marc Lasgouttes wrote:
> Le 13 janv. 2011 à 18:44, Andre Poenitz a écrit :
> >> 1) compute the metrics 8 times for a word of 8 letters 2) draw
> >> letter by letter all the times.  3) or rely on more on Qt widgets
> >> (i.e. use QTextEdit) instead on doing our thing.
> > 
> > 4) Compute the metrics for a word twice, once as a whole, once by
> > letter, and interpolate cursor position?
> 
> I do not understand why we cannot only cache strings. If one needs to
> place the cursor after the t of "metrics" (which is not an operation
> repeated often anyway), just compute the length of "met" and place the
> cursor there. 
> 
> What am I missing?

Nothing I think. I just didn't think to the end.

Andre'

Re: Font spacing issue again

[Andre Poenitz]

On Thu, Jan 13, 2011 at 09:07:46AM +0100, Abdelrazak Younes wrote:
 On 01/13/2011 08:48 AM, Pavel Sanda wrote:
 Stephan Witt wrote:
 The metrics cache computes the width of every single character -
 inclusive cacheing of it (to get better performance). But the
 drawing is done with complete text strings and if a font supports
 kerning e.g. it's absolutely correct to respect it on drawing.
 
 LyX cursor positioning simply operates in a parallel universe...
 ... and uses the metrics cache numbers.
 
 See ticket http://www.lyx.org/trac/ticket/6920
 its clearly not just mac os thing. this starts to be currently
 most annoying bug we have and the proper solution probably means
 rewrite the painting routines.
 
 http://www.lyx.org/trac/ticket/7235
 
 There are three solutions:
 
 1) compute the metrics 8 times for a word of 8 letters
 2) draw letter by letter all the times.
 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on
 doing our thing.

4) Compute the metrics for a word twice, once as a whole, once by
letter, and interpolate cursor position?

Andre'

Re: Font spacing issue again

[Andre Poenitz]

On Thu, Jan 13, 2011 at 09:07:46AM +0100, Abdelrazak Younes wrote:
> On 01/13/2011 08:48 AM, Pavel Sanda wrote:
> >Stephan Witt wrote:
> >>The metrics cache computes the width of every single character -
> >>inclusive cacheing of it (to get better performance). But the
> >>drawing is done with complete text strings and if a font supports
> >>kerning e.g. it's absolutely correct to respect it on drawing.
> >>
> >>LyX cursor positioning simply operates in a parallel universe...
> >>... and uses the metrics cache numbers.
> >>
> >>See ticket http://www.lyx.org/trac/ticket/6920
> >its clearly not just mac os thing. this starts to be currently
> >most annoying bug we have and the proper solution probably means
> >rewrite the painting routines.
> >
> >http://www.lyx.org/trac/ticket/7235
> 
> There are three solutions:
> 
> 1) compute the metrics 8 times for a word of 8 letters
> 2) draw letter by letter all the times.
> 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on
> doing our thing.

4) Compute the metrics for a word twice, once as a whole, once by
letter, and interpolate cursor position?

Andre'

Re: r36789 - in lyx-devel/trunk/src: . insets

[Andre Poenitz]

On Thu, Dec 09, 2010 at 06:55:11PM +0100, rgh...@lyx.org wrote:
 Author: rgheck
 Date: Thu Dec  9 18:55:11 2010
 New Revision: 36789
 URL: http://www.lyx.org/trac/changeset/36789
 
 Log:
 Remove support for viewing URLs from hyperlinks. This is a security
 risk, due to our lack of control over the links and the program used to
 view them.

Is that conceptual difference from any other external program?

Andre'

Re: r36789 - in lyx-devel/trunk/src: . insets

[Andre Poenitz]

On Thu, Dec 09, 2010 at 06:55:11PM +0100, rgh...@lyx.org wrote:
> Author: rgheck
> Date: Thu Dec  9 18:55:11 2010
> New Revision: 36789
> URL: http://www.lyx.org/trac/changeset/36789
> 
> Log:
> Remove support for viewing URLs from hyperlinks. This is a security
> risk, due to our lack of control over the links and the program used to
> view them.

Is that conceptual difference from any other external program?

Andre'

Re: PATCH for ticket 7026

[Andre Poenitz]

On Fri, Dec 03, 2010 at 07:33:58AM +0100, Stephan Witt wrote:
 Am 03.12.2010 um 04:36 schrieb Enrico Forestieri:
 
  On Fri, Dec 03, 2010 at 12:44:57AM +0100, Pavel Sanda wrote:
  
  Stephan Witt wrote:
  There is a patch pending from Georg.
  I present it here again and propose to apply it.
  
  The second part of the patch is mine.
  It encapsulates the crucial hasDigit into an ignoreWord() method to
  prepare to solve the FIXME and to propose an alternate implementation.
  
  The latter is not that important...
  
  is Enrico fine with the isDigit part? p
  
  It's becoming a mess. We have isdigit(), isDigit(), isDigitASCII(),
  and now iswdigit() enters the scene.
 
 iswdigit() is POSIX standard for wchar_t arguments - our char_type
 is a typedef of wchar_t. But I don't insist here.

I thought it was a typedef to a 32 bit integer type, even on systems
where wchar_t is only 16?

Andre'

Re: r36663 - lyx-devel/trunk/src

[Andre Poenitz]

On Thu, Dec 02, 2010 at 05:09:48PM -0500, Richard Heck wrote:
 On 12/02/2010 04:54 PM, Vincent van Ravesteijn wrote:
 I read somewhere that stacks are best implemented as deques. Don't ask me
 why now,
 but I think they are slightly cheaper. (I'm sure Andre would have a view
 about this.)
 Some googling gives me:
 
 The C++ Standard, in section 23.1.1, offers some advice on which
 containers to prefer. It says:
 
  vector is the type of sequence that should be used by default...
 deque is the data structure of choice when most insertions and
 deletions take place at the beginning or at the end of the sequence.
 
 That's our case: It's being used as a stack, so insertions and
 deletions always take place at the end.
 
 I guess the advantage to a deque here is that it doesn't allow you
 to do things you shouldn't be doing,
 like random access.

A deque is more complicated (usually some kind of list of blocks of
data), and it does provide random access. I don't think it's a good
default choice to implement a stack, but I've seen such recommendation,
too. Even some big guns were claiming for a while that deque is
uniformly better then vector as it has the same asymptotic behaviour
everywhere and additionally allows insertion/deletion at the begin.
This line of argumentation completely ignores the constant overhead.

Andre'

Re: r36663 - lyx-devel/trunk/src

[Andre Poenitz]

On Fri, Dec 03, 2010 at 08:58:32PM +0100, Pavel Sanda wrote:
 Andre Poenitz wrote:
  Even some big guns were claiming for a while that deque is
  uniformly better 
 
 could you be more explicit about the source? sutter?

Yes, I believe so.

Andre'

Re: PATCH for ticket 7026

[Andre Poenitz]

On Fri, Dec 03, 2010 at 07:33:58AM +0100, Stephan Witt wrote:
> Am 03.12.2010 um 04:36 schrieb Enrico Forestieri:
> 
> > On Fri, Dec 03, 2010 at 12:44:57AM +0100, Pavel Sanda wrote:
> > 
> >> Stephan Witt wrote:
> >>> There is a patch pending from Georg.
> >>> I present it here again and propose to apply it.
> >>> 
> >>> The second part of the patch is mine.
> >>> It encapsulates the crucial hasDigit into an ignoreWord() method to
> >>> prepare to solve the FIXME and to propose an alternate implementation.
> >>> 
> >>> The latter is not that important...
> >> 
> >> is Enrico fine with the isDigit part? p
> > 
> > It's becoming a mess. We have isdigit(), isDigit(), isDigitASCII(),
> > and now iswdigit() enters the scene.
> 
> iswdigit() is POSIX standard for wchar_t arguments - our char_type
> is a typedef of wchar_t. But I don't insist here.

I thought it was a typedef to a 32 bit integer type, even on systems
where wchar_t is only 16?

Andre'