Re: Helping out

[Vincent van Ravesteijn]

Hi Amir,

 I downloaded the code base and I want to help out. Does anyone have an
 idea for a simple needed task/bug fix that a newbie to the code can do?

 Right at the moment, we are very much in bugfixing mode prior to the 2.0
 release, so I'd suggest looking here:
    http://www.lyx.org/trac/wiki/BugTrackerHome
 especially at the very bottom, where the bugs targeted at 2.0 are listed.

Have you already thought about something you think is interesting to fix/create.

Some suggestions:

1) I thought about making a somewhat more user friendly way of
choosing a document class. Some UI to explain why a certain class is
unavailable, we might think of showing the user whether we have found
a *.layout file, while the TeX class is available, wether there is a
parse error and so on. Also, we want to be able to use specified .cls
files by creating a layout on the fly.

2) A layout editor for creating your own layouts/character
styles/insets and so forth.

3) UI for named sessions, such that you can easily manage related
documents and master/child relations and so on.
http://wiki.lyx.org/Devel/NamedSessions

4) Automatically checking whether included bib files have unicode
characters in them (as this is not supported by bibtex). Then we can
warn the user in time that there might happen strange things when
compiling the document.

Or just tell us what you like/dislike in LyX and we can think of
something useful.

Vincent

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

On Thu, Feb 10, 2011 at 12:34 PM, Pavel Sanda sa...@lyx.org wrote:
 kor...@lyx.org wrote:
 +#define LYX_MAJOR_VERSION ${LYX_MAJOR_VERSION}
 +#define LYX_MINOR_VERSION ${LYX_MINOR_VERSION}

 huh, this didn't come to my mind. now i think scons will suffer from the same 
 problem.
 please is there anybody around using scons to test?

 pavel


Here we go, quickfix against svn trunk for scons attached.
It might be better to generate the minor/major in scons_utils, but i
don't know the impact on this yet.

Didn't test it on trunk, but my backport of this version stuff to
1.6.9 is building fine again on windoze.
/patrick
Index: SConstruct
===
--- SConstruct  (revision 37689)
+++ SConstruct  (working copy)
@@ -49,6 +49,13 @@
 # get version number from configure.ac so that JMarc does
 # not have to change SConstruct during lyx release
 package_version, majmin_ver, lyx_date = utils.getVerFromConfigure(top_src_dir)
+try:
+lyx_major_version = package_version.split('.')[0]
+lyx_minor_version = package_version.split('.')[1]
+except IndexError, e:
+lyx_major_version = majmin_ver[0]
+lyx_minor_version = majmin_ver[1]
+
 package_cygwin_version = '%s-1' % package_version
 boost_version = ['1_34']
 
@@ -1024,6 +1031,10 @@
 'Define to the one symbol short name of this package.'),
 ('#define PACKAGE_VERSION %s' % package_version,
 'Define to the version of this package.'),
+('#define LYX_MAJOR_VERSION %s' % lyx_major_version,
+'Define to the major version of this package.'),
+('#define LYX_MINOR_VERSION %s' % lyx_minor_version,
+'Define to the minor version of this package.'),
 ('#define VERSION_INFO %s' % env['VERSION_INFO'].replace('\n', 
'\\n'),
 'Full version info'),
 ('#define LYX_DIR_VER LYX_DIR_%sx' % majmin_ver,

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

 Here we go, quickfix against svn trunk for scons attached.
Which is erroneous, i missed that we need const int. Please scrap that
last patch from me.

2nd try attached, sorry for the mess.

/patrick
Index: SConstruct
===
--- SConstruct  (revision 37689)
+++ SConstruct  (working copy)
@@ -49,6 +49,13 @@
 # get version number from configure.ac so that JMarc does
 # not have to change SConstruct during lyx release
 package_version, majmin_ver, lyx_date = utils.getVerFromConfigure(top_src_dir)
+try:
+lyx_major_version = package_version.split('.')[0]
+lyx_minor_version = package_version.split('.')[1]
+except IndexError, e:
+lyx_major_version = majmin_ver[0]
+lyx_minor_version = majmin_ver[1]
+
 package_cygwin_version = '%s-1' % package_version
 boost_version = ['1_34']
 
@@ -1024,6 +1031,10 @@
 'Define to the one symbol short name of this package.'),
 ('#define PACKAGE_VERSION %s' % package_version,
 'Define to the version of this package.'),
+('#define LYX_MAJOR_VERSION %d' % int(lyx_major_version),
+'Define to the major version of this package.'),
+('#define LYX_MINOR_VERSION %d' % int(lyx_minor_version),
+'Define to the minor version of this package.'),
 ('#define VERSION_INFO %s' % env['VERSION_INFO'].replace('\n', 
'\\n'),
 'Full version info'),
 ('#define LYX_DIR_VER LYX_DIR_%sx' % majmin_ver,

Re: r37580 - lyx-devel/trunk/development/cmake

[Pavel Sanda]

Patrick Atamaniuk wrote:
  Here we go, quickfix against svn trunk for scons attached.
 Which is erroneous, i missed that we need const int. Please scrap that
 last patch from me.
 
 2nd try attached, sorry for the mess.

control check:
when you build lyx with this patch and save new file, what the first
line of the file?

pavel

Re: Assertion in trunk on Find Advanced

[Richard Heck]

On 02/15/2011 06:54 PM, Pavel Sanda wrote:

Tommaso Cucinotta wrote:

What was recently changed ?

perhaps file format change which went in today.


Missing space. Fixed.

rh

option key not recognized in keybindings (Mac, trunk)

[BH]

On Mac with current trunk, the option key is not recognized for any
keybindings. (The Mac standard is for option-[arrow key] to move the
cursor around by words/paragraphs, so this is a real problem.)

Opening up the shortcuts preferences dialog, I find that all
keybindings that previously were assigned to option now indicate
that they are assigned to control instead (going by the symbol
displayed in the dialog); however, the control key is ignored as
well. Moreover, it is not possible to change the keybindings back to
option using the dialog: trying to assign optionleft to
word-left results in just the left key registering in the dialog.

Note: the option key is also used to enter accents and other
non-standard characters; this use is not affected. It's only LyX's
keybindings that ignore option.

BH

Menus.cpp, #includeQProxyStyle and Qt-4.4

[BH]

Current trunk will not compile for me right now with Qt-4.4, with this error:

/lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
such file or directory

Apparently, Qt-4.4 does not have QProxyStyle, though Qt-4.7 does. If I
comment out that line in Menus.cpp, everything seems to work fine on
Qt-4.4.

BH

r37678 (vfr) broke lyx-devel build on Debian Lenny

[Horst Schirmeier]

Hi,

lyx-devel SVN r37678 (Committer vfr, some Qt-related bugfix) broke the
build process for Debian Lenny (oldstable) because the QProxyStyle class
was introduced in Qt 4.6[1] but Lenny still comes with Qt 4.4.3.  The
LyX 1.6.x branch seems to contain a backport of the very same patch and
therefore doesn't build either.

As this is the only patch preventing a build on Lenny at the moment, I'd
suggest using a workaround (unfortunately I'm not at all into Qt, so I
cannot come up with one myself -- but the Qt docs talk about a
QProxyStyle being a convenience class) -- or introducing a hard
dependency on Qt 4.6 (in both configure.ac and the README/INSTALL
documents).

-- Horst

[1]http://doc.qt.nokia.com/4.6/qproxystyle.html#details

-- 
PGP-Key 0xD40E0E7A

Re: Menus.cpp, #includeQProxyStyle and Qt-4.4

[Jürgen Spitzmüller]

BH wrote:
 Current trunk will not compile for me right now with Qt-4.4, with this
 error:
 
 /lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
 such file or directory

better now?

Jürgen

Re: Menus.cpp, #includeQProxyStyle and Qt-4.4

[Vincent van Ravesteijn]

 Op 16-2-2011 16:51, Jürgen Spitzmüller schreef:

BH wrote:

Current trunk will not compile for me right now with Qt-4.4, with this
error:

/lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
such file or directory

better now?

Jürgen

Thanks,

I was just having a go at it ;).

The code is only needed on Windows, and we supply the newest version of 
Qt with the Windows version.


So, nothing changes due to this commit (except that it can be compiled 
now :)).


Should also be done in branch.

Vincent

Re: r37678 (vfr) broke lyx-devel build on Debian Lenny

[Vincent van Ravesteijn]

 Op 16-2-2011 16:20, Horst Schirmeier schreef:

Hi,

lyx-devel SVN r37678 (Committer vfr, some Qt-related bugfix) broke the
build process for Debian Lenny (oldstable) because the QProxyStyle class
was introduced in Qt 4.6[1] but Lenny still comes with Qt 4.4.3.  The
LyX 1.6.x branch seems to contain a backport of the very same patch and
therefore doesn't build either.

As this is the only patch preventing a build on Lenny at the moment, I'd
suggest using a workaround (unfortunately I'm not at all into Qt, so I
cannot come up with one myself -- but the Qt docs talk about a
QProxyStyle being a convenience class) -- or introducing a hard
dependency on Qt 4.6 (in both configure.ac and the README/INSTALL
documents).

-- Horst

[1]http://doc.qt.nokia.com/4.6/qproxystyle.html#details



Thanks,

This is fixed in r37692.

Vincent

Re: Menus.cpp, #includeQProxyStyle and Qt-4.4

[BH]

On Wed, Feb 16, 2011 at 10:51 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
 BH wrote:
 Current trunk will not compile for me right now with Qt-4.4, with this
 error:

 /lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
 such file or directory

 better now?

Yep -- thanks.

BH

Re: option key not recognized in keybindings (Mac, trunk)

[Pavel Sanda]

BH wrote:
 On Mac with current trunk, the option key is not recognized for any
 keybindings. (The Mac standard is for option-[arrow key] to move the
 cursor around by words/paragraphs, so this is a real problem.)
 
 Opening up the shortcuts preferences dialog, I find that all
 keybindings that previously were assigned to option now indicate
 that they are assigned to control instead (going by the symbol
 displayed in the dialog); however, the control key is ignored as
 well. Moreover, it is not possible to change the keybindings back to
 option using the dialog: trying to assign optionleft to
 word-left results in just the left key registering in the dialog.
 
 Note: the option key is also used to enter accents and other
 non-standard characters; this use is not affected. It's only LyX's
 keybindings that ignore option.

could it be related to http://www.lyx.org/trac/ticket/7292 ?
pavel

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

On Wed, Feb 16, 2011 at 3:24 PM, Pavel Sanda sa...@lyx.org wrote:

 2nd try attached, sorry for the mess.

 control check:
 when you build lyx with this patch and save new file, what the first
 line of the file?

I double checked - with the latter patch we get:
#LyX 1.6 created this file. For more info see http://www.lyx.org/

/patrick

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

 #LyX 1.6 created this file. For more info see http://www.lyx.org/
for the 1.6.9 backport that is. for trunk, i see config.h with correct
integers 2 and 0.
/p

Re: r37580 - lyx-devel/trunk/development/cmake

[Jürgen Spitzmüller]

Patrick Atamaniuk wrote:
  #LyX 1.6 created this file. For more info see http://www.lyx.org/
 
 for the 1.6.9 backport that is. for trunk, i see config.h with correct
 integers 2 and 0.

I'm not sure we should backport this to branch. There will (most probably) be 
one release in that series anyway.

Jürgen

Re: r37580 - lyx-devel/trunk/development/cmake

[Pavel Sanda]

Jürgen Spitzmüller wrote:
 Patrick Atamaniuk wrote:
   #LyX 1.6 created this file. For more info see http://www.lyx.org/
  
  for the 1.6.9 backport that is. for trunk, i see config.h with correct
  integers 2 and 0.
 
 I'm not sure we should backport this to branch. There will (most probably) be 
 one release in that series anyway.

i have the same feeling. if we introduce regressions, theres no much space to
repair it back.

pavel

Re: r37580 - lyx-devel/trunk/development/cmake

[Pavel Sanda]

Patrick Atamaniuk wrote:
 On Wed, Feb 16, 2011 at 3:24 PM, Pavel Sanda sa...@lyx.org wrote:
 
  2nd try attached, sorry for the mess.
 
  control check:
  when you build lyx with this patch and save new file, what the first
  line of the file?
 
 I double checked - with the latter patch we get:
 #LyX 1.6 created this file. For more info see http://www.lyx.org/

i put it into trunk. just after hitting enter i realized i forgot
to give you credits in commit message. sorry for that.

pavel

Re: r37580 - lyx-devel/trunk/development/cmake

[Jürgen Spitzmüller]

Pavel Sanda wrote:
  I'm not sure we should backport this to branch. There will (most
  probably) be  one release in that series anyway.
 
 i have the same feeling. if we introduce regressions, theres no much space
 to repair it back.

Also it seems not of much use. AFAIU the reasoning was to have an identical 
string over minor releases. But the string changes anyway, at least for 
1.6.10.

Jürgen

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

On Wed, Feb 16, 2011 at 6:27 PM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Pavel Sanda wrote:
  I'm not sure we should backport this to branch. There will (most
  probably) be  one release in that series anyway.

 i have the same feeling. if we introduce regressions, theres no much space
 to repair it back.

 Also it seems not of much use. AFAIU the reasoning was to have an identical
 string over minor releases. But the string changes anyway, at least for
 1.6.10.

 Jürgen


I did not want to suggest an official backport, you're absolutely right there.
 Perhaps you like to hear that my company's decision to replace an
Adobe product on Windows with LyX on Mac and Win is in evaluation,
going quite positive so far :-)
 I need that version feature for my company - amongst others like
tabular* or custom defaults, other toolbar icons etc. - so i maintain
an inofficial patch line and just noticed it there first.

Just anything what comes out there and seems to be worthy for 2.x will
get to this list. Appliable and tested against lyx-devel/trunk of
course.
It's just not my day, i confused my testcases when mailing. Again,
sorry if i'm more trouble than neccessary here.

And please, no credits needed for quickfixes, no worries.

/patrick

Re: tabular*

[Pavel Sanda]

Patrick Atamaniuk wrote:
 I need this :-)
 
 One annoying glitch though:
  if i check 'Use long table' and Apply, then the apply button gets
 disabled and stays so. Cannot edit any table setting anymore.
 The table settings are absolutely useless, after longtable has been checked.
 
 1. make a new table
 2. open table settings
 3. check 'use long table'
 4. apply
 5. try to make any other setting or uncheck 'use long table' - it
 won't have an effect
 
 I traced it down to InsetTabular.cpp:4327 , action 75
   case Tabular::SET_TABULAR_WIDTH:
   status.setEnabled(!tabular.rotate   
 !tabular.is_long_tabular
tabular.tabular_valignment == 
 Tabular::LYX_VALIGN_MIDDLE);
   break;
 This is called at lfun_ok calculation from
 InsetParamsDialog::checkWidgets and will set the status to not
 enabled, where get_status stops and the applyPB will be disabled.
 
 'immediate apply' option is not affecting anything either.
 
 I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
 queried at this point and where to avoid this other than to comment
 out above setEnabled call - so no patch from me :(

please push this into bug tracker otherwise it gets forgotten.
pavel

Re: tabular*

[Patrick Atamaniuk]

On Wed, Feb 16, 2011 at 7:13 PM, Pavel Sanda sa...@lyx.org wrote:
 please push this into bug tracker otherwise it gets forgotten.
 pavel


done, #7308

/patrick

Re: hebrew support in lyx 2.0?

[Richman Reuven]

sorry for the delay, i was away, i hope it's not too late:

(installing lyx using yum)
$ yum --version xetex
3.2.28
  Installed: rpm-4.8.1-5.fc14.i686 at 2011-02-07 23:02
  Built: Fedora Project at 2010-08-10 07:43
  Committed: Panu Matilainen pmati...@redhat.com at 2010-08-10

  Installed: yum-3.2.28-5.fc14.noarch at 2011-02-07 23:04
  Built: Fedora Project at 2010-10-05 13:03
  Committed: Seth Vidal skvidal at fedoraproject.org at 2010-10-05

i tried some basic documents with hebrew:

both the following for the standard article class (following the normal
recommendations for setting up culmus fonts for lyx and the keybord
input switching using f12:
% Preview source code

%% LyX 2.0.0beta3 created this file.  For more info, see
http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[hebrew,english]{article}
\usepackage[T1]{fontenc}
\usepackage[cp1255,latin9]{inputenc}
\usepackage{babel}
\begin{document}
\inputencoding{cp1255}%
\inputencoding{latin9}a\inputencoding{cp1255}\R{ש}
\end{document}
and for the hebrew article type with the default document language set
for hebrew:
% Preview source code

%% LyX 2.0.0beta3 created this file.  For more info, see
http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[english,hebrew]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9,cp1255]{inputenc}

\makeatletter
%% Textclass specific LaTeX
commands.
\usepackage{theorem}
\theorembodyfont{\upshape}
\newtheorem{theorem}{\R{משפט}}[section]
\AtBeginDocument{\make@lr\thetheorem}

\makeatother

\usepackage{babel}
\begin{document}
ש\inputencoding{latin9}\L{a}
\end{document}
generate a preview pdf with only the english 'a' (the second example has
it aligned tot he right of the page as it should) and the hebrew font
doesn't show at all :(

(it's kinda odd btw that the second example show a non default lyx
environment as it's what lyx itself shows)

this is as you can see lyx2.0.0beta3 on fedora 14 (with
2.6.35.10-74.fc14.i686, if you want to know specific pacakges i'd be
happy to provide) the viewer is evince 2.32.0 which doesn't seem to have
any problems showing documents with hebrew fonts :S

the second log looks something like:
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
(format=pdflatex 2011.2.8)  16 FEB 2011 22:41
entering extended mode
 %-line parsing enabled.
**newfile1.tex
(./newfile1.tex
LaTeX2e 2005/12/01
Babel v3.8h and hyphenation patterns for english,
usenglishmax, dumylang, noh
yphenation, arabic, basque, bulgarian, coptic, welsh, czech,
slovak, german, ng
erman, danish, esperanto, spanish, catalan, galician, estonian,
farsi, finnish,
 french, greek, monogreek, ancientgreek, croatian, hungarian,
interlingua, ibyc
us, indonesian, icelandic, italian, latin, mongolian, dutch,
norsk, polish, por
tuguese, pinyin, romanian, russian, slovenian, uppersorbian,
serbian, swedish, 
turkish, ukenglish, ukrainian, loaded.

(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2005/09/16 v1.4f Standard LaTeX document
class
(/usr/share/texmf/tex/latex/base/size10.clo
File: size10.clo 2005/09/16 v1.4f Standard LaTeX file (size
option)
)
\c@part=\count79
\c@section=\count80
\c@subsection=\count81
\c@subsubsection=\count82
\c@paragraph=\count83
\c@subparagraph=\count84
\c@figure=\count85
\c@table=\count86
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
) (/usr/share/texmf/tex/latex/base/fontenc.sty
Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
(/usr/share/texmf/tex/latex/base/t1enc.def
File: t1enc.def 2005/09/27 v1.99g Standard LaTeX file
LaTeX Font Info:Redeclaring font encoding T1 on input line
43.
)) (/usr/share/texmf/tex/latex/base/inputenc.sty
Package: inputenc 2006/05/05 v1.1b Input encoding file
\inpenc@prehook=\toks14
\inpenc@posthook=\toks15
(/usr/share/texmf/tex/latex/base/latin9.def
File: latin9.def 2006/05/05 v1.1b Input encoding file
) (/usr/share/texmf/tex/generic/babel/cp1255.def
File: cp1255.def 2004/02/20 v1.1b Hebrew input encoding file
)) (/usr/share/texmf/tex/latex/tools/theorem.sty
Package: theorem 1995/11/23 v2.2c Theorem extension package
(FMi)
\theorem@style=\toks16

Re: hebrew support in lyx 2.0?

[Richman Reuven]

sorry in the previous mail i thought i included it...

Name: tex-fonts-hebrew
Arch: noarch
Version : 0.1
Release : 14.fc12
Size: 222 k
Repo: installed
From repo   : fedora
Summary : Culmus Hebrew fonts support for LaTeX
URL : http://culmus.sf.net
License : GPL+ and LPPL
Description : Support using the Culmus Hebrew fonts in LaTeX.

Name: tex-preview
Arch: noarch
Version : 11.86
Release : 4.fc14
Size: 161 k
Repo: installed
From repo   : fedora
Summary : Preview style files for LaTeX
URL : http://www.gnu.org/software/auctex/
License : GPLv3+
Description : The preview package for LaTeX allows for the
processing of selected
: parts of a LaTeX input file.  This package
extracts indicated pieces
: from a source file (typically displayed equations,
figures and
: graphics) and typesets with their base point at
the (1in,1in) magic
: location, shipping out the individual pieces on
separate pages without
: any page markup.  You can produce either DVI or
PDF files, and options
: exist that will set the page size separately for
each page.  In that
: manner, further processing (as with Ghostscript or
dvipng) will be
: able to work in a single pass.
: 
: The main purpose of this package is the extraction
of certain
: environments (most notably displayed formulas)
from LaTeX sources as
: graphics. This works with DVI files postprocessed
by either Dvips and
: Ghostscript or dvipng, but it also works when you
are using PDFTeX for
: generating PDF files (usually also postprocessed
by Ghostscript).
: 
: The tex-preview package is generated from the
AUCTeX package for
: Emacs.

Name: tex-simplecv
Arch: noarch
Version : 1.6
Release : 8.fc12
Size: 5.4 k
Repo: installed
From repo   : fedora
Summary : A simple latex class for writing curricula vitae
URL :
http://tug.ctan.org/tex-archive/macros/latex/contrib/simplecv/
License : LPPL
Description : The simplecv document class is intended to provide
a simple yet
: elegant way to write your curriculum vitae
(resume). This is a
: repackaging of the |cv| class that has been
available with LyX for a
: long time. The change of name has been made
necessary by the existence
: of another |cv| class on CTAN.

Name: texinfo
Arch: i686
Version : 4.13a
Release : 13.fc14
Size: 1.9 M
Repo: installed
From repo   : updates
Summary : Tools needed to create Texinfo format
documentation files
URL : http://www.gnu.org/software/texinfo/
License : GPLv3+
Description : Texinfo is a documentation system that can produce
both online
: information and printed output from a single
source file. The GNU
: Project uses the Texinfo file format for most of
its documentation.
: 
: Install texinfo if you want a documentation system
for producing both
: online and print documentation from the same
source file and/or if you
: are going to write documentation for the GNU
Project.

Name: texlive
Arch: i686
Version : 2007
Release : 56.fc14
Size: 3.9 M
Repo: installed
From repo   : fedora
Summary : Binaries for the TeX formatting system
URL : http://tug.org/texlive/
License : GPLv2 and BSD and Public Domain and LGPLv2+ and
GPLv2+ and LPPL
Description : TeXLive is an implementation of TeX for Linux or
UNIX systems. TeX takes
: a text file and a set of formatting commands as
input and creates a
: printable file as output. Usually, TeX is used in
conjunction with
: a higher level formatting package like LaTeX or
PlainTeX, since TeX by
: 

Re: tabular*

[Edwin Leuven]

Patrick Atamaniuk ataman...@frobs.net wrote:
 I traced it down to InsetTabular.cpp:4327 , action 75
 This is called at lfun_ok calculation from
 InsetParamsDialog::checkWidgets and will set the status to not
 enabled, where get_status stops and the applyPB will be disabled.

 I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
 queried at this point

docstring GuiTabular::dialogToParams()

returns something like

tabular set-tabular-width 0pt set-pwidth 0pt align-center
set-decimal-point . valign-top  tabular-valign-middle  unset-booktabs
set-top-space none set-bottom-space none set-interline-space none
set-line-left true set-line-right false set-line-top true
set-line-bottom true set-special-column none unset-multicolumn
unset-multirow  unset-rotate-tabular  unset-rotate-cell
unset-longtabular  unset-ltcaption  unset-lthead none unset-lthead
dl_above unset-lthead dl_below unset-ltfirsthead dl_above
unset-ltfirsthead dl_below unset-ltfirsthead none unset-ltfirsthead
empty unset-ltfoot none unset-ltfoot dl_above unset-ltfoot dl_below
unset-ltlastfoot none unset-ltlastfoot dl_above unset-ltlastfoot
dl_below unset-ltlastfoot empty longtabular-align-center

...

so when you check longtable this gets passed to
InsetParamsDialog::checkWidgets which then checks whether
set-tabular-width is enabled (just because it happens to be first in
line), and it won't be and lfun_ok is false

a simple fix is to move

// table width
string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);
if (tabwidth.empty())
tabwidth = 0pt;
setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);

down so that for example set-pwidth will be queried first rather than
set-tabular-width

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?

edwin

Re: tabular*

[Vincent van Ravesteijn]

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?



I guess the logic of getStatus is meant to check whether an lfun with a 
single tabular feature is allowed. Magically, the lfun send by the 
dialog always passed the test.


I would just make it explicit and add an option which says that the lfun 
should always be enabled. It's not nice, but at least it is more clear 
what happens now.


Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp(revision 37694)
+++ src/insets/InsetTabular.cpp(working copy)
@@ -4280,6 +4280,12 @@

 string const s = cmd.getArg(1);
 // FIXME: We only check for the very first argument...
+
+if (s == always-enabled) {
+status.setEnabled(true);
+return true;
+}
+
 int action = Tabular::LAST_ACTION;
 int i = 0;
 for (; tabularFeature[i].action != Tabular::LAST_ACTION; ++i) {
Index: src/frontends/qt4/GuiTabular.cpp
===
--- src/frontends/qt4/GuiTabular.cpp(revision 37694)
+++ src/frontends/qt4/GuiTabular.cpp(working copy)
@@ -408,7 +408,7 @@
 docstring GuiTabular::dialogToParams() const
 {
 // FIXME: We should use Tabular directly.
-string param_str = tabular;
+string param_str = tabular always-enabled;

 // table width
 string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);



edwin

Vincent

Re: tabular*

[Richard Heck]

On 02/16/2011 05:22 PM, Edwin Leuven wrote:

Patrick Atamaniukataman...@frobs.net  wrote:

I traced it down to InsetTabular.cpp:4327 , action 75
This is called at lfun_ok calculation from
InsetParamsDialog::checkWidgets and will set the status to not
enabled, where get_status stops and the applyPB will be disabled.

I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
queried at this point

docstring GuiTabular::dialogToParams()

returns something like

tabular set-tabular-width 0pt set-pwidth 0pt align-center
set-decimal-point . valign-top  tabular-valign-middle  unset-booktabs
set-top-space none set-bottom-space none set-interline-space none
set-line-left true set-line-right false set-line-top true
set-line-bottom true set-special-column none unset-multicolumn
unset-multirow  unset-rotate-tabular  unset-rotate-cell
unset-longtabular  unset-ltcaption  unset-lthead none unset-lthead
dl_above unset-lthead dl_below unset-ltfirsthead dl_above
unset-ltfirsthead dl_below unset-ltfirsthead none unset-ltfirsthead
empty unset-ltfoot none unset-ltfoot dl_above unset-ltfoot dl_below
unset-ltlastfoot none unset-ltlastfoot dl_above unset-ltlastfoot
dl_below unset-ltlastfoot empty longtabular-align-center

...

so when you check longtable this gets passed to
InsetParamsDialog::checkWidgets which then checks whether
set-tabular-width is enabled (just because it happens to be first in
line), and it won't be and lfun_ok is false

a simple fix is to move

// table width
string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);
if (tabwidth.empty())
tabwidth = 0pt;
setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);

down so that for example set-pwidth will be queried first rather than
set-tabular-width

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?

Another option is not to write the set-tabular-width thing if we're 
disabled. Surely we don't depend upon its being there. Simple patch below.


InsetTabular::getStatus() is weird anyway, since it only checks the very 
first argument.


rh

===

Index: src/frontends/qt4/GuiTabular.cpp
===
--- src/frontends/qt4/GuiTabular.cpp(revision 37703)
+++ src/frontends/qt4/GuiTabular.cpp(working copy)
@@ -411,10 +411,12 @@
string param_str = tabular;

// table width
-   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

-   if (tabwidth.empty())
-   tabwidth = 0pt;
-   setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);
+   if (tabularWidthED-isEnabled()) {
+   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

+   if (tabwidth.empty())
+   tabwidth = 0pt;
+   setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);
+   }

// apply the fixed width values
// this must be done before applying the column alignment



edwin

Re: tabular*

[Vincent van Ravesteijn]

 Op 16-2-2011 23:34, Richard Heck schreef:

On 02/16/2011 05:22 PM, Edwin Leuven wrote:

Patrick Atamaniukataman...@frobs.net  wrote:

I traced it down to InsetTabular.cpp:4327 , action 75
This is called at lfun_ok calculation from
InsetParamsDialog::checkWidgets and will set the status to not
enabled, where get_status stops and the applyPB will be disabled.

I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
queried at this point

docstring GuiTabular::dialogToParams()

returns something like

tabular set-tabular-width 0pt set-pwidth 0pt align-center
set-decimal-point . valign-top  tabular-valign-middle  unset-booktabs
set-top-space none set-bottom-space none set-interline-space none
set-line-left true set-line-right false set-line-top true
set-line-bottom true set-special-column none unset-multicolumn
unset-multirow  unset-rotate-tabular  unset-rotate-cell
unset-longtabular  unset-ltcaption  unset-lthead none unset-lthead
dl_above unset-lthead dl_below unset-ltfirsthead dl_above
unset-ltfirsthead dl_below unset-ltfirsthead none unset-ltfirsthead
empty unset-ltfoot none unset-ltfoot dl_above unset-ltfoot dl_below
unset-ltlastfoot none unset-ltlastfoot dl_above unset-ltlastfoot
dl_below unset-ltlastfoot empty longtabular-align-center

...

so when you check longtable this gets passed to
InsetParamsDialog::checkWidgets which then checks whether
set-tabular-width is enabled (just because it happens to be first in
line), and it won't be and lfun_ok is false

a simple fix is to move

// table width
string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

if (tabwidth.empty())
tabwidth = 0pt;
setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);

down so that for example set-pwidth will be queried first rather than
set-tabular-width

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?

Another option is not to write the set-tabular-width thing if we're 
disabled. Surely we don't depend upon its being there. Simple patch 
below.


InsetTabular::getStatus() is weird anyway, since it only checks the 
very first argument.


rh

===

Index: src/frontends/qt4/GuiTabular.cpp
===
--- src/frontends/qt4/GuiTabular.cpp(revision 37703)
+++ src/frontends/qt4/GuiTabular.cpp(working copy)
@@ -411,10 +411,12 @@
string param_str = tabular;

// table width
-   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

-   if (tabwidth.empty())
-   tabwidth = 0pt;
-   setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);
+   if (tabularWidthED-isEnabled()) {
+   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

+   if (tabwidth.empty())
+   tabwidth = 0pt;
+   setParam(param_str, Tabular::SET_TABULAR_WIDTH, 
tabwidth);

+   }

// apply the fixed width values
// this must be done before applying the column alignment



edwin




This is not the right fix.

Imagine you have a longtable in your document. Now you uncheck the 
longtable checkbox, fill in a table width, press Apply. Nothing will 
happen because InsetTabular::getStatus checks for setting the table 
width, while the table is still a longtable.


Vincent

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

[Vincent van Ravesteijn]

 Op 16-2-2011 23:19, for...@lyx.org schreef:

Author: forenr
Date: Wed Feb 16 23:19:49 2011
New Revision: 37704
URL: http://www.lyx.org/trac/changeset/37704

Log:
Don't disable apply button if one (or more) of vertical alignment, rotation,
or long table settings are changed. Fixes bug #7308.

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 22:08:18 2011
(r37703)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 23:19:49 2011
(r37704)
@@ -4323,8 +4323,10 @@
return true;

case Tabular::SET_TABULAR_WIDTH:
-   status.setEnabled(!tabular.rotate   
!tabular.is_long_tabular
- tabular.tabular_valignment == 
Tabular::LYX_VALIGN_MIDDLE);
+   status.setEnabled(tabular.tabular_width.zero()
+   || (!tabular.rotate   !tabular.is_long_tabular
+ tabular.tabular_valignment ==
+   Tabular::LYX_VALIGN_MIDDLE));
break;

case Tabular::SET_DECIMAL_POINT:


This is not correct.

This is basically saying that SET_TABULAR_WIDTH should be allowed for 
longtables, because tabular_width is zero by definition for longtables.


Vincent

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

[Enrico Forestieri]

On Wed, Feb 16, 2011 at 11:57:22PM +0100, Vincent van Ravesteijn wrote:
  Op 16-2-2011 23:19, for...@lyx.org schreef:
 Author: forenr
 Date: Wed Feb 16 23:19:49 2011
 New Revision: 37704
 URL: http://www.lyx.org/trac/changeset/37704
 
 Log:
 Don't disable apply button if one (or more) of vertical alignment, rotation,
 or long table settings are changed. Fixes bug #7308.
 
 Modified:
 lyx-devel/trunk/src/insets/InsetTabular.cpp
 
 Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
 ==
 --- lyx-devel/trunk/src/insets/InsetTabular.cpp  Wed Feb 16 22:08:18 
 2011(r37703)
 +++ lyx-devel/trunk/src/insets/InsetTabular.cpp  Wed Feb 16 23:19:49 
 2011(r37704)
 @@ -4323,8 +4323,10 @@
  return true;
 
  case Tabular::SET_TABULAR_WIDTH:
 -status.setEnabled(!tabular.rotate   
 !tabular.is_long_tabular
 -  tabular.tabular_valignment == 
 Tabular::LYX_VALIGN_MIDDLE);
 +status.setEnabled(tabular.tabular_width.zero()
 +|| (!tabular.rotate   !tabular.is_long_tabular
 +  tabular.tabular_valignment ==
 +Tabular::LYX_VALIGN_MIDDLE));
  break;
 
  case Tabular::SET_DECIMAL_POINT:
 
 This is not correct.

I'm sorry, you're wrong.

 This is basically saying that SET_TABULAR_WIDTH should be allowed
 for longtables, because tabular_width is zero by definition for
 longtables.

It works just fine.

-- 
Enrico

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

[Vincent van Ravesteijn]

 Op 17-2-2011 0:17, Enrico Forestieri schreef:

On Wed, Feb 16, 2011 at 11:57:22PM +0100, Vincent van Ravesteijn wrote:

  Op 16-2-2011 23:19, for...@lyx.org schreef:

Author: forenr
Date: Wed Feb 16 23:19:49 2011
New Revision: 37704
URL: http://www.lyx.org/trac/changeset/37704

Log:
Don't disable apply button if one (or more) of vertical alignment, rotation,
or long table settings are changed. Fixes bug #7308.

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 22:08:18 2011
(r37703)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 23:19:49 2011
(r37704)
@@ -4323,8 +4323,10 @@
return true;

case Tabular::SET_TABULAR_WIDTH:
-   status.setEnabled(!tabular.rotate
!tabular.is_long_tabular
-  tabular.tabular_valignment == 
Tabular::LYX_VALIGN_MIDDLE);
+   status.setEnabled(tabular.tabular_width.zero()
+   || (!tabular.rotate
!tabular.is_long_tabular
+  tabular.tabular_valignment ==
+   Tabular::LYX_VALIGN_MIDDLE));
break;

case Tabular::SET_DECIMAL_POINT:

This is not correct.

I'm sorry, you're wrong.


I'm sorry, I'm right.


This is basically saying that SET_TABULAR_WIDTH should be allowed
for longtables, because tabular_width is zero by definition for
longtables.

It works just fine.

It does not. It allows you to execute inset-modify tabular 
set-tabular-width 7cm for a longtable, and it happily changes the 
table, while this lfun should have been disabled.


Vincent

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:
 Author: vfr
 Date: Thu Feb 17 00:06:43 2011
 New Revision: 37705
 URL: http://www.lyx.org/trac/changeset/37705
 
 Log:
 Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix 
 coming soon)


This patch was working fine. I don't understand why you are doing this
without discussing it with me.

 Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp
 
 Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
 ==
 --- lyx-devel/trunk/src/insets/InsetTabular.cpp   Wed Feb 16 23:19:49 
 2011(r37704)
 +++ lyx-devel/trunk/src/insets/InsetTabular.cpp   Thu Feb 17 00:06:43 
 2011(r37705)
 @@ -4323,10 +4323,8 @@
   return true;
  
   case Tabular::SET_TABULAR_WIDTH:
 - status.setEnabled(tabular.tabular_width.zero()
 - || (!tabular.rotate   !tabular.is_long_tabular
 -  tabular.tabular_valignment ==
 - Tabular::LYX_VALIGN_MIDDLE));
 + status.setEnabled(!tabular.rotate   
 !tabular.is_long_tabular
 +  tabular.tabular_valignment == 
 Tabular::LYX_VALIGN_MIDDLE);
   break;
  
   case Tabular::SET_DECIMAL_POINT:

-- 
Enrico

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

[Vincent van Ravesteijn]

 Op 17-2-2011 0:22, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:

Author: vfr
Date: Thu Feb 17 00:06:43 2011
New Revision: 37705
URL: http://www.lyx.org/trac/changeset/37705

Log:
Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix coming 
soon)


This patch was working fine. I don't understand why you are doing this
without discussing it with me.


Because it's wrong.

Vincent

Re: r37706 - in lyx-devel/trunk/src: frontends/qt4 insets

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:09:29AM +0100, v...@lyx.org wrote:
 Author: vfr
 Date: Thu Feb 17 00:09:29 2011
 New Revision: 37706
 URL: http://www.lyx.org/trac/changeset/37706
 
 Log:
 Fix bug #7308: Table settings dialog broken.

Previous fix was just fine. I am considering to revert this and
apply again the old one.

 Modified:
lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp
lyx-devel/trunk/src/insets/InsetTabular.cpp
 
 Modified: lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp
 ==
 --- lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp  Thu Feb 17 00:06:43 
 2011(r37705)
 +++ lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp  Thu Feb 17 00:09:29 
 2011(r37706)
 @@ -408,7 +408,7 @@
  docstring GuiTabular::dialogToParams() const
  {
   // FIXME: We should use Tabular directly.
 - string param_str = tabular;
 + string param_str = tabular from-dialog;
  
   // table width
   string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);
 
 Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
 ==
 --- lyx-devel/trunk/src/insets/InsetTabular.cpp   Thu Feb 17 00:06:43 
 2011(r37705)
 +++ lyx-devel/trunk/src/insets/InsetTabular.cpp   Thu Feb 17 00:09:29 
 2011(r37706)
 @@ -4278,8 +4278,16 @@
   if (cur.inset() != this || cmd.getArg(0) != tabular) 
   break;
  
 - string const s = cmd.getArg(1);
   // FIXME: We only check for the very first argument...
 + string const s = cmd.getArg(1);
 + // We always enable the lfun if it is coming from the dialog
 + // because the dialog makes sure all the settings are valid,
 + // even though the first argument might not be valid now.
 + if (s == from-dialog) {
 + status.setEnabled(true);
 + return true;
 + }
 +
   int action = Tabular::LAST_ACTION;
   int i = 0;
   for (; tabularFeature[i].action != Tabular::LAST_ACTION; ++i) {

-- 
Enrico

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:22:48AM +0100, Vincent van Ravesteijn wrote:
  Op 17-2-2011 0:22, Enrico Forestieri schreef:
 On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:
 Author: vfr
 Date: Thu Feb 17 00:06:43 2011
 New Revision: 37705
 URL: http://www.lyx.org/trac/changeset/37705
 
 Log:
 Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix 
 coming soon)
 
 This patch was working fine. I don't understand why you are doing this
 without discussing it with me.
 
 Because it's wrong.

You are wrong.

-- 
Enrico

Re: r37706 - in lyx-devel/trunk/src: frontends/qt4 insets

[Vincent van Ravesteijn]

 Op 17-2-2011 0:22, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:09:29AM +0100, v...@lyx.org wrote:

Author: vfr
Date: Thu Feb 17 00:09:29 2011
New Revision: 37706
URL: http://www.lyx.org/trac/changeset/37706

Log:
Fix bug #7308: Table settings dialog broken.

Previous fix was just fine. I am considering to revert this and
apply again the old one.


The previous fix was not fine.

Vincent

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

[Vincent van Ravesteijn]

 Op 17-2-2011 0:23, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:22:48AM +0100, Vincent van Ravesteijn wrote:

  Op 17-2-2011 0:22, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:

Author: vfr
Date: Thu Feb 17 00:06:43 2011
New Revision: 37705
URL: http://www.lyx.org/trac/changeset/37705

Log:
Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix coming 
soon)

This patch was working fine. I don't understand why you are doing this
without discussing it with me.


Because it's wrong.

You are wrong.


I'm not.

Vincent

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:20:49AM +0100, Vincent van Ravesteijn wrote:
  Op 17-2-2011 0:17, Enrico Forestieri schreef:
 On Wed, Feb 16, 2011 at 11:57:22PM +0100, Vincent van Ravesteijn wrote:
   Op 16-2-2011 23:19, for...@lyx.org schreef:
 Author: forenr
 Date: Wed Feb 16 23:19:49 2011
 New Revision: 37704
 URL: http://www.lyx.org/trac/changeset/37704
 
 Log:
 Don't disable apply button if one (or more) of vertical alignment, 
 rotation,
 or long table settings are changed. Fixes bug #7308.
 
 Modified:
 lyx-devel/trunk/src/insets/InsetTabular.cpp
 
 Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
 ==
 --- lyx-devel/trunk/src/insets/InsetTabular.cppWed Feb 16 22:08:18 
 2011(r37703)
 +++ lyx-devel/trunk/src/insets/InsetTabular.cppWed Feb 16 23:19:49 
 2011(r37704)
 @@ -4323,8 +4323,10 @@
return true;
 
case Tabular::SET_TABULAR_WIDTH:
 -  status.setEnabled(!tabular.rotate
 !tabular.is_long_tabular
 - tabular.tabular_valignment == 
 Tabular::LYX_VALIGN_MIDDLE);
 +  status.setEnabled(tabular.tabular_width.zero()
 +  || (!tabular.rotate
 !tabular.is_long_tabular
 + tabular.tabular_valignment ==
 +  Tabular::LYX_VALIGN_MIDDLE));
break;
 
case Tabular::SET_DECIMAL_POINT:
 This is not correct.
 I'm sorry, you're wrong.
 
 I'm sorry, I'm right.

You are only a conceited young man.

 This is basically saying that SET_TABULAR_WIDTH should be allowed
 for longtables, because tabular_width is zero by definition for
 longtables.
 It works just fine.
 
 It does not. It allows you to execute inset-modify tabular
 set-tabular-width 7cm for a longtable, and it happily changes the
 table, while this lfun should have been disabled.

Which has no effect at all.

-- 
Enrico

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:25:54AM +0100, Vincent van Ravesteijn wrote:
  Op 17-2-2011 0:23, Enrico Forestieri schreef:
 On Thu, Feb 17, 2011 at 12:22:48AM +0100, Vincent van Ravesteijn wrote:
   Op 17-2-2011 0:22, Enrico Forestieri schreef:
 On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:
 Author: vfr
 Date: Thu Feb 17 00:06:43 2011
 New Revision: 37705
 URL: http://www.lyx.org/trac/changeset/37705
 
 Log:
 Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix 
 coming soon)
 This patch was working fine. I don't understand why you are doing this
 without discussing it with me.
 
 Because it's wrong.
 You are wrong.
 
 I'm not.

Childish.

-- 
Enrico

Re: r37706 - in lyx-devel/trunk/src: frontends/qt4 insets

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:23:41AM +0100, Vincent van Ravesteijn wrote:
  Op 17-2-2011 0:22, Enrico Forestieri schreef:
 On Thu, Feb 17, 2011 at 12:09:29AM +0100, v...@lyx.org wrote:
 Author: vfr
 Date: Thu Feb 17 00:09:29 2011
 New Revision: 37706
 URL: http://www.lyx.org/trac/changeset/37706
 
 Log:
 Fix bug #7308: Table settings dialog broken.
 Previous fix was just fine. I am considering to revert this and
 apply again the old one.
 
 The previous fix was not fine.

You are still wrong.

-- 
Enrico

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

[Vincent van Ravesteijn]

This is basically saying that SET_TABULAR_WIDTH should be allowed
for longtables, because tabular_width is zero by definition for
longtables.

It works just fine.


It does not. It allows you to execute inset-modify tabular
set-tabular-width 7cm for a longtable, and it happily changes the
table, while this lfun should have been disabled.

Which has no effect at all.


It does.

Vincent

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:29:18AM +0100, Vincent van Ravesteijn wrote:
 
 This is basically saying that SET_TABULAR_WIDTH should be allowed
 for longtables, because tabular_width is zero by definition for
 longtables.
 It works just fine.
 
 It does not. It allows you to execute inset-modify tabular
 set-tabular-width 7cm for a longtable, and it happily changes the
 table, while this lfun should have been disabled.
 Which has no effect at all.
 
 It does.

Good bye, I have better things to do.

-- 
Enrico

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

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 Which has no effect at all.

 It does.

can both of you please come back to this point and in more than one sentence
put down your arguments/analysis?

and if possible no reverts while flaming, otherwise we might have correct code
but two developers left...

thanks,
pavel

Cut long patches to lyx-cvs

[Tommaso Cucinotta]

Hi all,

I'd like to know whether anyone else (apart from myself) has some 
troubles with those so long refactoring/new-features patches entirely 
sent to the lyx-cvs e-mail box.


I'm sure I'm using a so bad e-mail client like Thunderbird, however when 
opening one of those e-mail messages, my Thunderbird can freeze up to 1 
minute sometimes.


If it is not too difficult, I would propose to cut the attached patches 
to a maximum size, and include in the e-mail a URL to the trac that 
instead shows the entire patch for those ones who are interested.


Among those patches raising such an issue, I can remember someones 
involving changes to all .po files, others that recently added some new 
dictionary, and probably also my commit adding xvkbd to the tree.


Thanks,

T.

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 01:09:04AM +0100, Pavel Sanda wrote:
 Vincent van Ravesteijn wrote:
  Which has no effect at all.
 
  It does.
 
 can both of you please come back to this point and in more than one sentence
 put down your arguments/analysis?

I am sorry, this is a behavioural problem. I would not have any problem
discussing and even acknowledging that I could be wrong, but there are ways
to do things and the presuntuous way I cannot stand.

 and if possible no reverts while flaming, otherwise we might have correct code
 but two developers left...

I am not a developer, so you will lose nothing.

-- 
Enrico

Re: Cut long patches to lyx-cvs

[Pavel Sanda]

Tommaso Cucinotta wrote:
 If it is not too difficult, I would propose to cut the attached patches to 
 a maximum size,

+1

JMarc, this should be just one option in the svn hook scripts.

pavel

Re: Cut long patches to lyx-cvs

[Tommaso Cucinotta]

Il 17/02/2011 01:22, Tommaso Cucinotta ha scritto:
I'd like to know whether anyone else (apart from myself) has some 
troubles with those so long refactoring/new-features patches entirely 
sent to the lyx-cvs e-mail box.


just to support the argument: the dictionary e-mail of yesterday was a 
8MB e-mail, and my client didn't freeze for 1 min., but it was at least 
5 min. now. The .po message of Jan 20th was a 3.8MB one.


T.

Re: option key not recognized in keybindings (Mac, trunk)

[BH]

On Wed, Feb 16, 2011 at 11:14 AM, Pavel Sanda sa...@lyx.org wrote:
 BH wrote:
 On Mac with current trunk, the option key is not recognized for any
 keybindings. (The Mac standard is for option-[arrow key] to move the
 cursor around by words/paragraphs, so this is a real problem.)

 Opening up the shortcuts preferences dialog, I find that all
 keybindings that previously were assigned to option now indicate
 that they are assigned to control instead (going by the symbol
 displayed in the dialog); however, the control key is ignored as
 well. Moreover, it is not possible to change the keybindings back to
 option using the dialog: trying to assign optionleft to
 word-left results in just the left key registering in the dialog.

 Note: the option key is also used to enter accents and other
 non-standard characters; this use is not affected. It's only LyX's
 keybindings that ignore option.

 could it be related to http://www.lyx.org/trac/ticket/7292 ?
 pavel

That's definitely the culprit.

Stephan?

BH

Re: option key not recognized in keybindings (Mac, trunk)

[Stephan Witt]

Am 17.02.2011 um 03:31 schrieb BH:

 On Wed, Feb 16, 2011 at 11:14 AM, Pavel Sanda sa...@lyx.org wrote:
 BH wrote:
 On Mac with current trunk, the option key is not recognized for any
 keybindings. (The Mac standard is for option-[arrow key] to move the
 cursor around by words/paragraphs, so this is a real problem.)
 
 Opening up the shortcuts preferences dialog, I find that all
 keybindings that previously were assigned to option now indicate
 that they are assigned to control instead (going by the symbol
 displayed in the dialog); however, the control key is ignored as
 well. Moreover, it is not possible to change the keybindings back to
 option using the dialog: trying to assign optionleft to
 word-left results in just the left key registering in the dialog.
 
 Note: the option key is also used to enter accents and other
 non-standard characters; this use is not affected. It's only LyX's
 keybindings that ignore option.
 
 could it be related to http://www.lyx.org/trac/ticket/7292 ?
 pavel
 
 That's definitely the culprit.
 
 Stephan?

Yes, you're right. I missed that simple test. Sorry.
One is able to use Ctrl-Arrow instead of Option-Arrow
but that's of course not standard on Mac. You said this
is not working for you? Here I can use it.

Anyway, I'll revert the change and think of another solution.
Note: the accents input is broken again after that.

The correct solution is more work. The problem is the merge of 
MetaModifier and AltModifier done by LyX. LyX shouldn't fold both
Modifiers to AltModifier (Option-Key on Mac).

If this distinction is possible the key bindings on mac should
changed for all accented keys from Alt to Meta (if it isn't Meta already).

Stephan

Re: r37687 - in dictionaries/trunk: dicts thes

[Stephan Witt]

Am 16.02.2011 um 01:33 schrieb jo...@lyx.org:

 Author: joost
 Date: Wed Feb 16 01:33:18 2011
 New Revision: 37687
 URL: http://www.lyx.org/trac/changeset/37687
 
 Log:
 create subdirectories for dictionaries and thesaurus
 
 Added:
   dictionaries/trunk/dicts/
   dictionaries/trunk/thes/

Sorry, I was offline for two days...

The name for the subdirectory in the LyX package below the system directory
where LyX is doing the dictionary lookup is dict.
In general I don't like directory renaming on install so much.
I propose to change LyX default lookup accordingly to avoid the SVN move.

Stephan

Index: src/HunspellChecker.cpp
===
--- src/HunspellChecker.cpp (Revision 37706)
+++ src/HunspellChecker.cpp (Arbeitskopie)
@@ -77,7 +77,7 @@
 
/// the location below system/user directory
/// there the aff+dic files lookup will happen
-   const string dictDirectory(void) const { return dict; }
+   const string dictDirectory(void) const { return dicts; }
int maxLookupSelector(void) const { return 3; }
 };
 
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp   (Revision 37706)
+++ src/AspellChecker.cpp   (Arbeitskopie)
@@ -88,7 +88,7 @@
 
/// the location below system/user directory
/// there the rws files lookup will happen
-   const string dictDirectory(void) { return dict; }
+   const string dictDirectory(void) { return dicts; }
/// there the dat+cmap files lookup will happen
const string dataDirectory(void) { return data; }
/// os package directory constants

Re: Helping out

[Vincent van Ravesteijn]

Hi Amir,

>> I downloaded the code base and I want to help out. Does anyone have an
>> idea for a simple needed task/bug fix that a newbie to the code can do?
>>
> Right at the moment, we are very much in bugfixing mode prior to the 2.0
> release, so I'd suggest looking here:
>    http://www.lyx.org/trac/wiki/BugTrackerHome
> especially at the very bottom, where the bugs targeted at 2.0 are listed.

Have you already thought about something you think is interesting to fix/create.

Some suggestions:

1) I thought about making a somewhat more user friendly way of
choosing a document class. Some UI to explain why a certain class is
unavailable, we might think of showing the user whether we have found
a *.layout file, while the TeX class is available, wether there is a
parse error and so on. Also, we want to be able to use specified .cls
files by creating a layout on the fly.

2) A layout editor for creating your own layouts/character
styles/insets and so forth.

3) UI for named sessions, such that you can easily manage related
documents and master/child relations and so on.
http://wiki.lyx.org/Devel/NamedSessions

4) Automatically checking whether included bib files have unicode
characters in them (as this is not supported by bibtex). Then we can
warn the user in time that there might happen strange things when
compiling the document.

Or just tell us what you like/dislike in LyX and we can think of
something useful.

Vincent

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

On Thu, Feb 10, 2011 at 12:34 PM, Pavel Sanda  wrote:
> kor...@lyx.org wrote:
>> +#define LYX_MAJOR_VERSION ${LYX_MAJOR_VERSION}
>> +#define LYX_MINOR_VERSION ${LYX_MINOR_VERSION}
>
> huh, this didn't come to my mind. now i think scons will suffer from the same 
> problem.
> please is there anybody around using scons to test?
>
> pavel
>

Here we go, quickfix against svn trunk for scons attached.
It might be better to generate the minor/major in scons_utils, but i
don't know the impact on this yet.

Didn't test it on trunk, but my backport of this version stuff to
1.6.9 is building fine again on windoze.
/patrick
Index: SConstruct
===
--- SConstruct  (revision 37689)
+++ SConstruct  (working copy)
@@ -49,6 +49,13 @@
 # get version number from configure.ac so that JMarc does
 # not have to change SConstruct during lyx release
 package_version, majmin_ver, lyx_date = utils.getVerFromConfigure(top_src_dir)
+try:
+lyx_major_version = package_version.split('.')[0]
+lyx_minor_version = package_version.split('.')[1]
+except IndexError, e:
+lyx_major_version = majmin_ver[0]
+lyx_minor_version = majmin_ver[1]
+
 package_cygwin_version = '%s-1' % package_version
 boost_version = ['1_34']
 
@@ -1024,6 +1031,10 @@
 'Define to the one symbol short name of this package.'),
 ('#define PACKAGE_VERSION "%s"' % package_version,
 'Define to the version of this package.'),
+('#define LYX_MAJOR_VERSION "%s"' % lyx_major_version,
+'Define to the major version of this package.'),
+('#define LYX_MINOR_VERSION "%s"' % lyx_minor_version,
+'Define to the minor version of this package.'),
 ('#define VERSION_INFO "%s"' % env['VERSION_INFO'].replace('\n', 
'\\n'),
 'Full version info'),
 ('#define LYX_DIR_VER "LYX_DIR_%sx"' % majmin_ver,

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

> Here we go, quickfix against svn trunk for scons attached.
Which is erroneous, i missed that we need const int. Please scrap that
last patch from me.

2nd try attached, sorry for the mess.

/patrick
Index: SConstruct
===
--- SConstruct  (revision 37689)
+++ SConstruct  (working copy)
@@ -49,6 +49,13 @@
 # get version number from configure.ac so that JMarc does
 # not have to change SConstruct during lyx release
 package_version, majmin_ver, lyx_date = utils.getVerFromConfigure(top_src_dir)
+try:
+lyx_major_version = package_version.split('.')[0]
+lyx_minor_version = package_version.split('.')[1]
+except IndexError, e:
+lyx_major_version = majmin_ver[0]
+lyx_minor_version = majmin_ver[1]
+
 package_cygwin_version = '%s-1' % package_version
 boost_version = ['1_34']
 
@@ -1024,6 +1031,10 @@
 'Define to the one symbol short name of this package.'),
 ('#define PACKAGE_VERSION "%s"' % package_version,
 'Define to the version of this package.'),
+('#define LYX_MAJOR_VERSION %d' % int(lyx_major_version),
+'Define to the major version of this package.'),
+('#define LYX_MINOR_VERSION %d' % int(lyx_minor_version),
+'Define to the minor version of this package.'),
 ('#define VERSION_INFO "%s"' % env['VERSION_INFO'].replace('\n', 
'\\n'),
 'Full version info'),
 ('#define LYX_DIR_VER "LYX_DIR_%sx"' % majmin_ver,

Re: r37580 - lyx-devel/trunk/development/cmake

[Pavel Sanda]

Patrick Atamaniuk wrote:
> > Here we go, quickfix against svn trunk for scons attached.
> Which is erroneous, i missed that we need const int. Please scrap that
> last patch from me.
> 
> 2nd try attached, sorry for the mess.

control check:
when you build lyx with this patch and save new file, what the first
line of the file?

pavel

Re: Assertion in trunk on Find Advanced

[Richard Heck]

On 02/15/2011 06:54 PM, Pavel Sanda wrote:

Tommaso Cucinotta wrote:

What was recently changed ?

perhaps file format change which went in today.


Missing space. Fixed.

rh

key not recognized in keybindings (Mac, trunk)

[BH]

On Mac with current trunk, the  key is not recognized for any
keybindings. (The Mac standard is for -[arrow key] to move the
cursor around by words/paragraphs, so this is a real problem.)

Opening up the shortcuts preferences dialog, I find that all
keybindings that previously were assigned to  now indicate
that they are assigned to  instead (going by the symbol
displayed in the dialog); however, the  key is ignored as
well. Moreover, it is not possible to change the keybindings back to
 using the dialog: trying to assign  to
word-left results in just the  key registering in the dialog.

Note: the  key is also used to enter accents and other
non-standard characters; this use is not affected. It's only LyX's
keybindings that ignore .

BH

Menus.cpp, #include and Qt-4.4

[BH]

Current trunk will not compile for me right now with Qt-4.4, with this error:

/lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
such file or directory

Apparently, Qt-4.4 does not have QProxyStyle, though Qt-4.7 does. If I
comment out that line in Menus.cpp, everything seems to work fine on
Qt-4.4.

BH

r37678 (vfr) broke lyx-devel build on Debian Lenny

[Horst Schirmeier]

Hi,

lyx-devel SVN r37678 (Committer vfr, some Qt-related bugfix) broke the
build process for Debian Lenny (oldstable) because the QProxyStyle class
was introduced in Qt 4.6[1] but Lenny still comes with Qt 4.4.3.  The
LyX 1.6.x branch seems to contain a backport of the very same patch and
therefore doesn't build either.

As this is the only patch preventing a build on Lenny at the moment, I'd
suggest using a workaround (unfortunately I'm not at all into Qt, so I
cannot come up with one myself -- but the Qt docs talk about a
QProxyStyle being a "convenience class") -- or introducing a hard
dependency on Qt 4.6 (in both configure.ac and the README/INSTALL
documents).

-- Horst

[1]http://doc.qt.nokia.com/4.6/qproxystyle.html#details

-- 
PGP-Key 0xD40E0E7A

Re: Menus.cpp, #include and Qt-4.4

[Jürgen Spitzmüller]

BH wrote:
> Current trunk will not compile for me right now with Qt-4.4, with this
> error:
> 
> /lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
> such file or directory

better now?

Jürgen

Re: Menus.cpp, #include and Qt-4.4

[Vincent van Ravesteijn]

 Op 16-2-2011 16:51, Jürgen Spitzmüller schreef:

BH wrote:

Current trunk will not compile for me right now with Qt-4.4, with this
error:

/lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
such file or directory

better now?

Jürgen

Thanks,

I was just having a go at it ;).

The code is only needed on Windows, and we supply the newest version of 
Qt with the Windows version.


So, nothing changes due to this commit (except that it can be compiled 
now :)).


Should also be done in branch.

Vincent

Re: r37678 (vfr) broke lyx-devel build on Debian Lenny

[Vincent van Ravesteijn]

 Op 16-2-2011 16:20, Horst Schirmeier schreef:

Hi,

lyx-devel SVN r37678 (Committer vfr, some Qt-related bugfix) broke the
build process for Debian Lenny (oldstable) because the QProxyStyle class
was introduced in Qt 4.6[1] but Lenny still comes with Qt 4.4.3.  The
LyX 1.6.x branch seems to contain a backport of the very same patch and
therefore doesn't build either.

As this is the only patch preventing a build on Lenny at the moment, I'd
suggest using a workaround (unfortunately I'm not at all into Qt, so I
cannot come up with one myself -- but the Qt docs talk about a
QProxyStyle being a "convenience class") -- or introducing a hard
dependency on Qt 4.6 (in both configure.ac and the README/INSTALL
documents).

-- Horst

[1]http://doc.qt.nokia.com/4.6/qproxystyle.html#details



Thanks,

This is fixed in r37692.

Vincent

Re: Menus.cpp, #include and Qt-4.4

[BH]

On Wed, Feb 16, 2011 at 10:51 AM, Jürgen Spitzmüller  wrote:
> BH wrote:
>> Current trunk will not compile for me right now with Qt-4.4, with this
>> error:
>>
>> /lyx-devel/src/frontends/qt4/Menus.cpp:74:23: error: QProxyStyle: No
>> such file or directory
>
> better now?

Yep -- thanks.

BH

Re: key not recognized in keybindings (Mac, trunk)

[Pavel Sanda]

BH wrote:
> On Mac with current trunk, the  key is not recognized for any
> keybindings. (The Mac standard is for -[arrow key] to move the
> cursor around by words/paragraphs, so this is a real problem.)
> 
> Opening up the shortcuts preferences dialog, I find that all
> keybindings that previously were assigned to  now indicate
> that they are assigned to  instead (going by the symbol
> displayed in the dialog); however, the  key is ignored as
> well. Moreover, it is not possible to change the keybindings back to
>  using the dialog: trying to assign  to
> word-left results in just the  key registering in the dialog.
> 
> Note: the  key is also used to enter accents and other
> non-standard characters; this use is not affected. It's only LyX's
> keybindings that ignore .

could it be related to http://www.lyx.org/trac/ticket/7292 ?
pavel

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

On Wed, Feb 16, 2011 at 3:24 PM, Pavel Sanda  wrote:

>> 2nd try attached, sorry for the mess.
>
> control check:
> when you build lyx with this patch and save new file, what the first
> line of the file?

I double checked - with the latter patch we get:
#LyX 1.6 created this file. For more info see http://www.lyx.org/

/patrick

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

> #LyX 1.6 created this file. For more info see http://www.lyx.org/
for the 1.6.9 backport that is. for trunk, i see config.h with correct
integers 2 and 0.
/p

Re: r37580 - lyx-devel/trunk/development/cmake

[Jürgen Spitzmüller]

Patrick Atamaniuk wrote:
> > #LyX 1.6 created this file. For more info see http://www.lyx.org/
> 
> for the 1.6.9 backport that is. for trunk, i see config.h with correct
> integers 2 and 0.

I'm not sure we should backport this to branch. There will (most probably) be 
one release in that series anyway.

Jürgen

Re: r37580 - lyx-devel/trunk/development/cmake

[Pavel Sanda]

Jürgen Spitzmüller wrote:
> Patrick Atamaniuk wrote:
> > > #LyX 1.6 created this file. For more info see http://www.lyx.org/
> > 
> > for the 1.6.9 backport that is. for trunk, i see config.h with correct
> > integers 2 and 0.
> 
> I'm not sure we should backport this to branch. There will (most probably) be 
> one release in that series anyway.

i have the same feeling. if we introduce regressions, theres no much space to
repair it back.

pavel

Re: r37580 - lyx-devel/trunk/development/cmake

[Pavel Sanda]

Patrick Atamaniuk wrote:
> On Wed, Feb 16, 2011 at 3:24 PM, Pavel Sanda  wrote:
> 
> >> 2nd try attached, sorry for the mess.
> >
> > control check:
> > when you build lyx with this patch and save new file, what the first
> > line of the file?
> 
> I double checked - with the latter patch we get:
> #LyX 1.6 created this file. For more info see http://www.lyx.org/

i put it into trunk. just after hitting enter i realized i forgot
to give you credits in commit message. sorry for that.

pavel

Re: r37580 - lyx-devel/trunk/development/cmake

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> > I'm not sure we should backport this to branch. There will (most
> > probably) be  one release in that series anyway.
> 
> i have the same feeling. if we introduce regressions, theres no much space
> to repair it back.

Also it seems not of much use. AFAIU the reasoning was to have an identical 
string over minor releases. But the string changes anyway, at least for 
1.6.10.

Jürgen

Re: r37580 - lyx-devel/trunk/development/cmake

[Patrick Atamaniuk]

On Wed, Feb 16, 2011 at 6:27 PM, Jürgen Spitzmüller  wrote:
> Pavel Sanda wrote:
>> > I'm not sure we should backport this to branch. There will (most
>> > probably) be  one release in that series anyway.
>>
>> i have the same feeling. if we introduce regressions, theres no much space
>> to repair it back.
>
> Also it seems not of much use. AFAIU the reasoning was to have an identical
> string over minor releases. But the string changes anyway, at least for
> 1.6.10.
>
> Jürgen
>

I did not want to suggest an official backport, you're absolutely right there.
 Perhaps you like to hear that my company's decision to replace an
Adobe product on Windows with LyX on Mac and Win is in evaluation,
going quite positive so far :-)
 I need that version feature for my company - amongst others like
tabular* or custom defaults, other toolbar icons etc. - so i maintain
an inofficial patch line and just noticed it there first.

Just anything what comes out there and seems to be worthy for 2.x will
get to this list. Appliable and tested against lyx-devel/trunk of
course.
It's just not my day, i confused my testcases when mailing. Again,
sorry if i'm more trouble than neccessary here.

And please, no credits needed for quickfixes, no worries.

/patrick

Re: tabular*

[Pavel Sanda]

Patrick Atamaniuk wrote:
> I need this :-)
> 
> One annoying glitch though:
>  if i check 'Use long table' and Apply, then the apply button gets
> disabled and stays so. Cannot edit any table setting anymore.
> The table settings are absolutely useless, after longtable has been checked.
> 
> 1. make a new table
> 2. open table settings
> 3. check 'use long table'
> 4. apply
> 5. try to make any other setting or uncheck 'use long table' - it
> won't have an effect
> 
> I traced it down to InsetTabular.cpp:4327 , action 75
>   case Tabular::SET_TABULAR_WIDTH:
>   status.setEnabled(!tabular.rotate &&  
> !tabular.is_long_tabular
>   && tabular.tabular_valignment == 
> Tabular::LYX_VALIGN_MIDDLE);
>   break;
> This is called at lfun_ok calculation from
> InsetParamsDialog::checkWidgets and will set the status to not
> enabled, where get_status stops and the applyPB will be disabled.
> 
> 'immediate apply' option is not affecting anything either.
> 
> I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
> queried at this point and where to avoid this other than to comment
> out above setEnabled call - so no patch from me :(

please push this into bug tracker otherwise it gets forgotten.
pavel

Re: tabular*

[Patrick Atamaniuk]

On Wed, Feb 16, 2011 at 7:13 PM, Pavel Sanda  wrote:
> please push this into bug tracker otherwise it gets forgotten.
> pavel
>

done, #7308

/patrick

Re: hebrew support in lyx 2.0?

[Richman Reuven]

sorry for the delay, i was away, i hope it's not too late:

(installing lyx using yum)
$ yum --version xetex
3.2.28
  Installed: rpm-4.8.1-5.fc14.i686 at 2011-02-07 23:02
  Built: Fedora Project at 2010-08-10 07:43
  Committed: Panu Matilainen  at 2010-08-10

  Installed: yum-3.2.28-5.fc14.noarch at 2011-02-07 23:04
  Built: Fedora Project at 2010-10-05 13:03
  Committed: Seth Vidal  at 2010-10-05

i tried some basic documents with hebrew:

both the following for the standard article class (following the normal
recommendations for setting up culmus fonts for lyx and the keybord
input switching using f12:
% Preview source code

%% LyX 2.0.0beta3 created this file.  For more info, see
http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[hebrew,english]{article}
\usepackage[T1]{fontenc}
\usepackage[cp1255,latin9]{inputenc}
\usepackage{babel}
\begin{document}
\inputencoding{cp1255}%
\inputencoding{latin9}a\inputencoding{cp1255}\R{ש}
\end{document}
and for the hebrew article type with the default document language set
for hebrew:
% Preview source code

%% LyX 2.0.0beta3 created this file.  For more info, see
http://www.lyx.org/.
%% Do not edit unless you really know what you are doing.
\documentclass[english,hebrew]{article}
\usepackage[T1]{fontenc}
\usepackage[latin9,cp1255]{inputenc}

\makeatletter
%% Textclass specific LaTeX
commands.
\usepackage{theorem}
\theorembodyfont{\upshape}
\newtheorem{theorem}{\R{משפט}}[section]
\AtBeginDocument{\make@lr\thetheorem}

\makeatother

\usepackage{babel}
\begin{document}
ש\inputencoding{latin9}\L{a}
\end{document}
generate a preview pdf with only the english 'a' (the second example has
it aligned tot he right of the page as it should) and the hebrew font
doesn't show at all :(

(it's kinda odd btw that the second example show a non default lyx
environment as it's what lyx itself shows)

this is as you can see lyx2.0.0beta3 on fedora 14 (with
2.6.35.10-74.fc14.i686, if you want to know specific pacakges i'd be
happy to provide) the viewer is evince 2.32.0 which doesn't seem to have
any problems showing documents with hebrew fonts :S

the second log looks something like:
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
(format=pdflatex 2011.2.8)  16 FEB 2011 22:41
entering extended mode
 %&-line parsing enabled.
**newfile1.tex
(./newfile1.tex
LaTeX2e <2005/12/01>
Babel  and hyphenation patterns for english,
usenglishmax, dumylang, noh
yphenation, arabic, basque, bulgarian, coptic, welsh, czech,
slovak, german, ng
erman, danish, esperanto, spanish, catalan, galician, estonian,
farsi, finnish,
 french, greek, monogreek, ancientgreek, croatian, hungarian,
interlingua, ibyc
us, indonesian, icelandic, italian, latin, mongolian, dutch,
norsk, polish, por
tuguese, pinyin, romanian, russian, slovenian, uppersorbian,
serbian, swedish, 
turkish, ukenglish, ukrainian, loaded.

(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2005/09/16 v1.4f Standard LaTeX document
class
(/usr/share/texmf/tex/latex/base/size10.clo
File: size10.clo 2005/09/16 v1.4f Standard LaTeX file (size
option)
)
\c@part=\count79
\c@section=\count80
\c@subsection=\count81
\c@subsubsection=\count82
\c@paragraph=\count83
\c@subparagraph=\count84
\c@figure=\count85
\c@table=\count86
\abovecaptionskip=\skip41
\belowcaptionskip=\skip42
\bibindent=\dimen102
) (/usr/share/texmf/tex/latex/base/fontenc.sty
Package: fontenc 2005/09/27 v1.99g Standard LaTeX package
(/usr/share/texmf/tex/latex/base/t1enc.def
File: t1enc.def 2005/09/27 v1.99g Standard LaTeX file
LaTeX Font Info:Redeclaring font encoding T1 on input line
43.
)) (/usr/share/texmf/tex/latex/base/inputenc.sty
Package: inputenc 2006/05/05 v1.1b Input encoding file
\inpenc@prehook=\toks14
\inpenc@posthook=\toks15
(/usr/share/texmf/tex/latex/base/latin9.def
File: latin9.def 2006/05/05 v1.1b Input encoding file
) (/usr/share/texmf/tex/generic/babel/cp1255.def
File: cp1255.def 2004/02/20 v1.1b Hebrew input encoding file
)) (/usr/share/texmf/tex/latex/tools/theorem.sty
Package: theorem 1995/11/23 v2.2c Theorem extension package
(FMi)
\theorem@style=\toks16
\theorem@bodyfont=\toks17

Re: hebrew support in lyx 2.0?

[Richman Reuven]

sorry in the previous mail i thought i included it...

Name: tex-fonts-hebrew
Arch: noarch
Version : 0.1
Release : 14.fc12
Size: 222 k
Repo: installed
From repo   : fedora
Summary : Culmus Hebrew fonts support for LaTeX
URL : http://culmus.sf.net
License : GPL+ and LPPL
Description : Support using the Culmus Hebrew fonts in LaTeX.

Name: tex-preview
Arch: noarch
Version : 11.86
Release : 4.fc14
Size: 161 k
Repo: installed
From repo   : fedora
Summary : Preview style files for LaTeX
URL : http://www.gnu.org/software/auctex/
License : GPLv3+
Description : The preview package for LaTeX allows for the
processing of selected
: parts of a LaTeX input file.  This package
extracts indicated pieces
: from a source file (typically displayed equations,
figures and
: graphics) and typesets with their base point at
the (1in,1in) magic
: location, shipping out the individual pieces on
separate pages without
: any page markup.  You can produce either DVI or
PDF files, and options
: exist that will set the page size separately for
each page.  In that
: manner, further processing (as with Ghostscript or
dvipng) will be
: able to work in a single pass.
: 
: The main purpose of this package is the extraction
of certain
: environments (most notably displayed formulas)
from LaTeX sources as
: graphics. This works with DVI files postprocessed
by either Dvips and
: Ghostscript or dvipng, but it also works when you
are using PDFTeX for
: generating PDF files (usually also postprocessed
by Ghostscript).
: 
: The tex-preview package is generated from the
AUCTeX package for
: Emacs.

Name: tex-simplecv
Arch: noarch
Version : 1.6
Release : 8.fc12
Size: 5.4 k
Repo: installed
From repo   : fedora
Summary : A simple latex class for writing curricula vitae
URL :
http://tug.ctan.org/tex-archive/macros/latex/contrib/simplecv/
License : LPPL
Description : The simplecv document class is intended to provide
a simple yet
: elegant way to write your curriculum vitae
(resume). This is a
: repackaging of the |cv| class that has been
available with LyX for a
: long time. The change of name has been made
necessary by the existence
: of another |cv| class on CTAN.

Name: texinfo
Arch: i686
Version : 4.13a
Release : 13.fc14
Size: 1.9 M
Repo: installed
From repo   : updates
Summary : Tools needed to create Texinfo format
documentation files
URL : http://www.gnu.org/software/texinfo/
License : GPLv3+
Description : Texinfo is a documentation system that can produce
both online
: information and printed output from a single
source file. The GNU
: Project uses the Texinfo file format for most of
its documentation.
: 
: Install texinfo if you want a documentation system
for producing both
: online and print documentation from the same
source file and/or if you
: are going to write documentation for the GNU
Project.

Name: texlive
Arch: i686
Version : 2007
Release : 56.fc14
Size: 3.9 M
Repo: installed
From repo   : fedora
Summary : Binaries for the TeX formatting system
URL : http://tug.org/texlive/
License : GPLv2 and BSD and Public Domain and LGPLv2+ and
GPLv2+ and LPPL
Description : TeXLive is an implementation of TeX for Linux or
UNIX systems. TeX takes
: a text file and a set of formatting commands as
input and creates a
: printable file as output. Usually, TeX is used in
conjunction with
: a higher level formatting package like LaTeX or
PlainTeX, since TeX by
: 

Re: tabular*

[Edwin Leuven]

Patrick Atamaniuk  wrote:
> I traced it down to InsetTabular.cpp:4327 , action 75
> This is called at lfun_ok calculation from
> InsetParamsDialog::checkWidgets and will set the status to not
> enabled, where get_status stops and the applyPB will be disabled.
>
> I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
> queried at this point

docstring GuiTabular::dialogToParams()

returns something like

tabular set-tabular-width 0pt set-pwidth 0pt align-center
set-decimal-point . valign-top  tabular-valign-middle  unset-booktabs
set-top-space none set-bottom-space none set-interline-space none
set-line-left true set-line-right false set-line-top true
set-line-bottom true set-special-column none unset-multicolumn
unset-multirow  unset-rotate-tabular  unset-rotate-cell
unset-longtabular  unset-ltcaption  unset-lthead none unset-lthead
dl_above unset-lthead dl_below unset-ltfirsthead dl_above
unset-ltfirsthead dl_below unset-ltfirsthead none unset-ltfirsthead
empty unset-ltfoot none unset-ltfoot dl_above unset-ltfoot dl_below
unset-ltlastfoot none unset-ltlastfoot dl_above unset-ltlastfoot
dl_below unset-ltlastfoot empty longtabular-align-center

...

so when you check longtable this gets passed to
InsetParamsDialog::checkWidgets which then checks whether
set-tabular-width is enabled (just because it happens to be first in
line), and it won't be and lfun_ok is false

a simple "fix" is to move

// table width
string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);
if (tabwidth.empty())
tabwidth = "0pt";
setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);

down so that for example set-pwidth will be queried first rather than
set-tabular-width

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?

edwin

Re: tabular*

[Vincent van Ravesteijn]

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?



I guess the logic of getStatus is meant to check whether an lfun with a 
single tabular feature is allowed. Magically, the lfun send by the 
dialog always passed the test.


I would just make it explicit and add an option which says that the lfun 
should always be enabled. It's not nice, but at least it is more clear 
what happens now.


Index: src/insets/InsetTabular.cpp
===
--- src/insets/InsetTabular.cpp(revision 37694)
+++ src/insets/InsetTabular.cpp(working copy)
@@ -4280,6 +4280,12 @@

 string const s = cmd.getArg(1);
 // FIXME: We only check for the very first argument...
+
+if (s == "always-enabled") {
+status.setEnabled(true);
+return true;
+}
+
 int action = Tabular::LAST_ACTION;
 int i = 0;
 for (; tabularFeature[i].action != Tabular::LAST_ACTION; ++i) {
Index: src/frontends/qt4/GuiTabular.cpp
===
--- src/frontends/qt4/GuiTabular.cpp(revision 37694)
+++ src/frontends/qt4/GuiTabular.cpp(working copy)
@@ -408,7 +408,7 @@
 docstring GuiTabular::dialogToParams() const
 {
 // FIXME: We should use Tabular directly.
-string param_str = "tabular";
+string param_str = "tabular always-enabled";

 // table width
 string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);



edwin

Vincent

Re: tabular*

[Richard Heck]

On 02/16/2011 05:22 PM, Edwin Leuven wrote:

Patrick Atamaniuk  wrote:

I traced it down to InsetTabular.cpp:4327 , action 75
This is called at lfun_ok calculation from
InsetParamsDialog::checkWidgets and will set the status to not
enabled, where get_status stops and the applyPB will be disabled.

I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
queried at this point

docstring GuiTabular::dialogToParams()

returns something like

tabular set-tabular-width 0pt set-pwidth 0pt align-center
set-decimal-point . valign-top  tabular-valign-middle  unset-booktabs
set-top-space none set-bottom-space none set-interline-space none
set-line-left true set-line-right false set-line-top true
set-line-bottom true set-special-column none unset-multicolumn
unset-multirow  unset-rotate-tabular  unset-rotate-cell
unset-longtabular  unset-ltcaption  unset-lthead none unset-lthead
dl_above unset-lthead dl_below unset-ltfirsthead dl_above
unset-ltfirsthead dl_below unset-ltfirsthead none unset-ltfirsthead
empty unset-ltfoot none unset-ltfoot dl_above unset-ltfoot dl_below
unset-ltlastfoot none unset-ltlastfoot dl_above unset-ltlastfoot
dl_below unset-ltlastfoot empty longtabular-align-center

...

so when you check longtable this gets passed to
InsetParamsDialog::checkWidgets which then checks whether
set-tabular-width is enabled (just because it happens to be first in
line), and it won't be and lfun_ok is false

a simple "fix" is to move

// table width
string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);
if (tabwidth.empty())
tabwidth = "0pt";
setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);

down so that for example set-pwidth will be queried first rather than
set-tabular-width

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?

Another option is not to write the "set-tabular-width" thing if we're 
disabled. Surely we don't depend upon its being there. Simple patch below.


InsetTabular::getStatus() is weird anyway, since it only checks the very 
first argument.


rh

===

Index: src/frontends/qt4/GuiTabular.cpp
===
--- src/frontends/qt4/GuiTabular.cpp(revision 37703)
+++ src/frontends/qt4/GuiTabular.cpp(working copy)
@@ -411,10 +411,12 @@
string param_str = "tabular";

// table width
-   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

-   if (tabwidth.empty())
-   tabwidth = "0pt";
-   setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);
+   if (tabularWidthED->isEnabled()) {
+   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

+   if (tabwidth.empty())
+   tabwidth = "0pt";
+   setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);
+   }

// apply the fixed width values
// this must be done before applying the column alignment



edwin

Re: tabular*

[Vincent van Ravesteijn]

 Op 16-2-2011 23:34, Richard Heck schreef:

On 02/16/2011 05:22 PM, Edwin Leuven wrote:

Patrick Atamaniuk  wrote:

I traced it down to InsetTabular.cpp:4327 , action 75
This is called at lfun_ok calculation from
InsetParamsDialog::checkWidgets and will set the status to not
enabled, where get_status stops and the applyPB will be disabled.

I'm absolutely clueless why action 75 (Tabular::SET_TABULAR_WIDTH) is
queried at this point

docstring GuiTabular::dialogToParams()

returns something like

tabular set-tabular-width 0pt set-pwidth 0pt align-center
set-decimal-point . valign-top  tabular-valign-middle  unset-booktabs
set-top-space none set-bottom-space none set-interline-space none
set-line-left true set-line-right false set-line-top true
set-line-bottom true set-special-column none unset-multicolumn
unset-multirow  unset-rotate-tabular  unset-rotate-cell
unset-longtabular  unset-ltcaption  unset-lthead none unset-lthead
dl_above unset-lthead dl_below unset-ltfirsthead dl_above
unset-ltfirsthead dl_below unset-ltfirsthead none unset-ltfirsthead
empty unset-ltfoot none unset-ltfoot dl_above unset-ltfoot dl_below
unset-ltlastfoot none unset-ltlastfoot dl_above unset-ltlastfoot
dl_below unset-ltlastfoot empty longtabular-align-center

...

so when you check longtable this gets passed to
InsetParamsDialog::checkWidgets which then checks whether
set-tabular-width is enabled (just because it happens to be first in
line), and it won't be and lfun_ok is false

a simple "fix" is to move

// table width
string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

if (tabwidth.empty())
tabwidth = "0pt";
setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);

down so that for example set-pwidth will be queried first rather than
set-tabular-width

i don't know the logic of this machinery and i don't have the time to
try to twist my head around it either

so perhaps the inventor of this code can suggest a proper fix?

Another option is not to write the "set-tabular-width" thing if we're 
disabled. Surely we don't depend upon its being there. Simple patch 
below.


InsetTabular::getStatus() is weird anyway, since it only checks the 
very first argument.


rh

===

Index: src/frontends/qt4/GuiTabular.cpp
===
--- src/frontends/qt4/GuiTabular.cpp(revision 37703)
+++ src/frontends/qt4/GuiTabular.cpp(working copy)
@@ -411,10 +411,12 @@
string param_str = "tabular";

// table width
-   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

-   if (tabwidth.empty())
-   tabwidth = "0pt";
-   setParam(param_str, Tabular::SET_TABULAR_WIDTH, tabwidth);
+   if (tabularWidthED->isEnabled()) {
+   string tabwidth = widgetsToLength(tabularWidthED, 
tabularWidthUnitLC);

+   if (tabwidth.empty())
+   tabwidth = "0pt";
+   setParam(param_str, Tabular::SET_TABULAR_WIDTH, 
tabwidth);

+   }

// apply the fixed width values
// this must be done before applying the column alignment



edwin




This is not the right fix.

Imagine you have a longtable in your document. Now you uncheck the 
longtable checkbox, fill in a table width, press Apply. Nothing will 
happen because InsetTabular::getStatus checks for setting the table 
width, while the table is still a longtable.


Vincent

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

[Vincent van Ravesteijn]

 Op 16-2-2011 23:19, for...@lyx.org schreef:

Author: forenr
Date: Wed Feb 16 23:19:49 2011
New Revision: 37704
URL: http://www.lyx.org/trac/changeset/37704

Log:
Don't disable apply button if one (or more) of vertical alignment, rotation,
or long table settings are changed. Fixes bug #7308.

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 22:08:18 2011
(r37703)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 23:19:49 2011
(r37704)
@@ -4323,8 +4323,10 @@
return true;

case Tabular::SET_TABULAR_WIDTH:
-   status.setEnabled(!tabular.rotate&&   
!tabular.is_long_tabular
-   &&  tabular.tabular_valignment == 
Tabular::LYX_VALIGN_MIDDLE);
+   status.setEnabled(tabular.tabular_width.zero()
+   || (!tabular.rotate&&   !tabular.is_long_tabular
+   &&  tabular.tabular_valignment ==
+   Tabular::LYX_VALIGN_MIDDLE));
break;

case Tabular::SET_DECIMAL_POINT:


This is not correct.

This is basically saying that SET_TABULAR_WIDTH should be allowed for 
longtables, because tabular_width is zero by definition for longtables.


Vincent

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

[Enrico Forestieri]

On Wed, Feb 16, 2011 at 11:57:22PM +0100, Vincent van Ravesteijn wrote:
>  Op 16-2-2011 23:19, for...@lyx.org schreef:
> >Author: forenr
> >Date: Wed Feb 16 23:19:49 2011
> >New Revision: 37704
> >URL: http://www.lyx.org/trac/changeset/37704
> >
> >Log:
> >Don't disable apply button if one (or more) of vertical alignment, rotation,
> >or long table settings are changed. Fixes bug #7308.
> >
> >Modified:
> >lyx-devel/trunk/src/insets/InsetTabular.cpp
> >
> >Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
> >==
> >--- lyx-devel/trunk/src/insets/InsetTabular.cpp  Wed Feb 16 22:08:18 
> >2011(r37703)
> >+++ lyx-devel/trunk/src/insets/InsetTabular.cpp  Wed Feb 16 23:19:49 
> >2011(r37704)
> >@@ -4323,8 +4323,10 @@
> > return true;
> >
> > case Tabular::SET_TABULAR_WIDTH:
> >-status.setEnabled(!tabular.rotate&&   
> >!tabular.is_long_tabular
> >-&&  tabular.tabular_valignment == 
> >Tabular::LYX_VALIGN_MIDDLE);
> >+status.setEnabled(tabular.tabular_width.zero()
> >+|| (!tabular.rotate&&   !tabular.is_long_tabular
> >+&&  tabular.tabular_valignment ==
> >+Tabular::LYX_VALIGN_MIDDLE));
> > break;
> >
> > case Tabular::SET_DECIMAL_POINT:
> 
> This is not correct.

I'm sorry, you're wrong.

> This is basically saying that SET_TABULAR_WIDTH should be allowed
> for longtables, because tabular_width is zero by definition for
> longtables.

It works just fine.

-- 
Enrico

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

[Vincent van Ravesteijn]

 Op 17-2-2011 0:17, Enrico Forestieri schreef:

On Wed, Feb 16, 2011 at 11:57:22PM +0100, Vincent van Ravesteijn wrote:

  Op 16-2-2011 23:19, for...@lyx.org schreef:

Author: forenr
Date: Wed Feb 16 23:19:49 2011
New Revision: 37704
URL: http://www.lyx.org/trac/changeset/37704

Log:
Don't disable apply button if one (or more) of vertical alignment, rotation,
or long table settings are changed. Fixes bug #7308.

Modified:
lyx-devel/trunk/src/insets/InsetTabular.cpp

Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
==
--- lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 22:08:18 2011
(r37703)
+++ lyx-devel/trunk/src/insets/InsetTabular.cpp Wed Feb 16 23:19:49 2011
(r37704)
@@ -4323,8 +4323,10 @@
return true;

case Tabular::SET_TABULAR_WIDTH:
-   status.setEnabled(!tabular.rotate&&
!tabular.is_long_tabular
-   &&   tabular.tabular_valignment == 
Tabular::LYX_VALIGN_MIDDLE);
+   status.setEnabled(tabular.tabular_width.zero()
+   || (!tabular.rotate&&
!tabular.is_long_tabular
+   &&   tabular.tabular_valignment ==
+   Tabular::LYX_VALIGN_MIDDLE));
break;

case Tabular::SET_DECIMAL_POINT:

This is not correct.

I'm sorry, you're wrong.


I'm sorry, I'm right.


This is basically saying that SET_TABULAR_WIDTH should be allowed
for longtables, because tabular_width is zero by definition for
longtables.

It works just fine.

It does not. It allows you to execute "inset-modify tabular 
set-tabular-width 7cm" for a longtable, and it happily changes the 
table, while this lfun should have been disabled.


Vincent

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:
> Author: vfr
> Date: Thu Feb 17 00:06:43 2011
> New Revision: 37705
> URL: http://www.lyx.org/trac/changeset/37705
> 
> Log:
> Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix 
> coming soon)


This patch was working fine. I don't understand why you are doing this
without discussing it with me.

> Modified:
>lyx-devel/trunk/src/insets/InsetTabular.cpp
> 
> Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
> ==
> --- lyx-devel/trunk/src/insets/InsetTabular.cpp   Wed Feb 16 23:19:49 
> 2011(r37704)
> +++ lyx-devel/trunk/src/insets/InsetTabular.cpp   Thu Feb 17 00:06:43 
> 2011(r37705)
> @@ -4323,10 +4323,8 @@
>   return true;
>  
>   case Tabular::SET_TABULAR_WIDTH:
> - status.setEnabled(tabular.tabular_width.zero()
> - || (!tabular.rotate &&  !tabular.is_long_tabular
> - && tabular.tabular_valignment ==
> - Tabular::LYX_VALIGN_MIDDLE));
> + status.setEnabled(!tabular.rotate &&  
> !tabular.is_long_tabular
> + && tabular.tabular_valignment == 
> Tabular::LYX_VALIGN_MIDDLE);
>   break;
>  
>   case Tabular::SET_DECIMAL_POINT:

-- 
Enrico

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

[Vincent van Ravesteijn]

 Op 17-2-2011 0:22, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:

Author: vfr
Date: Thu Feb 17 00:06:43 2011
New Revision: 37705
URL: http://www.lyx.org/trac/changeset/37705

Log:
Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix coming 
soon)


This patch was working fine. I don't understand why you are doing this
without discussing it with me.


Because it's wrong.

Vincent

Re: r37706 - in lyx-devel/trunk/src: frontends/qt4 insets

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:09:29AM +0100, v...@lyx.org wrote:
> Author: vfr
> Date: Thu Feb 17 00:09:29 2011
> New Revision: 37706
> URL: http://www.lyx.org/trac/changeset/37706
> 
> Log:
> Fix bug #7308: Table settings dialog broken.

Previous fix was just fine. I am considering to revert this and
apply again the old one.

> Modified:
>lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp
>lyx-devel/trunk/src/insets/InsetTabular.cpp
> 
> Modified: lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp
> ==
> --- lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp  Thu Feb 17 00:06:43 
> 2011(r37705)
> +++ lyx-devel/trunk/src/frontends/qt4/GuiTabular.cpp  Thu Feb 17 00:09:29 
> 2011(r37706)
> @@ -408,7 +408,7 @@
>  docstring GuiTabular::dialogToParams() const
>  {
>   // FIXME: We should use Tabular directly.
> - string param_str = "tabular";
> + string param_str = "tabular from-dialog";
>  
>   // table width
>   string tabwidth = widgetsToLength(tabularWidthED, tabularWidthUnitLC);
> 
> Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
> ==
> --- lyx-devel/trunk/src/insets/InsetTabular.cpp   Thu Feb 17 00:06:43 
> 2011(r37705)
> +++ lyx-devel/trunk/src/insets/InsetTabular.cpp   Thu Feb 17 00:09:29 
> 2011(r37706)
> @@ -4278,8 +4278,16 @@
>   if (() != this || cmd.getArg(0) != "tabular") 
>   break;
>  
> - string const s = cmd.getArg(1);
>   // FIXME: We only check for the very first argument...
> + string const s = cmd.getArg(1);
> + // We always enable the lfun if it is coming from the dialog
> + // because the dialog makes sure all the settings are valid,
> + // even though the first argument might not be valid now.
> + if (s == "from-dialog") {
> + status.setEnabled(true);
> + return true;
> + }
> +
>   int action = Tabular::LAST_ACTION;
>   int i = 0;
>   for (; tabularFeature[i].action != Tabular::LAST_ACTION; ++i) {

-- 
Enrico

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:22:48AM +0100, Vincent van Ravesteijn wrote:
>  Op 17-2-2011 0:22, Enrico Forestieri schreef:
> >On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:
> >>Author: vfr
> >>Date: Thu Feb 17 00:06:43 2011
> >>New Revision: 37705
> >>URL: http://www.lyx.org/trac/changeset/37705
> >>
> >>Log:
> >>Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix 
> >>coming soon)
> >
> >This patch was working fine. I don't understand why you are doing this
> >without discussing it with me.
> >
> Because it's wrong.

You are wrong.

-- 
Enrico

Re: r37706 - in lyx-devel/trunk/src: frontends/qt4 insets

[Vincent van Ravesteijn]

 Op 17-2-2011 0:22, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:09:29AM +0100, v...@lyx.org wrote:

Author: vfr
Date: Thu Feb 17 00:09:29 2011
New Revision: 37706
URL: http://www.lyx.org/trac/changeset/37706

Log:
Fix bug #7308: Table settings dialog broken.

Previous fix was just fine. I am considering to revert this and
apply again the old one.


The previous fix was not fine.

Vincent

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

[Vincent van Ravesteijn]

 Op 17-2-2011 0:23, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:22:48AM +0100, Vincent van Ravesteijn wrote:

  Op 17-2-2011 0:22, Enrico Forestieri schreef:

On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:

Author: vfr
Date: Thu Feb 17 00:06:43 2011
New Revision: 37705
URL: http://www.lyx.org/trac/changeset/37705

Log:
Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix coming 
soon)

This patch was working fine. I don't understand why you are doing this
without discussing it with me.


Because it's wrong.

You are wrong.


I'm not.

Vincent

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:20:49AM +0100, Vincent van Ravesteijn wrote:
>  Op 17-2-2011 0:17, Enrico Forestieri schreef:
> >On Wed, Feb 16, 2011 at 11:57:22PM +0100, Vincent van Ravesteijn wrote:
> >>  Op 16-2-2011 23:19, for...@lyx.org schreef:
> >>>Author: forenr
> >>>Date: Wed Feb 16 23:19:49 2011
> >>>New Revision: 37704
> >>>URL: http://www.lyx.org/trac/changeset/37704
> >>>
> >>>Log:
> >>>Don't disable apply button if one (or more) of vertical alignment, 
> >>>rotation,
> >>>or long table settings are changed. Fixes bug #7308.
> >>>
> >>>Modified:
> >>>lyx-devel/trunk/src/insets/InsetTabular.cpp
> >>>
> >>>Modified: lyx-devel/trunk/src/insets/InsetTabular.cpp
> >>>==
> >>>--- lyx-devel/trunk/src/insets/InsetTabular.cppWed Feb 16 22:08:18 
> >>>2011(r37703)
> >>>+++ lyx-devel/trunk/src/insets/InsetTabular.cppWed Feb 16 23:19:49 
> >>>2011(r37704)
> >>>@@ -4323,8 +4323,10 @@
> >>>   return true;
> >>>
> >>>   case Tabular::SET_TABULAR_WIDTH:
> >>>-  status.setEnabled(!tabular.rotate&&
> >>>!tabular.is_long_tabular
> >>>-  &&   tabular.tabular_valignment == 
> >>>Tabular::LYX_VALIGN_MIDDLE);
> >>>+  status.setEnabled(tabular.tabular_width.zero()
> >>>+  || (!tabular.rotate&&
> >>>!tabular.is_long_tabular
> >>>+  &&   tabular.tabular_valignment ==
> >>>+  Tabular::LYX_VALIGN_MIDDLE));
> >>>   break;
> >>>
> >>>   case Tabular::SET_DECIMAL_POINT:
> >>This is not correct.
> >I'm sorry, you're wrong.
> >
> I'm sorry, I'm right.

You are only a conceited young man.

> >>This is basically saying that SET_TABULAR_WIDTH should be allowed
> >>for longtables, because tabular_width is zero by definition for
> >>longtables.
> >It works just fine.
> >
> It does not. It allows you to execute "inset-modify tabular
> set-tabular-width 7cm" for a longtable, and it happily changes the
> table, while this lfun should have been disabled.

Which has no effect at all.

-- 
Enrico

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:25:54AM +0100, Vincent van Ravesteijn wrote:
>  Op 17-2-2011 0:23, Enrico Forestieri schreef:
> >On Thu, Feb 17, 2011 at 12:22:48AM +0100, Vincent van Ravesteijn wrote:
> >>  Op 17-2-2011 0:22, Enrico Forestieri schreef:
> >>>On Thu, Feb 17, 2011 at 12:06:43AM +0100, v...@lyx.org wrote:
> Author: vfr
> Date: Thu Feb 17 00:06:43 2011
> New Revision: 37705
> URL: http://www.lyx.org/trac/changeset/37705
> 
> Log:
> Revert r37704. It enabled SET_TABULAR_WIDTH for all longtables (new fix 
> coming soon)
> >>>This patch was working fine. I don't understand why you are doing this
> >>>without discussing it with me.
> >>>
> >>Because it's wrong.
> >You are wrong.
> >
> I'm not.

Childish.

-- 
Enrico

Re: r37706 - in lyx-devel/trunk/src: frontends/qt4 insets

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:23:41AM +0100, Vincent van Ravesteijn wrote:
>  Op 17-2-2011 0:22, Enrico Forestieri schreef:
> >On Thu, Feb 17, 2011 at 12:09:29AM +0100, v...@lyx.org wrote:
> >>Author: vfr
> >>Date: Thu Feb 17 00:09:29 2011
> >>New Revision: 37706
> >>URL: http://www.lyx.org/trac/changeset/37706
> >>
> >>Log:
> >>Fix bug #7308: Table settings dialog broken.
> >Previous fix was just fine. I am considering to revert this and
> >apply again the old one.
> >
> The previous fix was not fine.

You are still wrong.

-- 
Enrico

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

[Vincent van Ravesteijn]

This is basically saying that SET_TABULAR_WIDTH should be allowed
for longtables, because tabular_width is zero by definition for
longtables.

It works just fine.


It does not. It allows you to execute "inset-modify tabular
set-tabular-width 7cm" for a longtable, and it happily changes the
table, while this lfun should have been disabled.

Which has no effect at all.


It does.

Vincent

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 12:29:18AM +0100, Vincent van Ravesteijn wrote:
> 
> This is basically saying that SET_TABULAR_WIDTH should be allowed
> for longtables, because tabular_width is zero by definition for
> longtables.
> >>>It works just fine.
> >>>
> >>It does not. It allows you to execute "inset-modify tabular
> >>set-tabular-width 7cm" for a longtable, and it happily changes the
> >>table, while this lfun should have been disabled.
> >Which has no effect at all.
> >
> It does.

Good bye, I have better things to do.

-- 
Enrico

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

[Pavel Sanda]

Vincent van Ravesteijn wrote:
>> Which has no effect at all.
>>
> It does.

can both of you please come back to this point and in more than one sentence
put down your arguments/analysis?

and if possible no reverts while flaming, otherwise we might have correct code
but two developers left...

thanks,
pavel

Cut long patches to lyx-cvs

[Tommaso Cucinotta]

Hi all,

I'd like to know whether anyone else (apart from myself) has some 
troubles with those so long refactoring/new-features patches entirely 
sent to the lyx-cvs e-mail box.


I'm sure I'm using a so bad e-mail client like Thunderbird, however when 
opening one of those e-mail messages, my Thunderbird can freeze up to 1 
minute sometimes.


If it is not too difficult, I would propose to cut the attached patches 
to a maximum size, and include in the e-mail a URL to the trac that 
instead shows the entire patch for those ones who are interested.


Among those patches raising such an issue, I can remember someones 
involving changes to all .po files, others that recently added some new 
dictionary, and probably also my commit adding xvkbd to the tree.


Thanks,

T.

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

[Enrico Forestieri]

On Thu, Feb 17, 2011 at 01:09:04AM +0100, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
> >> Which has no effect at all.
> >>
> > It does.
> 
> can both of you please come back to this point and in more than one sentence
> put down your arguments/analysis?

I am sorry, this is a behavioural problem. I would not have any problem
discussing and even acknowledging that I could be wrong, but there are ways
to do things and the presuntuous way I cannot stand.

> and if possible no reverts while flaming, otherwise we might have correct code
> but two developers left...

I am not a developer, so you will lose nothing.

-- 
Enrico

Re: Cut long patches to lyx-cvs

[Pavel Sanda]

Tommaso Cucinotta wrote:
> If it is not too difficult, I would propose to cut the attached patches to 
> a maximum size,

+1

JMarc, this should be just one option in the svn hook scripts.

pavel

Re: Cut long patches to lyx-cvs

[Tommaso Cucinotta]

Il 17/02/2011 01:22, Tommaso Cucinotta ha scritto:
I'd like to know whether anyone else (apart from myself) has some 
troubles with those so long refactoring/new-features patches entirely 
sent to the lyx-cvs e-mail box.


just to support the argument: the dictionary e-mail of yesterday was a 
8MB e-mail, and my client didn't freeze for 1 min., but it was at least 
5 min. now. The .po message of Jan 20th was a 3.8MB one.


T.

Re: key not recognized in keybindings (Mac, trunk)

[BH]

On Wed, Feb 16, 2011 at 11:14 AM, Pavel Sanda  wrote:
> BH wrote:
>> On Mac with current trunk, the  key is not recognized for any
>> keybindings. (The Mac standard is for -[arrow key] to move the
>> cursor around by words/paragraphs, so this is a real problem.)
>>
>> Opening up the shortcuts preferences dialog, I find that all
>> keybindings that previously were assigned to  now indicate
>> that they are assigned to  instead (going by the symbol
>> displayed in the dialog); however, the  key is ignored as
>> well. Moreover, it is not possible to change the keybindings back to
>>  using the dialog: trying to assign  to
>> word-left results in just the  key registering in the dialog.
>>
>> Note: the  key is also used to enter accents and other
>> non-standard characters; this use is not affected. It's only LyX's
>> keybindings that ignore .
>
> could it be related to http://www.lyx.org/trac/ticket/7292 ?
> pavel

That's definitely the culprit.

Stephan?

BH

Re: key not recognized in keybindings (Mac, trunk)

[Stephan Witt]

Am 17.02.2011 um 03:31 schrieb BH:

> On Wed, Feb 16, 2011 at 11:14 AM, Pavel Sanda  wrote:
>> BH wrote:
>>> On Mac with current trunk, the  key is not recognized for any
>>> keybindings. (The Mac standard is for -[arrow key] to move the
>>> cursor around by words/paragraphs, so this is a real problem.)
>>> 
>>> Opening up the shortcuts preferences dialog, I find that all
>>> keybindings that previously were assigned to  now indicate
>>> that they are assigned to  instead (going by the symbol
>>> displayed in the dialog); however, the  key is ignored as
>>> well. Moreover, it is not possible to change the keybindings back to
>>>  using the dialog: trying to assign  to
>>> word-left results in just the  key registering in the dialog.
>>> 
>>> Note: the  key is also used to enter accents and other
>>> non-standard characters; this use is not affected. It's only LyX's
>>> keybindings that ignore .
>> 
>> could it be related to http://www.lyx.org/trac/ticket/7292 ?
>> pavel
> 
> That's definitely the culprit.
> 
> Stephan?

Yes, you're right. I missed that simple test. Sorry.
One is able to use Ctrl-Arrow instead of Option-Arrow
but that's of course not standard on Mac. You said this
is not working for you? Here I can use it.

Anyway, I'll revert the change and think of another solution.
Note: the accents input is broken again after that.

The correct solution is more work. The problem is the merge of 
MetaModifier and AltModifier done by LyX. LyX shouldn't fold both
Modifiers to AltModifier (Option-Key on Mac).

If this distinction is possible the key bindings on mac should
changed for all accented keys from Alt to Meta (if it isn't Meta already).

Stephan

Re: r37687 - in dictionaries/trunk: dicts thes

[Stephan Witt]

Am 16.02.2011 um 01:33 schrieb jo...@lyx.org:

> Author: joost
> Date: Wed Feb 16 01:33:18 2011
> New Revision: 37687
> URL: http://www.lyx.org/trac/changeset/37687
> 
> Log:
> create subdirectories for dictionaries and thesaurus
> 
> Added:
>   dictionaries/trunk/dicts/
>   dictionaries/trunk/thes/

Sorry, I was offline for two days...

The name for the subdirectory in the LyX package below the system directory
where LyX is doing the dictionary lookup is "dict".
In general I don't like directory renaming on install so much.
I propose to change LyX default lookup accordingly to avoid the SVN move.

Stephan

Index: src/HunspellChecker.cpp
===
--- src/HunspellChecker.cpp (Revision 37706)
+++ src/HunspellChecker.cpp (Arbeitskopie)
@@ -77,7 +77,7 @@
 
/// the location below system/user directory
/// there the aff+dic files lookup will happen
-   const string dictDirectory(void) const { return "dict"; }
+   const string dictDirectory(void) const { return "dicts"; }
int maxLookupSelector(void) const { return 3; }
 };
 
Index: src/AspellChecker.cpp
===
--- src/AspellChecker.cpp   (Revision 37706)
+++ src/AspellChecker.cpp   (Arbeitskopie)
@@ -88,7 +88,7 @@
 
/// the location below system/user directory
/// there the rws files lookup will happen
-   const string dictDirectory(void) { return "dict"; }
+   const string dictDirectory(void) { return "dicts"; }
/// there the dat+cmap files lookup will happen
const string dataDirectory(void) { return "data"; }
/// os package directory constants