date:20120321

Tommaso Cucinotta tomm...@lyx.org writes:

| Il 13/03/2012 23:32, Lars Gullik Bjønnes ha scritto:
 On Wed, Mar 14, 2012 at 00:03, Tommaso Cucinottatomm...@lyx.org  wrote:
 Il 13/03/2012 22:38, Lars Gullik Bjønnes ha scritto:

 All developers login as the git user, then your pub key is used to
 authenticate you and distinguish you from the other developers.


 It's receiving objects, thanks... @ 50 KiB/s, it will take a while.

 On a related note, if I clone both

g...@git.lyx.org:lyx

 and

g...@git.lyx.org:developers/tommaso/lyx
 (assuming this was created with ssh g...@git.lyx.org fork lyx
 developers/tommaso/lyx)

 on my laptop, will those 2 clones share the same common patches (and save my
 local disk space) or not ?
 No, but they would if you first cloned git clone
 g...@git.lyx.org:developers/tommaso/lyx lyx
 and then

 git clone --reference lyx g...@git.lyx.org:developers/tommaso/lyx lyx-tommaso

 then they would share a lot. However lyx-tommaso would also depend on
 lyx and you
 could never delete that without wrecking lyx-tommaso.

| I just followed the receipt (not for my own repo, but for checking out
| the 2.0.x branch in a separate folder -- I prefer keeping it like
| this), and I added also --shared, which I guess is the part that
| makes the new repo actually depending on the other repo. The
| disk-space saving is not that much, as I hoped:

| 239Mlyx
| 90Mlyx-2.0.x

Remember that since you have used '--shared' your lyx-2.0.x repo is now
dependent on the lyx repo. You cannot delete the lyx repo, then you
destroy the lyx-2.0.x repo as well. As long as you are aware of that
using '--shared' is quite ok.

-- 
   Lgb

[PATCH] Setup .gitignore for generated files


Setting up .gitignore or .git/info/excludes is something that should
be done. Not doing it makes it a lot harder to see actual new files
that should be added.

Signed-off-by: Lars Gullik BjÃ¸nnes lar...@gullik.org
---
 .gitignore|   13 +
 boost/.gitignore  |1 +
 config/.gitignore |6 ++
 development/.gitignore|1 +
 development/MacOSX/.gitignore |2 ++
 development/cygwin/.gitignore |1 +
 lib/.gitignore|4 
 lib/lyx2lyx/.gitignore|1 +
 po/.gitignore |5 +
 sourcedoc/.gitignore  |1 +
 src/.gitignore|6 ++
 src/client/.gitignore |2 ++
 src/frontends/.gitignore  |1 +
 src/frontends/qt4/.gitignore  |5 +
 src/support/.gitignore|2 ++
 src/tex2lyx/.gitignore|2 ++
 16 files changed, 53 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 boost/.gitignore
 create mode 100644 config/.gitignore
 create mode 100644 development/.gitignore
 create mode 100644 development/MacOSX/.gitignore
 create mode 100644 development/cygwin/.gitignore
 create mode 100644 lib/.gitignore
 create mode 100644 lib/lyx2lyx/.gitignore
 create mode 100644 po/.gitignore
 create mode 100644 sourcedoc/.gitignore
 create mode 100644 src/.gitignore
 create mode 100644 src/client/.gitignore
 create mode 100644 src/frontends/.gitignore
 create mode 100644 src/frontends/qt4/.gitignore
 create mode 100644 src/support/.gitignore
 create mode 100644 src/tex2lyx/.gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..dcaa06d
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,13 @@
+*.o
+.deps/
+Makefile
+Makefile.in
+aclocal.m4
+configure
+autom4te.cache/
+config.h.in
+config.h
+config.log
+config.status
+lyx.1
+stamp-h1
diff --git a/boost/.gitignore b/boost/.gitignore
new file mode 100644
index 000..4492822
--- /dev/null
+++ b/boost/.gitignore
@@ -0,0 +1 @@
+liblyxboost.a
diff --git a/config/.gitignore b/config/.gitignore
new file mode 100644
index 000..1fe03f8
--- /dev/null
+++ b/config/.gitignore
@@ -0,0 +1,6 @@
+config.guess
+config.sub
+depcomp
+install-sh
+missing
+py-compile
diff --git a/development/.gitignore b/development/.gitignore
new file mode 100644
index 000..570c439
--- /dev/null
+++ b/development/.gitignore
@@ -0,0 +1 @@
+lyx.spec
diff --git a/development/MacOSX/.gitignore b/development/MacOSX/.gitignore
new file mode 100644
index 000..270c8e8
--- /dev/null
+++ b/development/MacOSX/.gitignore
@@ -0,0 +1,2 @@
+Info.plist
+lyxrc.dist
diff --git a/development/cygwin/.gitignore b/development/cygwin/.gitignore
new file mode 100644
index 000..abceabf
--- /dev/null
+++ b/development/cygwin/.gitignore
@@ -0,0 +1 @@
+lyxrc.dist
diff --git a/lib/.gitignore b/lib/.gitignore
new file mode 100644
index 000..4dc6dab
--- /dev/null
+++ b/lib/.gitignore
@@ -0,0 +1,4 @@
+lyx.desktop
+lyx.desktop-temp
+lyx.png
+lyx.svg
diff --git a/lib/lyx2lyx/.gitignore b/lib/lyx2lyx/.gitignore
new file mode 100644
index 000..fc74c0b
--- /dev/null
+++ b/lib/lyx2lyx/.gitignore
@@ -0,0 +1 @@
+lyx2lyx_version.py
diff --git a/po/.gitignore b/po/.gitignore
new file mode 100644
index 000..b7acd9d
--- /dev/null
+++ b/po/.gitignore
@@ -0,0 +1,5 @@
+POTFILES
+POTFILES.in
+lyx.pot
+*.gmo
+stamp-po
diff --git a/sourcedoc/.gitignore b/sourcedoc/.gitignore
new file mode 100644
index 000..3849810
--- /dev/null
+++ b/sourcedoc/.gitignore
@@ -0,0 +1 @@
+Doxyfile
diff --git a/src/.gitignore b/src/.gitignore
new file mode 100644
index 000..51eb62f
--- /dev/null
+++ b/src/.gitignore
@@ -0,0 +1,6 @@
+lyx
+liblyxcore.a
+liblyxgraphics.a
+liblyxinsets.a
+liblyxmathed.a
+moc_Compare.cpp
diff --git a/src/client/.gitignore b/src/client/.gitignore
new file mode 100644
index 000..d27dc51
--- /dev/null
+++ b/src/client/.gitignore
@@ -0,0 +1,2 @@
+lyxclient
+lyxclient.1
diff --git a/src/frontends/.gitignore b/src/frontends/.gitignore
new file mode 100644
index 000..2473004
--- /dev/null
+++ b/src/frontends/.gitignore
@@ -0,0 +1 @@
+liblyxfrontends.a
diff --git a/src/frontends/qt4/.gitignore b/src/frontends/qt4/.gitignore
new file mode 100644
index 000..14699e4
--- /dev/null
+++ b/src/frontends/qt4/.gitignore
@@ -0,0 +1,5 @@
+Resources.cpp
+Resources.qrc
+liblyxqt4.a
+ui_*.h
+moc_*.cpp
diff --git a/src/support/.gitignore b/src/support/.gitignore
new file mode 100644
index 000..222e5ec
--- /dev/null
+++ b/src/support/.gitignore
@@ -0,0 +1,2 @@
+liblyxsupport.a
+moc_SystemcallPrivate.cpp
diff --git a/src/tex2lyx/.gitignore b/src/tex2lyx/.gitignore
new file mode 100644
index 000..827ef2b
--- /dev/null
+++ b/src/tex2lyx/.gitignore
@@ -0,0 +1,2 @@
+tex2lyx
+tex2lyx.1
-- 
1.7.7.6

Re: [PATCH] Setup .gitignore for generated files


Le 21/03/2012 10:02, Lars Gullik Bjønnes a écrit :


Setting up .gitignore or .git/info/excludes is something that should
be done. Not doing it makes it a lot harder to see actual new files
that should be added.


Definitely.

JMarc

Re: [PATCH] Setup .gitignore for generated files

Lars Gullik Bj?nnes wrote:
 
 Setting up .gitignore or .git/info/excludes is something that should
 be done. Not doing it makes it a lot harder to see actual new files
 that should be added.
 
 Signed-off-by: Lars Gullik Bj?¸nnes lar...@gullik.org
 ---
  .gitignore|   13 +

IIRC it's doable through single file, or is such spread intention? P

  boost/.gitignore  |1 +
  config/.gitignore |6 ++
  development/.gitignore|1 +
  development/MacOSX/.gitignore |2 ++
  development/cygwin/.gitignore |1 +
  lib/.gitignore|4 
  lib/lyx2lyx/.gitignore|1 +
  po/.gitignore |5 +
  sourcedoc/.gitignore  |1 +
  src/.gitignore|6 ++
  src/client/.gitignore |2 ++
  src/frontends/.gitignore  |1 +
  src/frontends/qt4/.gitignore  |5 +
  src/support/.gitignore|2 ++
  src/tex2lyx/.gitignore|2 ++
  16 files changed, 53 insertions(+), 0 deletions(-)
  create mode 100644 .gitignore
  create mode 100644 boost/.gitignore
  create mode 100644 config/.gitignore
  create mode 100644 development/.gitignore
  create mode 100644 development/MacOSX/.gitignore
  create mode 100644 development/cygwin/.gitignore
  create mode 100644 lib/.gitignore
  create mode 100644 lib/lyx2lyx/.gitignore
  create mode 100644 po/.gitignore
  create mode 100644 sourcedoc/.gitignore
  create mode 100644 src/.gitignore
  create mode 100644 src/client/.gitignore
  create mode 100644 src/frontends/.gitignore
  create mode 100644 src/frontends/qt4/.gitignore
  create mode 100644 src/support/.gitignore
  create mode 100644 src/tex2lyx/.gitignore
 
 diff --git a/.gitignore b/.gitignore
 new file mode 100644
 index 000..dcaa06d
 --- /dev/null
 +++ b/.gitignore
 @@ -0,0 +1,13 @@
 +*.o
 +.deps/
 +Makefile
 +Makefile.in
 +aclocal.m4
 +configure
 +autom4te.cache/
 +config.h.in
 +config.h
 +config.log
 +config.status
 +lyx.1
 +stamp-h1
 diff --git a/boost/.gitignore b/boost/.gitignore
 new file mode 100644
 index 000..4492822
 --- /dev/null
 +++ b/boost/.gitignore
 @@ -0,0 +1 @@
 +liblyxboost.a
 diff --git a/config/.gitignore b/config/.gitignore
 new file mode 100644
 index 000..1fe03f8
 --- /dev/null
 +++ b/config/.gitignore
 @@ -0,0 +1,6 @@
 +config.guess
 +config.sub
 +depcomp
 +install-sh
 +missing
 +py-compile
 diff --git a/development/.gitignore b/development/.gitignore
 new file mode 100644
 index 000..570c439
 --- /dev/null
 +++ b/development/.gitignore
 @@ -0,0 +1 @@
 +lyx.spec
 diff --git a/development/MacOSX/.gitignore b/development/MacOSX/.gitignore
 new file mode 100644
 index 000..270c8e8
 --- /dev/null
 +++ b/development/MacOSX/.gitignore
 @@ -0,0 +1,2 @@
 +Info.plist
 +lyxrc.dist
 diff --git a/development/cygwin/.gitignore b/development/cygwin/.gitignore
 new file mode 100644
 index 000..abceabf
 --- /dev/null
 +++ b/development/cygwin/.gitignore
 @@ -0,0 +1 @@
 +lyxrc.dist
 diff --git a/lib/.gitignore b/lib/.gitignore
 new file mode 100644
 index 000..4dc6dab
 --- /dev/null
 +++ b/lib/.gitignore
 @@ -0,0 +1,4 @@
 +lyx.desktop
 +lyx.desktop-temp
 +lyx.png
 +lyx.svg
 diff --git a/lib/lyx2lyx/.gitignore b/lib/lyx2lyx/.gitignore
 new file mode 100644
 index 000..fc74c0b
 --- /dev/null
 +++ b/lib/lyx2lyx/.gitignore
 @@ -0,0 +1 @@
 +lyx2lyx_version.py
 diff --git a/po/.gitignore b/po/.gitignore
 new file mode 100644
 index 000..b7acd9d
 --- /dev/null
 +++ b/po/.gitignore
 @@ -0,0 +1,5 @@
 +POTFILES
 +POTFILES.in
 +lyx.pot
 +*.gmo
 +stamp-po
 diff --git a/sourcedoc/.gitignore b/sourcedoc/.gitignore
 new file mode 100644
 index 000..3849810
 --- /dev/null
 +++ b/sourcedoc/.gitignore
 @@ -0,0 +1 @@
 +Doxyfile
 diff --git a/src/.gitignore b/src/.gitignore
 new file mode 100644
 index 000..51eb62f
 --- /dev/null
 +++ b/src/.gitignore
 @@ -0,0 +1,6 @@
 +lyx
 +liblyxcore.a
 +liblyxgraphics.a
 +liblyxinsets.a
 +liblyxmathed.a
 +moc_Compare.cpp
 diff --git a/src/client/.gitignore b/src/client/.gitignore
 new file mode 100644
 index 000..d27dc51
 --- /dev/null
 +++ b/src/client/.gitignore
 @@ -0,0 +1,2 @@
 +lyxclient
 +lyxclient.1
 diff --git a/src/frontends/.gitignore b/src/frontends/.gitignore
 new file mode 100644
 index 000..2473004
 --- /dev/null
 +++ b/src/frontends/.gitignore
 @@ -0,0 +1 @@
 +liblyxfrontends.a
 diff --git a/src/frontends/qt4/.gitignore b/src/frontends/qt4/.gitignore
 new file mode 100644
 index 000..14699e4
 --- /dev/null
 +++ b/src/frontends/qt4/.gitignore
 @@ -0,0 +1,5 @@
 +Resources.cpp
 +Resources.qrc
 +liblyxqt4.a
 +ui_*.h
 +moc_*.cpp
 diff --git a/src/support/.gitignore b/src/support/.gitignore
 new file mode 100644
 index 000..222e5ec
 --- /dev/null
 +++ b/src/support/.gitignore
 @@ -0,0 +1,2 @@
 +liblyxsupport.a
 +moc_SystemcallPrivate.cpp
 diff --git a/src/tex2lyx/.gitignore b/src/tex2lyx/.gitignore
 new file mode 100644
 index 000..827ef2b
 ---

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 20-3-2012 20:35, Richard Heck schreef:

On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:

Op 20-3-2012 0:15, Richard Heck schreef:


This is in my private repo. I have a branch master, and another 
branch bugs/7975, and another branch lyx/trunk that is tracking the 
main repo, set up as you suggested. The master and lyx/trunk 
branches were completely in sync, or so I thought. So then I did:

git checkout lyx/trunk
git merge bugs/7975
and I ended up with the merge commit, representing the new commit 
from bugs/7975 as one branch and some of the material from lyx/trunk 
as a separate branch. I think was, in part, because bugs/7975 had 
been rebased against branch. I've done some other tests, and if I 
rebase it against lyx/trunk then of course it is OK.




This is just the classic example of a merge. In one branch is the 
development of the others (master) and your development is in your 
private branch (bugs/7975). Now you merged the two together.


If you rebase your feature branch on top of master first and then do 
a merge, you will get a special type of merge, namely a fast-forward 
merge. If you would specify --no-ff, you would still get a merge commit.


I'm not sure what part is surprising to you.

What's surprising is that I get a non-fast-forward merge that is 
empty. Unsurprising that it's empty, since the two branches are 
completely synchronized, but surprising that the empty merge shows up 
as a commit. Note that, as I said, this does not happen if I've 
rebased against the other branch.


* First, I'm not sure what you mean by the merge is empty. Indeed,  
'git show 9236a938' does not show any changes in the code, but that's 
normal. A merge only combines two sets of commits; the actual changes to 
the code is done in the commits themselves. In this case in commit 
0a0a837b and in commits 8be18455..758d0482. (try: 'gitk 
8be18455..758d0482' this will show all commits that are in this range). 
If you want to see the code changes introduced by a merge you can do:


$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

* Second, what do you mean with two branches are completely 
synchronized ? I guess you mean that if one branch is based on top the 
other they are synchronized ? And if they are  'synchronized', you get a 
fast-forward merge and thus no merge commit. This really is a special 
case and technically not even a merge.



So whether I get the empty commit depends upon which branch I rebased 
against, not what's actually in that branch.


If you rebase a branch A against another branch B, all commits of the 
branch B are actually included in branch A. So please don't rebase a 
branch A versus another branch B before merging it with branch C, 
because than branch B will also be merged into branch C.


If you would have rebased your feature branch against the 2.0.x branch 
before merging it into master, you are bound to run into problems if the 
commits in the 2.0.x branch are not _exactly_ the same as those in the 
master branch.


Vincent

Re: conversion of suit characters from utf to math seems broken between 2.0.2 and 2.0.3

2012-03-21 Thread Guenter Milde

On 2012-03-20, Georg Baum wrote:
 Vincent van Ravesteijn wrote:

 I don't know what is supposed to happen to these characters.

 Basically nothing (see below).

 Like the other ca. 1000 out of 2751 Unicode math-related symbols without
 (traditional) LaTeX support, they cannot be auto-converted to a LaTeX
 command by LyX.

 * File a bug/enhancement report for conditional conversions in
unicodesymbols, i.e. conversions that are active if LyX detects that
the required command is available in the document without auto-loading
packages.

 * File a bug/enhancement report asking for a way to add Unicode-LaTeX
conversions on a per-document basis.

 I do not believe a per-document solution is good. Why should a particular 
 conversion only be valid for one document?

Just like other settings, the available Unicode replacements can depend
on document settings that lyx is not aware of: I can add a
required package, latex command and \DeclareUnicodeCharacter (if the
document uses utf8) in the custom preamble or ERT. However, I still
cannot use the new-defined character in LyX, as LyX is unaware of this
replacement.

One possible implementation would be a new Unicodesymbols section for
LyX modules and layouts. Then, characters provided by packages or
preamble code can be handled by modules (and local modules would allow
the per-document configuration).

--

 You can roughly divide unicode symbols in two classes: The ones like ?
 that can be composed of glyphs existing in many fonts (in this case the
 acute symbol on top of the small letter c), and the ones like ? that
 require special glyphs.

 The first class can be handled perfectly by the unicodesymbols file for 
 almost any font that can be used by latex/pdflatex.

While the first class can be handled by the current unicodesymbols
syntax, this is currently not allowed:

 # Do only add commands that give correct output, no hacks that look similar.

AFIK, even using a lookalike character with different semantic is
considered a hack that looks 'similar'. Composing, turning, skaling or
moving glyphs to build a new character representation has definitely more
serious drawbacks. (This is, e.g., the reason why LyX defaults to the
T1 font encoding instead of the LaTeX default OT1.)

A perfect Unicode-LaTeX mapping is only given if the character in the
output document is recoverable, i.e. if copying from the PDF, say, will
result in the same character as used in the input. (Actually, not all
character mapping in unicodesymbols meet this criterium.)

We might consider offering lookalikes and substitutions on a configurable
basis (as a module?).


 The second class cannot be handled in a generic way, since it either
 requires a font with an extended set of glyphs, or an additional font
 that provides the extra glyphs. In the latter case the additional font
 is almost always tied to a particular main font (otherwise the output
 would not look good, although many people don't care). What is needed
 here is a more flexible mechanism for mapping these symbols to LaTeX
 commands: Depending on the main document font chosen, LyX should use
 different LaTeX commands provided by different packages. 

While in this case the output can be perfect, the syntax of LyX's
unicodesymbols file needs additions to handle the conditional mappings.

 E.g. if the main document font is times, it could output ? with 
 $\varheartsuit$ using txfonts.sty, with $\varheartsuit$ using pxfonts.sty if 
 the main font is palatino, or else with \ding{170} using pifont.sty.
 You cannot always use pifont, since it looks bad for some fonts, e.g. times 
 (compare $\heartsuit$ with \ding{170}).

As txfonts, pxfonts, kmath, and kpfonts all change the look of math
symbols as well as spacing in equations etc. (compare e.g. the math
typesetting in the two Times-using example documents
http://milde.users.sourceforge.net/Matheschriften/txfonts-test.pdf and 
http://milde.users.sourceforge.net/Matheschriften/tgtermes-qtxmath-MnSymbol-test.pdf
), they should *never* be automatically loaded.

 For now, we could replace some of the removed characters with the pifont 
 versions (pifont is already used elsewhere in unicodesymbols). When removing 
 the txfonts symbols, I was not aware that some are also offered by 
 pifont.sty.

Attention: The Unicode Character Names list states that these are different
characters:

2764HEAVY BLACK HEART
x (black heart suit - 2665)


 Unfortunately I don't know how such a solution could look like in practice. 


Mappings provided by a module are one possibility, suited for
glyph-providing packages that are typically added by the user (in LaTeX
via \usepackage) and have few side-effects.

Another possibility, suited, e.g., for fonts selected by LyX's font
selection GUI, is an extension to the syntax of unicodesymbols, adding
conditionals and alternatives, e.g.

 0x2665\\varheartsuit txfonts?|pxfonts?|kmath?|kpfonts?

to define \varheartsuit only if one of

Re: about Lyx in general


Op 21-3-2012 13:32, Dahlmann Martin TU Ilmenau schreef:


Hello,

I am writing this to the developers list, because its more about the 
development than how to possibly manually fix a special issue that I 
might mention. Simply, if there is a manual fix, then I have not found 
it yet, which might mean that it is too hard to find. And hard to find 
would mean a poor useability.


The roadmap that I have found only contains single features. Where is 
the overall concept discussion? Also discussing how WYSIWYM actually 
may work, which sure does not have only a single way to see it.


Or the user interface and control concepts to make it more userfriendly?

Some questions that came up after trying Lyx for a few weeks:

How can I change the list icon that I see in the editor?



What list icon do you mean ?

Why are there still different Headline levels? (compare to h in 
XHTML 2.0)




I don't know what you mean. The type of headline you need depends on the 
structure of the document you are writing.


How can I configure which icon appears in a toolbar, and which does 
not? (to remove the useless ones manually, e.g. text style, paragraph 
settings)




You can edit Resource/ui/stdtoolbars.inc. There has been done work on a 
toolbar editor, but it is not yet finished.


There are toolbar icons for figure and table environments, but why is 
there none for formulars?




There is one for formulas as well. However, for some unknown reason, the 
Insert math, Insert graphics and Insert table are separate from 
most of the other Insert...  icons.


Similar the figure environment cannot be chosen using the context 
menu, like the math ones.




What do you mean ? How many figure environments are there ?



Why can the user choose from so many math environments (align, array, 
...) and even has to? Some do not work right. Why not simply keep the 
one that is working best?




It all depends on what kind of formula you want to insert. Is it a 
derivation ? Is it a matrix equation ? Is it a system of equations ? Is 
it a formula which is too long for a single row ? etc.


Why can the user choose from that many different tex2pdf tools? One 
single selection to export as PDF is much easier to use and less 
confusing.




Because different people want to use different tools, and some documents 
require another tools than others.


I agree, we could make it more clear which is the standard one for 
people that are confused by so many options.


I would like to see a Lyx lite version with only WYSIWYM, all WYSIWYG 
features removed. Also most Options removed to keep it simple (keep 
the best option).




Your feature request is to remove a lot of features. I think a lot of 
other people will start complaining if we do that. Why are you so 
bothered by features. You don't have to use them if you don't want to.


If there is a standard, then force the user to follow it! Do not add 
many options to choose from (= many ways to do it wrong).




One of the most heard complaints about LyX is that LyX prentends to know 
better what the user wants than the user himself. This would make this 
even worse for that type of user.



Content and Layout are currently still together in the same file. Does 
Lyx not want to follow the concept of separation of content and 
formatting?




This is separated. The formatting is defined by the class, style, layout 
and module files. If you have special formatting in your document, it is 
adviced to use Character styles, instead of changing the formatting locally.



WYSIWYG list (just what I saw so far during my short test):

* text alignment (should just allways be left in the editor to avoid 
too large spaces between words)




Other people want to have the text justified on the screen.

In 2.1 there will be an option to justify or not the text on screen. 
However, this is yet another option, while you want to remove all 
options. Do you mean you want all options to be fixed to what _you_ 
think is the *best* option ?


* text and paragraph formatting like color (em as formatting is 
WYSIWYM, setting a color is WYSIWYG)




We advice to use Character styles, custom insets etc. for this. However, 
other people want to have the ability to set the color.



* image alignment, scaling, rotating ...



?

* setting image size manually in the editor (Where is the auto scale 
option to fit the screen while editing?)




Yes, I wanted to implement something that scales the images to a fixed 
size for a long time.


The important final question: Does Lyx aim to be fully WYSIWYM and may 
be try new concepts, or does it want to keep LATEXs WYSIWYG features 
and only be a LATEX Editor?




(I've no idea what you mean with LaTeX's WYSIWYG features ?)

One of the largest things that we would like to add to LyX is a layout 
editor. This would be able to more easily specify the formatting in a 
single separate file, and even less in the document itself. Then we 
could also move a lot of the settings of

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

Vincent van Ravesteijn wrote:
 all commits that are in this range). If you want to see the code changes 
 introduced by a merge you can do:

 $ git diff 9236a938 9236a938^1

 This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).



Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Vincent

Re: Updates to gitolite progress


Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :

If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in home/lyx, you can clone this with

git clone -s -b 2.0.x home/lyx home/lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to branch. 
I don't want to be a git jedi just now, so I applied the patch I had to 
my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.

I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I do 
a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs list.


OK, I think, the stuff has been committed from my shared 2.0.x directory 
to the original lyx checkout on my computer, so I have to push there too.


But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x - 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a patch 
to branch (please tell me there is!). I understand that plenty of 
probably exciting and complicated ways of working on a branch have been 
given, but I would like to start with trivial stuff like making a commit 
of a bite-size patch on a branch.


JMarc

Wiki page editing

Hello,

I'm willing to edit the web pages after 2.0.3 is out, but now when I try to
login nothing happens.
Has the password been changed ?

-- 
Jean-Pierre

Re: Wiki page editing

Jean-Pierre Chrétien wrote:
 Hello,
 
 I'm willing to edit the web pages after 2.0.3 is out, but now when I try to
 login nothing happens.
 Has the password been changed ?

No, its broken. Christian is slowly trying to recover. Pavel

Re: Wiki page editing

Pavel Sanda sanda at lyx.org writes:


 
 No, its broken. Christian is slowly trying to recover. Pavel
 

Ok, I will wait then. Does he need help ? I'm running pmwikis for my personal
needs (after seeing lyx wiki features :-)

-- 
Jean-Pierre

Re: Updates to gitolite progress


Op 21-3-2012 15:51, Jean-Marc Lasgouttes schreef:

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the 
following:


Assume you have a git clone in home/lyx, you can clone this with

git clone -s -b 2.0.x home/lyx home/lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to 
branch. I don't want to be a git jedi just now, so I applied the patch 
I had to my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.


There is also a 2.0.x branch in your first clone, so you can just 
cherry-pick the commit to master directly onto this 2.0.x branch, and 
push from there.




I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I 
do a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs 
list.


OK, I think, the stuff has been committed from my shared 2.0.x 
directory to the original lyx checkout on my computer, so I have to 
push there too.


Yes.

You can also push directly from your 2.0.x clone by adding the remote to 
this clone:


$ git remote add lyx g...@git.lyx.org:lyx

Now you can push your branch to lyx:

$ git push lyx 2.0.x

Use

$ git remote -v

to see the remotes that are set up for a clone. For your 2.0.x clone 
you'll indeed see that the origin the your original clone.




But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x - 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were 
rejected

Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a 
patch to branch (please tell me there is!). I understand that plenty 
of probably exciting and complicated ways of working on a branch have 
been given, but I would like to start with trivial stuff like making a 
commit of a bite-size patch on a branch.


The hint in the error message says that you have to merge the remote 
changes before you push. This is the same as that svn would tell you 
that your repo is not up to date.


Most probably the following will solve this:

$ git pull --rebase

(though I recommend to do 'git fetch', 'git merge --ff-only', and only 
rebase your feature branch on top of master when you really want to push 
it).





JMarc


Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

Vincent van Ravesteijn wrote:
 Op 21-3-2012 15:00, Pavel Sanda schreef:
 Vincent van Ravesteijn wrote:
 all commits that are in this range). If you want to see the code changes
 introduced by a merge you can do:

 $ git diff 9236a938 9236a938^1

 This will show you that the merge is not empty at all.
 Is there a way how to obtain full listing of diffs which went into the 
 master?
 (I mean something like git log -p produced by git-svn on the old svn 
 trunk).


 Something like this:

 $ git log 9236a938^1..9236a938 --no-merges -p

 you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p 
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


git log -p really shows all commits that went into master. The problem 
is that by using git log you're forcing the history to be linear, 
while it actually isn't. Git therefore sorts the commit based on the 
date of the commit (not the date of the merge). So, the date of the 
actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


git log -p really shows all commits that went into master. The 
problem is that by using git log you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date of 
the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:

$ git log -p --simplify-merges

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 16:48, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.
Is there a way how to obtain full listing of diffs which went into 
the

master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


git log -p really shows all commits that went into master. The 
problem is that by using git log you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date 
of the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only 
Richard's commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:


or:

git log -p -m --first-parent

-m

   This flag makes the merge commits show the full diff like regular
   commits; for each merge parent, a separate log entry and diff is
   generated. An exception is that only diff against the first parent
   is shown when /--first-parent/ option is given; in that case, the
   output represents the changes the merge brought /into/ the
   then-current branch.



Vincent

Re: Updates to gitolite progress



There has to be a simple way to commit a patch to branch (please tell 
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you 
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x 
will automatically be merged into the master. This can be done, because, 
in general, all fixes that go into 2.0.x are in master too.


Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

Vincent van Ravesteijn wrote:
 change that was merged in by Richard was March 13.

 You can see this immediately if you limit the output to only Richard's 
 commits:

 $ git log -p --author='Richard Heck'

 Vincent

 The following shows the diffs in order they got into master:

 or:

 git log -p -m --first-parent

I see. Actually even git log -p is fine with me, I just didn't catch
that the commit was from March 13...

Pavel

Re: Current git workflow

Georg Baum wrote:
 commit yet)? I guess it would look like
 
 git checkout -b fixfileformat
 git commit
 git checkout master
 git merge fixfileformat
 git commit
 git branch -d fixfileformat

The simplistic SVN-like scenario is just:

git pull (update from public repo)
git commit (just local commit in your tree)
git push (push the commit to public repo)

Pavel

Re: Updates to gitolite progress


Le 21/03/2012 16:56, Vincent van Ravesteijn a écrit :



There has to be a simple way to commit a patch to branch (please tell
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x
will automatically be merged into the master. This can be done, because,
in general, all fixes that go into 2.0.x are in master too.


That would mak sense. I intend t eventually understand the git way, but 
my first goal is to walk a few baby steps by myself.


JMarc

Re: Wiki page editing

2012-03-21 Thread Richard Heck


On 03/21/2012 11:09 AM, Jean-Pierre Chrétien wrote:

Pavel Sandasandaat  lyx.org  writes:



No, its broken. Christian is slowly trying to recover. Pavel


Ok, I will wait then. Does he need help ? I'm running pmwikis for my personal
needs (after seeing lyx wiki features :-)

Apparently, the problem is that the version of pmwiki we have doesn't 
like the version of PHP we have. So the former needs to be upgraded. I 
think Christian was hoping to get to it this weekend.


Richard

Re: Updates to gitolite progress


Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing a 
full rebuild everytime, I have to have two checkouts living in different 
places, right? And moreover, I have to update satus.20x.



You can also push directly from your 2.0.x clone by adding the remote to
this clone:

$ git remote add lyx g...@git.lyx.org:lyx


OK

Now you can push your branch to lyx:

$ git push lyx 2.0.x


How come I have to specify lyx 2.0.x. Isn't it possible to setup the 
branch so that git push will do the right thing?



The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?

Thanks.

JMarc

Re: Updates to gitolite progress




Now you can push your branch to lyx:

$ git push lyx 2.0.x


How come I have to specify lyx 2.0.x. Isn't it possible to setup the 
branch so that git push will do the right thing?


git push will by default push to the remote which is tracked by the 
current branch. If the current branch does not track anything it will 
push to origin.


To see and edit what is being tracked by a branch, you can type

$ git config -e

There will be something like:

[branch 2.0.x]
remote = origin
merge = refs/heads/2.0.x

So, the branch 2.0.x tracks the branch 2.0.x from the remote origin. 
So, you can configure it however you want it.






The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?


In the one from where you are trying to push to the git.lyx.org from.

Vincent

Re: Updates to gitolite progress

Jean-Marc Lasgouttes wrote:
 Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
 There is also a 2.0.x branch in your first clone, so you can just
 cherry-pick the commit to master directly onto this 2.0.x branch, and
 push from there.

 But If I want to compile both the master and the branch without doing a 
 full rebuild everytime, I have to have two checkouts living in different 
 places, right? And moreover, I have to update satus.20x.

I believe more repositories are necessary and while its possible to clone
locally one from the other (and thus save some disk space), it will bring
problems with cryptic error messages for newcomers as you could see.

The simplest SVN-like scenario:

1. Checkout full repo 
git clone g...@git.lyx.org:lyx trunk
2. Full mirror of branch as well, not through clone
cp -r trunk branch; cd branch
3. Checkout branch 2.0.x
git checkout 2.0.x
   (by default you commit  push directly to 2.0.x branch in branch dir from 
now on)

Now for the commit backporting:
(4. commit  push change into trunk 5. go to branch directory)

6. git pull (receive trunk change to the branch repo as well)

One problem is that the commit never equals thanks to status.20x changes,
so one of many ways could be to remember hash from the trunk commit (say ) 
and:

7. git show  | git apply   (patch the current tree with the commit XXX)
8. add your changes to status.20x
9. git commit
10. git push

Pavel

Re: Current git workflow

2012-03-21 Thread André Pönitz

On Wed, Mar 21, 2012 at 05:04:56PM +0100, Pavel Sanda wrote:
 Georg Baum wrote:
  commit yet)? I guess it would look like
  
  git checkout -b fixfileformat
  git commit
  git checkout master
  git merge fixfileformat
  git commit
  git branch -d fixfileformat
 
 The simplistic SVN-like scenario is just:
 
 git pull (update from public repo)
 git commit (just local commit in your tree)
 git push (push the commit to public repo)

Methinks

  git commit (just local commit in your tree)
  git pull --rebase (update from public repo and put local changes on top)
  git push (push the - possibly adjusted - commit to public repo)

is closer to the SVN way.

Andre'

Re: [patch] full support for table rotations


Am 20.03.2012 09:31, schrieb Vincent van Ravesteijn:


+ if (tabular.rotate != 0)
+ rotateTabularAngleSB-setValue(tabular.rotate);
+ else
+ rotateTabularAngleSB-setValue(90);


rotateTabularAngleSB-setValue(tabular.rotate == 0 ? 90 : tabular.rotate);


I never understood why this form is preferred. For me my version consumes more lines but I can see 
faster what it is about.



- height400/height
+ height402/height
/rect
/property
property name=windowTitle


I'd prefer not to tinkle with the size.


Me too but I cannot reduce the height back to 400, 402 are now required in the designer. But there 
are only 2 pixels and I added an edit field which consumes this more space.



@@ -5196,6 +5196,14 @@ bool InsetTabular::oneCellHasRotationState(bool rotated,
return false;
}

+bool InsetTabular::tableIsRotated() const


I think this function is not useful.


Indeed.


case Tabular::TOGGLE_ROTATE_TABULAR:
- tabular.rotate = !tabular.rotate;
+ // when pressing the rotate button we default to 90° rotation
+ if (tableIsRotated())
+ tabular.rotate = 90;
+ else
+ tabular.rotate = 0;
break;


This seems wrong.


Yes, I must be the opposite.


Missing: Tex2lyx - TODO entry: Import rotated tables (and cells probably) ?


I can add this, but that tex2lyx cannot handle rotations in tables is not 
introduced by this commit.

many thanks for the review and regards
Uwe

Re: [lyx/refs/heads/2.0.x] GuiTabular.cpp: fix bug #8084


Am 20.03.2012 09:47, schrieb Vincent van Ravesteijn:


I would write:

bool const fixed_width_multirow = multirowCB-isChecked()  width != 0pt;
bool const inherit_column_align = !fixed_width_multirow;
if (inherit_column_align)
setHAlign(param_str);

Now it is immediately clear that we only set the column alignment if we inherit 
the alignment from
the column and this is only the case if do not have a multirow with a fixed 
width.


Seems that we have 2 different views on this topic. For me it is more complicated to read this out 
of the code than to read a comment. Moreover your code does not link the bug. My experience is that 
a linked bug in a comment helps for issues that will probably reappear and the multirow alignment 
topic is a bit strange and this question will arise again sooner or later.



Some more reasons to prefer clear code above an unclear comment:
- you don't make typos, grammatical errors,


Yes.


- you don't assume knowledge, you don't imply logical steps that other people 
don't understand, etc.


That is why I link to the bugreport. If I read your code without background knowledge I would be 
lost why you are doing what you do. Thus I prefer comments.



- if the code changes, the comments are often forgotten to be updated. This 
results in a lot of
outdated comments in the code,


This is no excuse. When code is changed the comment also needs to be changed accordingly- I was 
taught that comments are also code and every developer must treat it as such.


regards Uwe

Re: [lyx/refs/heads/master] - INSTALL.Win32: revise and update the description because since Qt 4.8 it mustn't be compiled (and can currently also not without a lot of hacking). Moreover we have now a

Am 20.03.2012 10:04, schrieb Vincent van Ravesteijn:

What is incomplete?
I changed it because it didn't work anymore. With Qt 4.8 things have changed
and Peter did a good
job with the script so that the former manual settings are now automatically
set.

It still worked perfectly for me. What didn't work anymore ?

You cannot compile Qt 4.8 as described. First you will stumble over the problem that a window pops
up telling you that you have to install Perl. This is a known bug of the Qt package. But even if you
put in the workaround fix, you will stumble over compilation errors for which one can again find
workarounds. Finally I found out that the precompiled Qt 4.8.0 comes already with all you need and
now supports MSVC 2010. So in fact handling Qt is now as simple as installing a program with a few
clicks.

Which settings had to be set manually
which are now set automatically ?

The CMAKE variable settings, see the diff of my change for a list of them. (All
;-) )

At some point you say where you copied the dependencies to. I have no idea
what you mean with this.

This was also not clear in the old version. I now added a further step:

It suddenly requires CMakeScript

This is the official CMake release plus a script that is provided directly by
Peter. So we have
the maintainer in our team.

I'm not sure whether Peter is still in our team.

I think yes.

If you were a CMake expert, ok. But if there is a CMake problem, you come to
the list and ask others
to fix it. Now suddenly you promote tools which are only used by yourself.

Peter suggested it and it works much faster, in my opinio this is an advantage. If you don#t like
the script, you still can either use CMAKE without the script of the version I linked and remove the
ninja option as I described. For security reasons the build script doesn't use it for release
builds. (However I could find an issue.)

The Install.Win32 file is for new developers. I guess existing developers will never read it as they
already have their setup. So I tried to make it as simple as possible.

No other developer have
ever heard of CMakeScript before, let alone about Ninja. You nowhere even
explains what Ninja is ?

It is an alternative to Make. I also don't know the details how it internally sets up filelists and
dependencies and don't want to. But what I see is that compiling LyX using Ninja is much faster and
thus saves a lot of time. Just check it out.

Have you tried it? It generates studio files and solutions for debugging too.

No,

Why are you then telling it does not?

but you don't mention it at all in the file.

I'm using MSVC since the beginning and I would not have accepted it if I could not debug with MSVC.
Why should I explicitly mention the solution files? I can but for just compiling LyX you don't need
them. If you want to debug LyX you will but the Install-Win32 file was not about debugging LyX. But
if you like I can add a section about this.

I'm afraid that this will generate a merged build by default which is rather
useless to use in
MSVC.

Please test and then be afraid.

Why do you then have to manually supply the path to the dependencies ? The
previous workflow did
this automatically.

If you don't have then or the path to them is not correct they will be downloaded. But it might be
that you already have them. Then you don't need them twice. For example I started compiling master
and got the dependencies. But when compiling branch they would be downloaded again. But to save disk
space I changed the build script in my branch checkout to the folder of the dependencies that were
downloaded once for master.
Maybe my description is not clear enough or I indeed have a bug in the script, thus please test and
I'll fix it or you can change the description to make things more clear.

In what way do you have to be a CMake expert to use the GUI ? Start the gui,
browse to the correct
folder, and check some options. What is difficult ?

Maybe you remember that I had to ask on the list how this is done. And when switching to branch or
from branch I had to do this again.

CMake searched for Qt, so if it could find it,
there was no need to supply it manually. The GNUWin32 directory was set
automatically.

Not on my setup.

So, you
prefer to do this all manually ?

You only have to set the path once and never again when switching between branches. This is much,
much easier and I don't need to learn the different names of Cmake variables.

Why wouldn't the CMake GUI allow you to compile master and branch parallel ?

I never managed to get this and on this list I was told that this doesn't work and so a script was
proposed.

It doesn't make sense
that you would want to compile both with the same settings.

I do this since 2 years. Why should I use different settings? I only need to distinguish between
release and debug builds, but for this you can call the build script with different

Re: Updates to gitolite progress

2012-03-21 Thread Tommaso Cucinotta


Il 21/03/2012 16:44, Jean-Marc Lasgouttes ha scritto:

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing 
a full rebuild everytime, I have to have two checkouts living in 
different places,


that's how I'm used to work, also because normally I have different 
configure options for trunk/master (more debug) w.r.t. branch (less 
debug, more optimiz., try system libs). I've noted down the receipt I 
followed to share the patches between the two separate folders/repos, at:


  http://wiki.lyx.org/Devel/LyXGit

(last bullet of Cloning the Repository). I can't count how many warnings 
I received from git seniors about using --shared, still it's just what 
I need :-), as my disk-space is finite and my mobile broadband has a 
GB/month cap :-(.


T.

Re: [PATCH] Setup .gitignore for generated files

Pavel Sanda sa...@lyx.org writes:

| Lars Gullik Bj?nnes wrote:
 
 Setting up .gitignore or .git/info/excludes is something that should
 be done. Not doing it makes it a lot harder to see actual new files
 that should be added.
 
 Signed-off-by: Lars Gullik Bj?¸nnes lar...@gullik.org
 ---
  .gitignore|   13 +

| IIRC it's doable through single file, or is such spread intention? P

Yes. It is intentional.

The generic stuff is handled from the top, more specifics, f.ex.
moc_*.cpp is handled where it happens.

If a file suddenly appears in a location where we did not expect we
should now about it.

-- 
   Lgb

Re: Updates to gitolite progress

Vincent van Ravesteijn v...@lyx.org writes:

 There has to be a simple way to commit a patch to branch (please
 tell me there is!).


| I forgot to mention: Ideally, if we do it the git-way completely, you
| would only have to commit a patch to the 2.0.x branch. Later, the
| 2.0.x will automatically be merged into the master. This can be done,
| because, in general, all fixes that go into 2.0.x are in master too.

Hmm... that would be a very bad idea.
And the premise is in general not true.

-- 
   Lgb

Re: Updates to gitolite progress

Pavel Sanda sa...@lyx.org writes:

| Jean-Marc Lasgouttes wrote:
 Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
 There is also a 2.0.x branch in your first clone, so you can just
 cherry-pick the commit to master directly onto this 2.0.x branch, and
 push from there.

 But If I want to compile both the master and the branch without doing a 
 full rebuild everytime, I have to have two checkouts living in different 
 places, right? And moreover, I have to update satus.20x.

| I believe more repositories are necessary and while its possible to clone
| locally one from the other (and thus save some disk space), it will bring
| problems with cryptic error messages for newcomers as you could see.

| The simplest SVN-like scenario:

| 1. Checkout full repo 
| git clone g...@git.lyx.org:lyx trunk
| 2. Full mirror of branch as well, not through clone
| cp -r trunk branch; cd branch

No...
(perhaps... it does not seem optimal, does not take advantage that
things are on same fs f.ex.))

-- 
   Lgb

Re: [patch] full support for table rotations

Uwe Stöhr uwesto...@web.de writes:

| Am 20.03.2012 09:31, schrieb Vincent van Ravesteijn:

 + if (tabular.rotate != 0)
 + rotateTabularAngleSB-setValue(tabular.rotate);
 + else
 + rotateTabularAngleSB-setValue(90);

 rotateTabularAngleSB-setValue(tabular.rotate == 0 ? 90 : tabular.rotate);

| I never understood why this form is preferred. For me my version
| consumes more lines but I can see faster what it is about.

for me with at helper var for the arg that is not the case.
that rotateTabularAngleSB-setValue is dublicated and that I have to use
time to verify that the lines really are the same is worse.

int const rot = tabular.rotate == 0 ? 90 : tabular.rotate:
rotateTabularAngleSB-setValue(rot);

solves that form me.

-- 
   Lgb

Re: svn commit denied ?

Tommaso Cucinotta  writes:

| Il 13/03/2012 23:32, Lars Gullik Bjønnes ha scritto:
>> On Wed, Mar 14, 2012 at 00:03, Tommaso Cucinotta  wrote:
>>> Il 13/03/2012 22:38, Lars Gullik Bjønnes ha scritto:
>>>
>>> All developers login as the "git" user, then your pub key is used to
>>> authenticate you and distinguish you from the other developers.
>>>
>>>
>>> It's "receiving objects", thanks... @ 50 KiB/s, it will take a while.
>>>
>>> On a related note, if I clone both
>>>
>>>g...@git.lyx.org:lyx
>>>
>>> and
>>>
>>>g...@git.lyx.org:developers/tommaso/lyx
>> (assuming this was created with "ssh g...@git.lyx.org fork lyx
>> developers/tommaso/lyx")
>>
>>> on my laptop, will those 2 clones share the same common patches (and save my
>>> local disk space) or not ?
>> No, but they would if you first cloned "git clone
>> g...@git.lyx.org:developers/tommaso/lyx lyx"
>> and then
>>
>> git clone --reference lyx g...@git.lyx.org:developers/tommaso/lyx lyx-tommaso
>>
>> then they would share a lot. However lyx-tommaso would also depend on
>> lyx and you
>> could never delete that without wrecking lyx-tommaso.
>
| I just followed the receipt (not for my own repo, but for checking out
| the 2.0.x branch in a separate folder -- I prefer keeping it like
| this), and I added also "--shared", which I guess is the part that
| makes the new repo actually depending on the other repo. The
| disk-space saving is not that much, as I hoped:
>
| 239Mlyx
| 90Mlyx-2.0.x

Remember that since you have used '--shared' your lyx-2.0.x repo is now
dependent on the lyx repo. You cannot delete the lyx repo, then you
destroy the lyx-2.0.x repo as well. As long as you are aware of that
using '--shared' is quite ok.

-- 
   Lgb

[PATCH] Setup .gitignore for generated files


Setting up .gitignore or .git/info/excludes is something that should
be done. Not doing it makes it a lot harder to see actual new files
that should be added.

Signed-off-by: Lars Gullik BjÃ¸nnes 
---
 .gitignore|   13 +
 boost/.gitignore  |1 +
 config/.gitignore |6 ++
 development/.gitignore|1 +
 development/MacOSX/.gitignore |2 ++
 development/cygwin/.gitignore |1 +
 lib/.gitignore|4 
 lib/lyx2lyx/.gitignore|1 +
 po/.gitignore |5 +
 sourcedoc/.gitignore  |1 +
 src/.gitignore|6 ++
 src/client/.gitignore |2 ++
 src/frontends/.gitignore  |1 +
 src/frontends/qt4/.gitignore  |5 +
 src/support/.gitignore|2 ++
 src/tex2lyx/.gitignore|2 ++
 16 files changed, 53 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 boost/.gitignore
 create mode 100644 config/.gitignore
 create mode 100644 development/.gitignore
 create mode 100644 development/MacOSX/.gitignore
 create mode 100644 development/cygwin/.gitignore
 create mode 100644 lib/.gitignore
 create mode 100644 lib/lyx2lyx/.gitignore
 create mode 100644 po/.gitignore
 create mode 100644 sourcedoc/.gitignore
 create mode 100644 src/.gitignore
 create mode 100644 src/client/.gitignore
 create mode 100644 src/frontends/.gitignore
 create mode 100644 src/frontends/qt4/.gitignore
 create mode 100644 src/support/.gitignore
 create mode 100644 src/tex2lyx/.gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..dcaa06d
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,13 @@
+*.o
+.deps/
+Makefile
+Makefile.in
+aclocal.m4
+configure
+autom4te.cache/
+config.h.in
+config.h
+config.log
+config.status
+lyx.1
+stamp-h1
diff --git a/boost/.gitignore b/boost/.gitignore
new file mode 100644
index 000..4492822
--- /dev/null
+++ b/boost/.gitignore
@@ -0,0 +1 @@
+liblyxboost.a
diff --git a/config/.gitignore b/config/.gitignore
new file mode 100644
index 000..1fe03f8
--- /dev/null
+++ b/config/.gitignore
@@ -0,0 +1,6 @@
+config.guess
+config.sub
+depcomp
+install-sh
+missing
+py-compile
diff --git a/development/.gitignore b/development/.gitignore
new file mode 100644
index 000..570c439
--- /dev/null
+++ b/development/.gitignore
@@ -0,0 +1 @@
+lyx.spec
diff --git a/development/MacOSX/.gitignore b/development/MacOSX/.gitignore
new file mode 100644
index 000..270c8e8
--- /dev/null
+++ b/development/MacOSX/.gitignore
@@ -0,0 +1,2 @@
+Info.plist
+lyxrc.dist
diff --git a/development/cygwin/.gitignore b/development/cygwin/.gitignore
new file mode 100644
index 000..abceabf
--- /dev/null
+++ b/development/cygwin/.gitignore
@@ -0,0 +1 @@
+lyxrc.dist
diff --git a/lib/.gitignore b/lib/.gitignore
new file mode 100644
index 000..4dc6dab
--- /dev/null
+++ b/lib/.gitignore
@@ -0,0 +1,4 @@
+lyx.desktop
+lyx.desktop-temp
+lyx.png
+lyx.svg
diff --git a/lib/lyx2lyx/.gitignore b/lib/lyx2lyx/.gitignore
new file mode 100644
index 000..fc74c0b
--- /dev/null
+++ b/lib/lyx2lyx/.gitignore
@@ -0,0 +1 @@
+lyx2lyx_version.py
diff --git a/po/.gitignore b/po/.gitignore
new file mode 100644
index 000..b7acd9d
--- /dev/null
+++ b/po/.gitignore
@@ -0,0 +1,5 @@
+POTFILES
+POTFILES.in
+lyx.pot
+*.gmo
+stamp-po
diff --git a/sourcedoc/.gitignore b/sourcedoc/.gitignore
new file mode 100644
index 000..3849810
--- /dev/null
+++ b/sourcedoc/.gitignore
@@ -0,0 +1 @@
+Doxyfile
diff --git a/src/.gitignore b/src/.gitignore
new file mode 100644
index 000..51eb62f
--- /dev/null
+++ b/src/.gitignore
@@ -0,0 +1,6 @@
+lyx
+liblyxcore.a
+liblyxgraphics.a
+liblyxinsets.a
+liblyxmathed.a
+moc_Compare.cpp
diff --git a/src/client/.gitignore b/src/client/.gitignore
new file mode 100644
index 000..d27dc51
--- /dev/null
+++ b/src/client/.gitignore
@@ -0,0 +1,2 @@
+lyxclient
+lyxclient.1
diff --git a/src/frontends/.gitignore b/src/frontends/.gitignore
new file mode 100644
index 000..2473004
--- /dev/null
+++ b/src/frontends/.gitignore
@@ -0,0 +1 @@
+liblyxfrontends.a
diff --git a/src/frontends/qt4/.gitignore b/src/frontends/qt4/.gitignore
new file mode 100644
index 000..14699e4
--- /dev/null
+++ b/src/frontends/qt4/.gitignore
@@ -0,0 +1,5 @@
+Resources.cpp
+Resources.qrc
+liblyxqt4.a
+ui_*.h
+moc_*.cpp
diff --git a/src/support/.gitignore b/src/support/.gitignore
new file mode 100644
index 000..222e5ec
--- /dev/null
+++ b/src/support/.gitignore
@@ -0,0 +1,2 @@
+liblyxsupport.a
+moc_SystemcallPrivate.cpp
diff --git a/src/tex2lyx/.gitignore b/src/tex2lyx/.gitignore
new file mode 100644
index 000..827ef2b
--- /dev/null
+++ b/src/tex2lyx/.gitignore
@@ -0,0 +1,2 @@
+tex2lyx
+tex2lyx.1
-- 
1.7.7.6

Re: [PATCH] Setup .gitignore for generated files


Le 21/03/2012 10:02, Lars Gullik Bjønnes a écrit :


Setting up .gitignore or .git/info/excludes is something that should
be done. Not doing it makes it a lot harder to see actual new files
that should be added.


Definitely.

JMarc

Re: [PATCH] Setup .gitignore for generated files

Lars Gullik Bj?nnes wrote:
> 
> Setting up .gitignore or .git/info/excludes is something that should
> be done. Not doing it makes it a lot harder to see actual new files
> that should be added.
> 
> Signed-off-by: Lars Gullik Bj?¸nnes 
> ---
>  .gitignore|   13 +

IIRC it's doable through single file, or is such spread intention? P

>  boost/.gitignore  |1 +
>  config/.gitignore |6 ++
>  development/.gitignore|1 +
>  development/MacOSX/.gitignore |2 ++
>  development/cygwin/.gitignore |1 +
>  lib/.gitignore|4 
>  lib/lyx2lyx/.gitignore|1 +
>  po/.gitignore |5 +
>  sourcedoc/.gitignore  |1 +
>  src/.gitignore|6 ++
>  src/client/.gitignore |2 ++
>  src/frontends/.gitignore  |1 +
>  src/frontends/qt4/.gitignore  |5 +
>  src/support/.gitignore|2 ++
>  src/tex2lyx/.gitignore|2 ++
>  16 files changed, 53 insertions(+), 0 deletions(-)
>  create mode 100644 .gitignore
>  create mode 100644 boost/.gitignore
>  create mode 100644 config/.gitignore
>  create mode 100644 development/.gitignore
>  create mode 100644 development/MacOSX/.gitignore
>  create mode 100644 development/cygwin/.gitignore
>  create mode 100644 lib/.gitignore
>  create mode 100644 lib/lyx2lyx/.gitignore
>  create mode 100644 po/.gitignore
>  create mode 100644 sourcedoc/.gitignore
>  create mode 100644 src/.gitignore
>  create mode 100644 src/client/.gitignore
>  create mode 100644 src/frontends/.gitignore
>  create mode 100644 src/frontends/qt4/.gitignore
>  create mode 100644 src/support/.gitignore
>  create mode 100644 src/tex2lyx/.gitignore
> 
> diff --git a/.gitignore b/.gitignore
> new file mode 100644
> index 000..dcaa06d
> --- /dev/null
> +++ b/.gitignore
> @@ -0,0 +1,13 @@
> +*.o
> +.deps/
> +Makefile
> +Makefile.in
> +aclocal.m4
> +configure
> +autom4te.cache/
> +config.h.in
> +config.h
> +config.log
> +config.status
> +lyx.1
> +stamp-h1
> diff --git a/boost/.gitignore b/boost/.gitignore
> new file mode 100644
> index 000..4492822
> --- /dev/null
> +++ b/boost/.gitignore
> @@ -0,0 +1 @@
> +liblyxboost.a
> diff --git a/config/.gitignore b/config/.gitignore
> new file mode 100644
> index 000..1fe03f8
> --- /dev/null
> +++ b/config/.gitignore
> @@ -0,0 +1,6 @@
> +config.guess
> +config.sub
> +depcomp
> +install-sh
> +missing
> +py-compile
> diff --git a/development/.gitignore b/development/.gitignore
> new file mode 100644
> index 000..570c439
> --- /dev/null
> +++ b/development/.gitignore
> @@ -0,0 +1 @@
> +lyx.spec
> diff --git a/development/MacOSX/.gitignore b/development/MacOSX/.gitignore
> new file mode 100644
> index 000..270c8e8
> --- /dev/null
> +++ b/development/MacOSX/.gitignore
> @@ -0,0 +1,2 @@
> +Info.plist
> +lyxrc.dist
> diff --git a/development/cygwin/.gitignore b/development/cygwin/.gitignore
> new file mode 100644
> index 000..abceabf
> --- /dev/null
> +++ b/development/cygwin/.gitignore
> @@ -0,0 +1 @@
> +lyxrc.dist
> diff --git a/lib/.gitignore b/lib/.gitignore
> new file mode 100644
> index 000..4dc6dab
> --- /dev/null
> +++ b/lib/.gitignore
> @@ -0,0 +1,4 @@
> +lyx.desktop
> +lyx.desktop-temp
> +lyx.png
> +lyx.svg
> diff --git a/lib/lyx2lyx/.gitignore b/lib/lyx2lyx/.gitignore
> new file mode 100644
> index 000..fc74c0b
> --- /dev/null
> +++ b/lib/lyx2lyx/.gitignore
> @@ -0,0 +1 @@
> +lyx2lyx_version.py
> diff --git a/po/.gitignore b/po/.gitignore
> new file mode 100644
> index 000..b7acd9d
> --- /dev/null
> +++ b/po/.gitignore
> @@ -0,0 +1,5 @@
> +POTFILES
> +POTFILES.in
> +lyx.pot
> +*.gmo
> +stamp-po
> diff --git a/sourcedoc/.gitignore b/sourcedoc/.gitignore
> new file mode 100644
> index 000..3849810
> --- /dev/null
> +++ b/sourcedoc/.gitignore
> @@ -0,0 +1 @@
> +Doxyfile
> diff --git a/src/.gitignore b/src/.gitignore
> new file mode 100644
> index 000..51eb62f
> --- /dev/null
> +++ b/src/.gitignore
> @@ -0,0 +1,6 @@
> +lyx
> +liblyxcore.a
> +liblyxgraphics.a
> +liblyxinsets.a
> +liblyxmathed.a
> +moc_Compare.cpp
> diff --git a/src/client/.gitignore b/src/client/.gitignore
> new file mode 100644
> index 000..d27dc51
> --- /dev/null
> +++ b/src/client/.gitignore
> @@ -0,0 +1,2 @@
> +lyxclient
> +lyxclient.1
> diff --git a/src/frontends/.gitignore b/src/frontends/.gitignore
> new file mode 100644
> index 000..2473004
> --- /dev/null
> +++ b/src/frontends/.gitignore
> @@ -0,0 +1 @@
> +liblyxfrontends.a
> diff --git a/src/frontends/qt4/.gitignore b/src/frontends/qt4/.gitignore
> new file mode 100644
> index 000..14699e4
> --- /dev/null
> +++ b/src/frontends/qt4/.gitignore
> @@ -0,0 +1,5 @@
> +Resources.cpp
> +Resources.qrc
> +liblyxqt4.a
> +ui_*.h
> +moc_*.cpp
> diff --git a/src/support/.gitignore b/src/support/.gitignore
> new file mode 100644
> index 000..222e5ec
> --- /dev/null
> +++

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 20-3-2012 20:35, Richard Heck schreef:

On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:

Op 20-3-2012 0:15, Richard Heck schreef:


This is in my private repo. I have a branch master, and another 
branch bugs/7975, and another branch lyx/trunk that is tracking the 
main repo, set up as you suggested. The master and lyx/trunk 
branches were completely in sync, or so I thought. So then I did:

git checkout lyx/trunk
git merge bugs/7975
and I ended up with the merge commit, representing the new commit 
from bugs/7975 as one branch and some of the material from lyx/trunk 
as a separate branch. I think was, in part, because bugs/7975 had 
been rebased against branch. I've done some other tests, and if I 
rebase it against lyx/trunk then of course it is OK.




This is just the classic example of a merge. In one branch is the 
development of the others (master) and your development is in your 
private branch (bugs/7975). Now you merged the two together.


If you rebase your feature branch on top of master first and then do 
a merge, you will get a special type of merge, namely a fast-forward 
merge. If you would specify --no-ff, you would still get a merge commit.


I'm not sure what part is surprising to you.

What's surprising is that I get a non-fast-forward merge that is 
empty. Unsurprising that it's empty, since the two branches are 
completely synchronized, but surprising that the empty merge shows up 
as a commit. Note that, as I said, this does not happen if I've 
rebased against the other branch.


* First, I'm not sure what you mean by "the merge is empty". Indeed,  
'git show 9236a938' does not show any changes in the code, but that's 
normal. A merge only combines two sets of commits; the actual changes to 
the code is done in the commits themselves. In this case in commit 
0a0a837b and in commits 8be18455..758d0482. (try: 'gitk 
8be18455..758d0482' this will show all commits that are in this range). 
If you want to see the code changes introduced by a merge you can do:


$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

* Second, what do you mean with "two branches are completely 
synchronized" ? I guess you mean that if one branch is based on top the 
other they are synchronized ? And if they are  'synchronized', you get a 
fast-forward merge and thus no merge commit. This really is a special 
case and technically not even a merge.



So whether I get the empty commit depends upon which branch I rebased 
against, not what's actually in that branch.


If you rebase a branch A against another branch B, all commits of the 
branch B are actually included in branch A. So please don't rebase a 
branch A versus another branch B before merging it with branch C, 
because than branch B will also be merged into branch C.


If you would have rebased your feature branch against the 2.0.x branch 
before merging it into master, you are bound to run into problems if the 
commits in the 2.0.x branch are not _exactly_ the same as those in the 
master branch.


Vincent

Re: conversion of suit characters from utf to math seems broken between 2.0.2 and 2.0.3

2012-03-21 Thread Guenter Milde

On 2012-03-20, Georg Baum wrote:
> Vincent van Ravesteijn wrote:

>> I don't know what is supposed to happen to these characters.

> Basically nothing (see below).

>>> Like the other ca. 1000 out of 2751 Unicode math-related symbols without
>>> (traditional) LaTeX support, they cannot be auto-converted to a LaTeX
>>> command by LyX.

>>> * File a bug/enhancement report for "conditional" conversions in
>>>"unicodesymbols", i.e. conversions that are active if LyX detects that
>>>the required command is available in the document without auto-loading
>>>packages.

>>> * File a bug/enhancement report asking for a way to add Unicode->LaTeX
>>>conversions on a per-document basis.

> I do not believe a per-document solution is good. Why should a particular 
> conversion only be valid for one document?

Just like other settings, the available Unicode replacements can depend
on document settings that lyx is not aware of: I can add a
required package, latex command and \DeclareUnicodeCharacter (if the
document uses utf8) in the custom preamble or ERT. However, I still
cannot use the new-defined character in LyX, as LyX is unaware of this
replacement.

One possible implementation would be a new "Unicodesymbols" section for
LyX modules and layouts. Then, characters provided by packages or
preamble code can be handled by modules (and local modules would allow
the per-document configuration).

--

> You can roughly divide unicode symbols in two classes: The ones like ?
> that can be composed of glyphs existing in many fonts (in this case the
> acute symbol on top of the small letter c), and the ones like ? that
> require special glyphs.

> The first class can be handled perfectly by the unicodesymbols file for 
> almost any font that can be used by latex/pdflatex.

While the first class can be handled by the current unicodesymbols
syntax, this is currently not allowed:

 # Do only add commands that give correct output, no hacks that look "similar".

AFIK, even using a lookalike character with different semantic is
considered a "hack that looks 'similar'". Composing, turning, skaling or
moving glyphs to build a new character representation has definitely more
serious drawbacks. (This is, e.g., the reason why LyX defaults to the
T1 font encoding instead of the LaTeX default OT1.)

A "perfect" Unicode->LaTeX mapping is only given if the character in the
output document is "recoverable", i.e. if copying from the PDF, say, will
result in the same character as used in the input. (Actually, not all
character mapping in "unicodesymbols" meet this criterium.)

We might consider offering lookalikes and substitutions on a configurable
basis (as a module?).

> The second class cannot be handled in a generic way, since it either
> requires a font with an extended set of glyphs, or an additional font
> that provides the extra glyphs. In the latter case the additional font
> is almost always tied to a particular main font (otherwise the output
> would not look good, although many people don't care). What is needed
> here is a more flexible mechanism for mapping these symbols to LaTeX
> commands: Depending on the main document font chosen, LyX should use
> different LaTeX commands provided by different packages. 

While in this case the output can be "perfect", the syntax of LyX's
unicodesymbols file needs additions to handle the conditional mappings.

> E.g. if the main document font is times, it could output ? with 
> $\varheartsuit$ using txfonts.sty, with $\varheartsuit$ using pxfonts.sty if 
> the main font is palatino, or else with \ding{170} using pifont.sty.
> You cannot always use pifont, since it looks bad for some fonts, e.g. times 
> (compare $\heartsuit$ with \ding{170}).

As txfonts, pxfonts, kmath, and kpfonts all change the look of math
symbols as well as spacing in equations etc. (compare e.g. the math
typesetting in the two Times-using example documents
http://milde.users.sourceforge.net/Matheschriften/txfonts-test.pdf and 
http://milde.users.sourceforge.net/Matheschriften/tgtermes-qtxmath-MnSymbol-test.pdf
), they should *never* be automatically loaded.

> For now, we could replace some of the removed characters with the pifont 
> versions (pifont is already used elsewhere in unicodesymbols). When removing 
> the txfonts symbols, I was not aware that some are also offered by 
> pifont.sty.

Attention: The Unicode Character Names list states that these are different
characters:

2764HEAVY BLACK HEART
x (black heart suit - 2665)

> Unfortunately I don't know how such a solution could look like in practice. 

Mappings provided by a module are one possibility, suited for
glyph-providing packages that are typically added by the user (in LaTeX
via \usepackage) and have few side-effects.

Another possibility, suited, e.g., for fonts selected by LyX's font
selection GUI, is an extension to the syntax of unicodesymbols, adding
conditionals and alternatives, e.g.

 0x2665 "" "" ""

Re: about Lyx in general


Op 21-3-2012 13:32, Dahlmann Martin TU Ilmenau schreef:


Hello,

I am writing this to the developers list, because its more about the 
development than how to possibly manually fix a special issue that I 
might mention. Simply, if there is a manual fix, then I have not found 
it yet, which might mean that it is too hard to find. And hard to find 
would mean a poor useability.


The roadmap that I have found only contains single features. Where is 
the overall concept discussion? Also discussing how WYSIWYM actually 
may work, which sure does not have only a single way to see it.


Or the user interface and control concepts to make it more userfriendly?

Some questions that came up after trying Lyx for a few weeks:

How can I change the list icon that I see in the editor?



What list icon do you mean ?

Why are there still different Headline levels? (compare to  in 
XHTML 2.0)




I don't know what you mean. The type of headline you need depends on the 
structure of the document you are writing.


How can I configure which icon appears in a toolbar, and which does 
not? (to remove the useless ones manually, e.g. text style, paragraph 
settings)




You can edit Resource/ui/stdtoolbars.inc. There has been done work on a 
toolbar editor, but it is not yet finished.


There are toolbar icons for figure and table environments, but why is 
there none for formulars?




There is one for formulas as well. However, for some unknown reason, the 
"Insert math", "Insert graphics" and "Insert table" are separate from 
most of the other "Insert... " icons.


Similar the figure environment cannot be chosen using the context 
menu, like the math ones.




What do you mean ? How many figure environments are there ?



Why can the user choose from so many math environments (align, array, 
...) and even has to? Some do not work right. Why not simply keep the 
one that is working best?




It all depends on what kind of formula you want to insert. Is it a 
derivation ? Is it a matrix equation ? Is it a system of equations ? Is 
it a formula which is too long for a single row ? etc.


Why can the user choose from that many different tex2pdf tools? One 
single selection to export as PDF is much easier to use and less 
confusing.




Because different people want to use different tools, and some documents 
require another tools than others.


I agree, we could make it more clear which is the standard one for 
people that are confused by so many options.


I would like to see a Lyx lite version with only WYSIWYM, all WYSIWYG 
features removed. Also most Options removed to keep it simple (keep 
the "best" option).




Your feature request is to remove a lot of features. I think a lot of 
other people will start complaining if we do that. Why are you so 
bothered by features. You don't have to use them if you don't want to.


If there is a standard, then force the user to follow it! Do not add 
many options to choose from (= many ways to do it wrong).




One of the most heard complaints about LyX is that LyX prentends to know 
better what the user wants than the user himself. This would make this 
even worse for that type of user.



Content and Layout are currently still together in the same file. Does 
Lyx not want to follow the concept of separation of content and 
formatting?




This is separated. The formatting is defined by the class, style, layout 
and module files. If you have special formatting in your document, it is 
adviced to use Character styles, instead of changing the formatting locally.



WYSIWYG list (just what I saw so far during my short test):

* text alignment (should just allways be left in the editor to avoid 
too large spaces between words)




Other people want to have the text justified on the screen.

In 2.1 there will be an option to justify or not the text on screen. 
However, this is yet another option, while you want to remove all 
options. Do you mean you want all options to be fixed to what _you_ 
think is the *best* option ?


* text and paragraph formatting like color (em as formatting is 
WYSIWYM, setting a color is WYSIWYG)




We advice to use Character styles, custom insets etc. for this. However, 
other people want to have the ability to set the color.



* image alignment, scaling, rotating ...



?

* setting image size manually in the editor (Where is the auto scale 
option to fit the screen while editing?)




Yes, I wanted to implement something that scales the images to a fixed 
size for a long time.


The important final question: Does Lyx aim to be fully WYSIWYM and may 
be try new concepts, or does it want to keep LATEXs WYSIWYG features 
and only be a LATEX Editor?




(I've no idea what you mean with "LaTeX's WYSIWYG features" ?)

One of the largest things that we would like to add to LyX is a layout 
editor. This would be able to more easily specify the formatting in a 
single separate file, and even less in the document itself. Then we 
could also move a lot of the

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

Vincent van Ravesteijn wrote:
> all commits that are in this range). If you want to see the code changes 
> introduced by a merge you can do:
>
> $ git diff 9236a938 9236a938^1
>
> This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).



Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Vincent

Re: Updates to gitolite progress


Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :

If you want a tree for both 2.0.x and 2.1.0svn, you can do the following:

Assume you have a git clone in /lyx, you can clone this with

git clone -s -b 2.0.x /lyx /lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to branch. 
I don't want to be a git jedi just now, so I applied the patch I had to 
my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.

I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I do 
a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs list.


OK, I think, the stuff has been committed from my shared 2.0.x directory 
to the original lyx checkout on my computer, so I have to push there too.


But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x -> 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a patch 
to branch (please tell me there is!). I understand that plenty of 
probably exciting and complicated ways of working on a branch have been 
given, but I would like to start with trivial stuff like making a commit 
of a bite-size patch on a branch.


JMarc

Wiki page editing

Hello,

I'm willing to edit the web pages after 2.0.3 is out, but now when I try to
login nothing happens.
Has the password been changed ?

-- 
Jean-Pierre

Re: Wiki page editing

Jean-Pierre Chrétien wrote:
> Hello,
> 
> I'm willing to edit the web pages after 2.0.3 is out, but now when I try to
> login nothing happens.
> Has the password been changed ?

No, its broken. Christian is slowly trying to recover. Pavel

Re: Wiki page editing

Pavel Sanda  lyx.org> writes:


> 
> No, its broken. Christian is slowly trying to recover. Pavel
> 

Ok, I will wait then. Does he need help ? I'm running pmwikis for my personal
needs (after seeing lyx wiki features :-)

-- 
Jean-Pierre

Re: Updates to gitolite progress


Op 21-3-2012 15:51, Jean-Marc Lasgouttes schreef:

Le 12/03/2012 19:56, Vincent van Ravesteijn a écrit :
If you want a tree for both 2.0.x and 2.1.0svn, you can do the 
following:


Assume you have a git clone in /lyx, you can clone this with

git clone -s -b 2.0.x /lyx /lyx20x

This will clone your repo, but it will reuse the objects. This means
that the second repo is much smaller than the first one.


OK, I have done that, and now I am trying to backport a patch to 
branch. I don't want to be a git jedi just now, so I applied the patch 
I had to my 2.0.x branch checkout, did 'git add' for the modified files,

a commit for good measure.


There is also a 2.0.x branch in your first clone, so you can just 
cherry-pick the commit to master directly onto this 2.0.x branch, and 
push from there.




I am happy, I can do 'git format-patch' and see a nice formated patch 
like the grown ups do.


Alas, now comes the time to put my patch to the git.lyx.org server. I 
do a 'git push' in my 2.0.x branch to see what happens. Things happen 
(cryptic messages I do not have anymore), but nothing in the lyx-cvs 
list.


OK, I think, the stuff has been committed from my shared 2.0.x 
directory to the original lyx checkout on my computer, so I have to 
push there too.


Yes.

You can also push directly from your 2.0.x clone by adding the remote to 
this clone:


$ git remote add lyx g...@git.lyx.org:lyx

Now you can push your branch to "lyx":

$ git push lyx 2.0.x

Use

$ git remote -v

to see the remotes that are set up for a clone. For your 2.0.x clone 
you'll indeed see that the origin the your original clone.




But when I push in lyx/ (which is the full checkout), I get:

fantomas: git push
To g...@git.lyx.org:lyx
 ! [rejected]2.0.x -> 2.0.x (non-fast-forward)
error: failed to push some refs to 'g...@git.lyx.org:lyx'
To prevent you from losing history, non-fast-forward updates were 
rejected

Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.


Where do I go from there? There has to be a simple way to commit a 
patch to branch (please tell me there is!). I understand that plenty 
of probably exciting and complicated ways of working on a branch have 
been given, but I would like to start with trivial stuff like making a 
commit of a bite-size patch on a branch.


The hint in the error message says that you have to merge the remote 
changes before you push. This is the same as that svn would tell you 
that your repo is not up to date.


Most probably the following will solve this:

$ git pull --rebase

(though I recommend to do 'git fetch', 'git merge --ff-only', and only 
rebase your feature branch on top of master when you really want to push 
it).





JMarc


Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

Vincent van Ravesteijn wrote:
> Op 21-3-2012 15:00, Pavel Sanda schreef:
>> Vincent van Ravesteijn wrote:
>>> all commits that are in this range). If you want to see the code changes
>>> introduced by a merge you can do:
>>>
>>> $ git diff 9236a938 9236a938^1
>>>
>>> This will show you that the merge is not empty at all.
>> Is there a way how to obtain full listing of diffs which went into the 
>> master?
>> (I mean something like git log -p produced by git-svn on the old svn 
>> trunk).
>>
>
> Something like this:
>
> $ git log 9236a938^1..9236a938 --no-merges -p
>
> you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p 
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


"git log -p" really shows all commits that went into master. The problem 
is that by using "git log" you're forcing the history to be linear, 
while it actually isn't. Git therefore sorts the commit based on the 
date of the commit (not the date of the merge). So, the date of the 
actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


"git log -p" really shows all commits that went into master. The 
problem is that by using "git log" you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date of 
the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:

$ git log -p --simplify-merges

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by


Op 21-3-2012 16:48, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.
Is there a way how to obtain full listing of diffs which went into 
the

master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


"git log -p" really shows all commits that went into master. The 
problem is that by using "git log" you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date 
of the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only 
Richard's commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:


or:

git log -p -m --first-parent

-m

   This flag makes the merge commits show the full diff like regular
   commits; for each merge parent, a separate log entry and diff is
   generated. An exception is that only diff against the first parent
   is shown when /--first-parent/ option is given; in that case, the
   output represents the changes the merge brought /into/ the
   then-current branch.



Vincent

Re: Updates to gitolite progress



There has to be a simple way to commit a patch to branch (please tell 
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you 
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x 
will automatically be merged into the master. This can be done, because, 
in general, all fixes that go into 2.0.x are in master too.


Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

Vincent van Ravesteijn wrote:
>>> change that was merged in by Richard was March 13.
>>>
>>> You can see this immediately if you limit the output to only Richard's 
>>> commits:
>>>
>>> $ git log -p --author='Richard Heck'
>>>
>>> Vincent
>>
>> The following shows the diffs in order they got into master:
>>
> or:
>
> git log -p -m --first-parent

I see. Actually even git log -p is fine with me, I just didn't catch
that the commit was from March 13...

Pavel

Re: Current git workflow

Georg Baum wrote:
> commit yet)? I guess it would look like
> 
> git checkout -b fixfileformat
> git commit
> git checkout master
> git merge fixfileformat
> git commit
> git branch -d fixfileformat

The simplistic SVN-like scenario is just:

git pull (update from public repo)
git commit (just local commit in your tree)
git push (push the commit to public repo)

Pavel

Re: Updates to gitolite progress


Le 21/03/2012 16:56, Vincent van Ravesteijn a écrit :



There has to be a simple way to commit a patch to branch (please tell
me there is!).




I forgot to mention: Ideally, if we do it the git-way completely, you
would only have to commit a patch to the 2.0.x branch. Later, the 2.0.x
will automatically be merged into the master. This can be done, because,
in general, all fixes that go into 2.0.x are in master too.


That would mak sense. I intend t eventually understand the git way, but 
my first goal is to walk a few baby steps by myself.


JMarc

Re: Wiki page editing

2012-03-21 Thread Richard Heck


On 03/21/2012 11:09 AM, Jean-Pierre Chrétien wrote:

Pavel Sanda  writes:



No, its broken. Christian is slowly trying to recover. Pavel


Ok, I will wait then. Does he need help ? I'm running pmwikis for my personal
needs (after seeing lyx wiki features :-)

Apparently, the problem is that the version of pmwiki we have doesn't 
like the version of PHP we have. So the former needs to be upgraded. I 
think Christian was hoping to get to it this weekend.


Richard

Re: Updates to gitolite progress


Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing a 
full rebuild everytime, I have to have two checkouts living in different 
places, right? And moreover, I have to update satus.20x.



You can also push directly from your 2.0.x clone by adding the remote to
this clone:

$ git remote add lyx g...@git.lyx.org:lyx


OK

Now you can push your branch to "lyx":

$ git push lyx 2.0.x


How come I have to specify "lyx 2.0.x". Isn't it possible to setup the 
branch so that "git push" will do the right thing?



The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?

Thanks.

JMarc

Re: Updates to gitolite progress




Now you can push your branch to "lyx":

$ git push lyx 2.0.x


How come I have to specify "lyx 2.0.x". Isn't it possible to setup the 
branch so that "git push" will do the right thing?


"git push" will by default push to the remote which is tracked by the 
current branch. If the current branch does not track anything it will 
push to "origin".


To see and edit what is being tracked by a branch, you can type

$ git config -e

There will be something like:

[branch "2.0.x"]
remote = origin
merge = refs/heads/2.0.x

So, the branch 2.0.x tracks the branch "2.0.x" from the remote "origin". 
So, you can configure it however you want it.






The hint in the error message says that you have to merge the remote
changes before you push. This is the same as that svn would tell you
that your repo is not up to date.

Most probably the following will solve this:

$ git pull --rebase


In which repository?


In the one from where you are trying to push to the git.lyx.org from.

Vincent

Re: Updates to gitolite progress

Jean-Marc Lasgouttes wrote:
> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
>> There is also a 2.0.x branch in your first clone, so you can just
>> cherry-pick the commit to master directly onto this 2.0.x branch, and
>> push from there.
>
> But If I want to compile both the master and the branch without doing a 
> full rebuild everytime, I have to have two checkouts living in different 
> places, right? And moreover, I have to update satus.20x.

I believe more repositories are necessary and while its possible to clone
locally one from the other (and thus save some disk space), it will bring
problems with cryptic error messages for newcomers as you could see.

The simplest SVN-like scenario:

1. Checkout full repo 
git clone g...@git.lyx.org:lyx trunk
2. Full mirror of branch as well, not through clone
cp -r trunk branch; cd branch
3. Checkout branch 2.0.x
git checkout 2.0.x
   (by default you commit & push directly to 2.0.x branch in "branch" dir from 
now on)

Now for the commit backporting:
(4. commit & push change into trunk 5. go to branch directory)

6. git pull (receive trunk change to the branch repo as well)

One problem is that the commit never equals thanks to status.20x changes,
so one of many ways could be to remember hash from the trunk commit (say ) 
and:

7. git show  | git apply   (patch the current tree with the commit XXX)
8. add your changes to status.20x
9. git commit
10. git push

Pavel

Re: Current git workflow

2012-03-21 Thread André Pönitz

On Wed, Mar 21, 2012 at 05:04:56PM +0100, Pavel Sanda wrote:
> Georg Baum wrote:
> > commit yet)? I guess it would look like
> > 
> > git checkout -b fixfileformat
> > git commit
> > git checkout master
> > git merge fixfileformat
> > git commit
> > git branch -d fixfileformat
> 
> The simplistic SVN-like scenario is just:
> 
> git pull (update from public repo)
> git commit (just local commit in your tree)
> git push (push the commit to public repo)

Methinks

  git commit (just local commit in your tree)
  git pull --rebase (update from public repo and put local changes on top)
  git push (push the - possibly adjusted - commit to public repo)

is closer to the SVN way.

Andre'

Re: [patch] full support for table rotations


Am 20.03.2012 09:31, schrieb Vincent van Ravesteijn:


+ if (tabular.rotate != 0)
+ rotateTabularAngleSB->setValue(tabular.rotate);
+ else
+ rotateTabularAngleSB->setValue(90);


rotateTabularAngleSB->setValue(tabular.rotate == 0 ? 90 : tabular.rotate);


I never understood why this form is preferred. For me my version consumes more lines but I can see 
faster what it is about.



- 400
+ 402





I'd prefer not to tinkle with the size.


Me too but I cannot reduce the height back to 400, 402 are now required in the designer. But there 
are only 2 pixels and I added an edit field which consumes this more space.



@@ -5196,6 +5196,14 @@ bool InsetTabular::oneCellHasRotationState(bool rotated,
return false;
}

+bool InsetTabular::tableIsRotated() const


I think this function is not useful.


Indeed.


case Tabular::TOGGLE_ROTATE_TABULAR:
- tabular.rotate = !tabular.rotate;
+ // when pressing the rotate button we default to 90° rotation
+ if (tableIsRotated())
+ tabular.rotate = 90;
+ else
+ tabular.rotate = 0;
break;


This seems wrong.


Yes, I must be the opposite.


Missing: Tex2lyx - TODO entry: Import rotated tables (and cells probably) ?


I can add this, but that tex2lyx cannot handle rotations in tables is not 
introduced by this commit.

many thanks for the review and regards
Uwe

Re: [lyx/refs/heads/2.0.x] GuiTabular.cpp: fix bug #8084


Am 20.03.2012 09:47, schrieb Vincent van Ravesteijn:


I would write:

bool const fixed_width_multirow = multirowCB->isChecked() && width != "0pt";
bool const inherit_column_align = !fixed_width_multirow;
if (inherit_column_align)
setHAlign(param_str);

Now it is immediately clear that we only set the column alignment if we inherit 
the alignment from
the column and this is only the case if do not have a multirow with a fixed 
width.


Seems that we have 2 different views on this topic. For me it is more complicated to read this out 
of the code than to read a comment. Moreover your code does not link the bug. My experience is that 
a linked bug in a comment helps for issues that will probably reappear and the multirow alignment 
topic is a bit strange and this question will arise again sooner or later.



Some more reasons to prefer clear code above an unclear comment:
- you don't make typos, grammatical errors,


Yes.


- you don't assume knowledge, you don't imply logical steps that other people 
don't understand, etc.


That is why I link to the bugreport. If I read your code without background knowledge I would be 
lost why you are doing what you do. Thus I prefer comments.



- if the code changes, the comments are often forgotten to be updated. This 
results in a lot of
outdated comments in the code,


This is no excuse. When code is changed the comment also needs to be changed accordingly- I was 
taught that comments are also code and every developer must treat it as such.


regards Uwe

Re: [lyx/refs/heads/master] - INSTALL.Win32: revise and update the description because since Qt 4.8 it mustn't be compiled (and can currently also not without a lot of hacking). Moreover we have now a

Am 20.03.2012 10:04, schrieb Vincent van Ravesteijn:

What is incomplete?
I changed it because it didn't work anymore. With Qt 4.8 things have changed
and Peter did a good
job with the script so that the former manual settings are now automatically
set.

It still worked perfectly for me. What didn't work anymore ?

Which settings had to be set manually
which are now set automatically ?

The CMAKE variable settings, see the diff of my change for a list of them. (All
;-) )

At some point you say "where you copied the dependencies to". I have no idea
what you mean with this.

This was also not clear in the old version. I now added a further step:

It suddenly requires CMakeScript

This is the official CMake release plus a script that is provided directly by
Peter. So we have
the maintainer in our team.

I'm not sure whether Peter is still in our team.

I think yes.

If you were a CMake expert, ok. But if there is a CMake problem, you come to
the list and ask others
to fix it. Now suddenly you promote tools which are only used by yourself.

The Install.Win32 file is for new developers. I guess existing developers will never read it as they
already have their setup. So I tried to make it as simple as possible.

No other developer have
ever heard of CMakeScript before, let alone about Ninja. You nowhere even
explains what Ninja is ?

Have you tried it? It generates studio files and solutions for debugging too.

No,

Why are you then telling it does not?

but you don't mention it at all in the file.

> I'm afraid that this will generate a merged build by default which is rather
useless to use in
> MSVC.

Please test and then be afraid.

Why do you then have to manually supply the path to the dependencies ? The
previous workflow did
this automatically.

In what way do you have to be a CMake expert to use the GUI ? Start the gui,
browse to the correct
folder, and check some options. What is difficult ?

Maybe you remember that I had to ask on the list how this is done. And when switching to branch or
from branch I had to do this again.

CMake searched for Qt, so if it could find it,
there was no need to supply it manually. The GNUWin32 directory was set
automatically.

Not on my setup.

So, you
prefer to do this all manually ?

You only have to set the path once and never again when switching between branches. This is much,
much easier and I don't need to learn the different names of Cmake variables.

Why wouldn't the CMake GUI allow you to compile master and branch parallel ?

I never managed to get this and on this list I was told that this doesn't work and so a script was
proposed.

It doesn't make sense
that you would want to compile both with the same settings.

I do this since 2 years. Why should I use different settings? I only need to distinguish between
release and debug builds, but for this you can call the build script with different

Re: Updates to gitolite progress

2012-03-21 Thread Tommaso Cucinotta


Il 21/03/2012 16:44, Jean-Marc Lasgouttes ha scritto:

Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :

There is also a 2.0.x branch in your first clone, so you can just
cherry-pick the commit to master directly onto this 2.0.x branch, and
push from there.


But If I want to compile both the master and the branch without doing 
a full rebuild everytime, I have to have two checkouts living in 
different places,


that's how I'm used to work, also because normally I have different 
configure options for trunk/master (more debug) w.r.t. branch (less 
debug, more optimiz., try system libs). I've noted down the receipt I 
followed to share the patches between the two separate folders/repos, at:


  http://wiki.lyx.org/Devel/LyXGit

(last bullet of Cloning the Repository). I can't count how many warnings 
I received from git seniors about using "--shared", still it's just what 
I need :-), as my disk-space is finite and my mobile broadband has a 
GB/month cap :-(.


T.

Re: [PATCH] Setup .gitignore for generated files

Pavel Sanda  writes:

| Lars Gullik Bj?nnes wrote:
>> 
>> Setting up .gitignore or .git/info/excludes is something that should
>> be done. Not doing it makes it a lot harder to see actual new files
>> that should be added.
>> 
>> Signed-off-by: Lars Gullik Bj?¸nnes 
>> ---
>>  .gitignore|   13 +
>
| IIRC it's doable through single file, or is such spread intention? P

Yes. It is intentional.

The generic stuff is handled from the top, more specifics, f.ex.
moc_*.cpp is handled where it happens.

If a file suddenly appears in a location where we did not expect we
should now about it.

-- 
   Lgb

Re: Updates to gitolite progress

Vincent van Ravesteijn  writes:

>>> There has to be a simple way to commit a patch to branch (please
>>> tell me there is!).
>>
>
| I forgot to mention: Ideally, if we do it the git-way completely, you
| would only have to commit a patch to the 2.0.x branch. Later, the
| 2.0.x will automatically be merged into the master. This can be done,
| because, in general, all fixes that go into 2.0.x are in master too.

Hmm... that would be a very bad idea.
And the premise is in general not true.

-- 
   Lgb

Re: Updates to gitolite progress

Pavel Sanda  writes:

| Jean-Marc Lasgouttes wrote:
>> Le 21/03/2012 16:14, Vincent van Ravesteijn a écrit :
>>> There is also a 2.0.x branch in your first clone, so you can just
>>> cherry-pick the commit to master directly onto this 2.0.x branch, and
>>> push from there.
>>
>> But If I want to compile both the master and the branch without doing a 
>> full rebuild everytime, I have to have two checkouts living in different 
>> places, right? And moreover, I have to update satus.20x.
>
| I believe more repositories are necessary and while its possible to clone
| locally one from the other (and thus save some disk space), it will bring
| problems with cryptic error messages for newcomers as you could see.
>
| The simplest SVN-like scenario:
>
| 1. Checkout full repo 
| git clone g...@git.lyx.org:lyx trunk
| 2. Full mirror of branch as well, not through clone
| cp -r trunk branch; cd branch

No...
(perhaps... it does not seem optimal, does not take advantage that
things are on same fs f.ex.))

-- 
   Lgb

Re: [patch] full support for table rotations