Re: Fwd: GSOC: reStructuredText support for LyX?

2013-04-25 Thread Guenter Milde 
On 2013-04-24, Nico Williams wrote:
 On Wed, Apr 24, 2013 at 4:40 PM, Guenter Milde mi...@users.sf.net wrote:

 This means it might be easier to use XML as intermediate format: Docutils
 can generate a native XML representation of a reStructuredText document and
 also re-generate a document tree from this representation.
 There are attempts to have a native LyX XML format (either replacing the
 current fileformat or as an alternative representation), so XSLT
 transformations may help to transform between these two.

 LyX - XML converter:

 https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml
 https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py
 https://github.com/nicowilliams/lyx2rfc/blob/master/src/xml_streamer.py

 After that apply an XSL to change schemas.

Yes, this was my idea. 

However, going the XML/XSL way we still need to handle the
incompatibilities between the document models.

I don't know XSL, so my contributions to such a project would be limited to
answering questions about Docutils/reStructuredText and testing.

If you are interested, there is reference material in
http://docutils.sourceforge.net/docs/ref/ including the
Docutils Generic DTD http://docutils.sourceforge.net/docs/ref/docutils.dtd
and an (incomplete) description of the document model
http://docutils.sourceforge.net/docs/ref/doctree.html

Thanks, 

Günter

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

2013-04-25 Thread Jean-Marc Lasgouttes 

24/04/2013 21:41, pdv:

Why do you add 0x61 to the values?


That's just for easy reading when looking at what exactly gets written
to the map; In this way the codes are a, b, c ...


That makes sense.


I do not think there is a need to have a map per document. A shared map
stored in TextLetrics should be OK (like singleWidth currently).


I was worried that the map might grow out of proportion, e.g. when
leaving the application open for a long time and since there are more
words than characters this will be worse than for singleWidth.


I would start with the simple solution and then worry about a more 
complicated one. A shared map will take less total memory. If acces time 
is bad, then it may be worth implementing qHash(docstring) (by aping the 
QString version) and use a QHashdoctring, int.



When typing it's unavoidable to generate all partials of a word; these
are removed again from the map so that only the final word remains;
However nothing is done to remedy the reverse: when deleting a word
character by character all partials will end-up in the map;


Did you do some measurement to ensure that there is a gain of doing that?


I don't think it makes so much difference in time. It was merely to
avoid filling the map with useless entries, especially if a single map
is used.


My policy in these kind of situation is to implement the simple solution 
and do optimization only when some measurement (profiling) proved that 
there is a problem to solve. Remember Knuth quote: Premature 
optimization is the root of all evil (or at least most of it) in 
programming.


Do not hesitate to post patches as often as needed. While I do not have 
time to look at the hard parts of the patch right now, I think we move 
in the right direction.


JMarc

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

2013-04-25 Thread Jean-Marc Lasgouttes 

24/04/2013 21:14, pdv:

Sorry, the problem is obvious.
I'm using cmake and although --enable-stdlib-debug is mentioned in the
install notes, I can't set that option.
Once (more or less) ready I build manually with the
LyX-Mac-binary-release.sh script, which by default disables this option.
When I enable it, lyx crashes right away when starting. Don't know yet
whether this signals other problems or if there is a problem with this
option.


Actually the stdlib-debug option does not work on OS X (it may depend on 
gcc and boost versions, I do not know). But I can use it on linux and 
tell you what I find :)


JMarc

Re: [LyX master] Hungarian Tutorial.lyx: revert last change

2013-04-25 Thread Scott Kostyshak 
On Mon, Apr 22, 2013 at 3:58 PM, Scott Kostyshak skost...@lyx.org wrote:
 On Sun, Apr 21, 2013 at 3:32 PM, Uwe Stöhr uwesto...@web.de wrote:
 Am 20.04.2013 07:51, schrieb Scott Kostyshak:
 To make sure, you are asking me to backport all of the recent changes
 I've made to the manuals and example files in trunk?

 I mean the changes where you encountered export problems and therefore set
 the default output format to pdf2.

 Ah, I'm glad I asked. OK I will look through the commits and
 cherry-pick the ones that set the default output format. I don't think
 it's always to pdf2. IIRC, some required format pdf.

Done starting at edd91d5e.

Scott

[PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Hugo Hinterberger 
Hallo,

I am using a development build in order to have SVN 1.7 support and I 
noticed some issues with the build environment on Windows.

IMHO one issue needs to be fixed in the repository.
I attached (tried to - first post with Pan) a patch file that resolves 
the issue for me.

The other issue I noticed is that the regex2.dll library and possibly 
other files are missing from the msvc2010-deps package.

Kind regards,
Hugo

Re: Beamer goto buttons and text hyperlinks

2013-04-25 Thread Scott Kostyshak 
On Tue, Apr 23, 2013 at 11:32 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 20/04/2013 09:06, Jürgen Spitzmüller a écrit :

 Scott Kostyshak wrote:

 Do you think it's better to add \hyperlink support to the label inset
 or to make a separate, collapsable hypertarget inset? \hypertarget
 takes two arguments: the name and the text. The name could be set in
 the settings, and the text in the collapsable inset.


 I'd prefer not to add too many different insets for similar functions. But
 the
 collapsable solution adds some convenience.


 We could maybe have an inset that is only a button when no extra text is
 needed and a collapsablme inset otherwise. Somethin in between InsetCommand
 and InsetCollapsable.

I find this very interesting. If I understand correctly, it would work
like this:

When I go to insert  label, it inserts a button and everything works
exactly as it does now, except that if I click on the hypertarget
checkbox in the label settings dialog, the button is now a collapsable
inset. And if there is a selection, insert  label can default to
having the hypertarget checkbox checked and having that text put in
the collapsable box. The current behavior when there is text selected
is for the text to be deleted.

Would we also want to do this for the cross ref inset? It could work
in a similar way: there is a checkbox for hyperlink. If checked, the
inset becomes a collapsable inset. Note that in this case more is done
if hyperlinkCB is checked: the hypertargets would be shown along with
the labels, either in the same tree widget (perhaps we could give the
hypertargets a prefix so that when grouped it's easy to navigate) or
there could be a split tree widget, more clearly separating labels
from hypertargets.

Jürgen, do you still prefer to have the cross ref code copied over to
the hyperref inset? My hesitation is that there would be a lot of
duplicate code. Also, I think that the text hyperlinks have more in
common with references than they do with hrefs to web, emails, and
files. However, I think your argument is that overloading the cross
ref dialog would make the user experience more complicated and there
would be a larger chance of a regression for this important part of
the code. This makes sense to me also.

Scott

Re: [PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Hugo Hinterberger 
On Thu, 25 Apr 2013 09:59:04 +, Hugo Hinterberger wrote:

 IMHO one issue needs to be fixed in the repository.
 I attached (tried to - first post with Pan) a patch file that resolves
 the issue for me.

Since I do not see the patch attached I put it in the message body:

= CPack-NSIS.patch =
 development/cmake/LyxPackaging.cmake | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/development/cmake/LyxPackaging.cmake b/development/cmake/
LyxPackaging.cmake
index 4f9091b..1788b0a 100644
--- a/development/cmake/LyxPackaging.cmake
+++ b/development/cmake/LyxPackaging.cmake
@@ -32,9 +32,13 @@ FILE(STRINGS ${TOP_CMAKE_PATH}/LyX_summary.txt 
CPACK_PACKAGE_DESCRIPTION_SUMMA
 
 set(CPACK_PACKAGE_INSTALL_DIRECTORY CMake ${LYX_INSTALL_SUFFIX})
 
-#
-# needed by rpm
-set(CPACK_SET_DESTDIR ON)
+if(WIN32)
+   # does not work on Windows, and NSIS
+   set(CPACK_SET_DESTDIR OFF)
+else()
+# needed by rpm
+   set(CPACK_SET_DESTDIR ON)
+endif()
 FILE(READ ${TOP_CMAKE_PATH}/LyX_license.txt CPACK_RPM_PACKAGE_LICENSE)
 set(CPACK_RPM_PACKAGE_GROUP Applications/Publishing)
 set(CPACK_RPM_PACKAGE_VENDOR The LyX team)
= CPack-NSIS.patch =

Re: ps2pdf13 - ps2pdf14 ?

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 11, 2013 at 5:20 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 08/04/2013 08:04, Jürgen Spitzmüller:

 Scott Kostyshak wrote:

 I don't have any particular reason for changing it and the safe thing
 would be to leave it alone, but I'm curious what others think.


 My vote would be to use plain ps2pdf without any format binding.


 +1

It's in at 959d2c5.

Scott

Re: [PATCH] Spelling: Postscript - PostScript

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 11, 2013 at 3:46 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 11/04/2013 04:51, Scott Kostyshak:

  From what I understand, PostScript is the correct way to write it.

 Does anyone have an opinion on this?


 Why not. If you go this way, git grep tells me that there are other places
 needing attention.

Is the attached patch OK? I did not make the change in the translated
manuals. Should I? I don't know how the translation process works for
the manuals.

Scott
From d31db4ee94d433a9a57fe58e79a13a6f4e06ddb3 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak skost...@lyx.org
Date: Wed, 10 Apr 2013 22:47:44 -0400
Subject: [PATCH] Spelling: Postscript - PostScript

---
 lib/configure.py  |6 +++---
 lib/doc/EmbeddedObjects.lyx   |2 +-
 lib/doc/LaTeXConfig.lyx   |2 +-
 lib/doc/UserGuide.lyx |6 +++---
 lib/examples/CV-image.eps |2 +-
 lib/examples/ItemizeBullets.lyx   |4 ++--
 lib/examples/ca/ItemizeBullets.lyx|2 +-
 lib/examples/es/ItemizeBullets.lyx|2 +-
 lib/examples/fr/ListesPuces.lyx   |2 +-
 lib/examples/instant_preview.lyx  |4 ++--
 lib/examples/powerdot-example.lyx |4 ++--
 lib/examples/seminar.lyx  |4 ++--
 lib/scripts/lyxpreview2bitmap.py  |4 ++--
 lyx.1in   |2 +-
 src/Length.h  |2 +-
 src/LyXAction.cpp |4 ++--
 src/frontends/qt4/GuiDocument.cpp |2 +-
 src/frontends/qt4/ui/PrefPrinterUi.ui |2 +-
 src/graphics/GraphicsParams.cpp   |4 ++--
 src/graphics/epstools.cpp |2 +-
 src/insets/InsetGraphics.cpp  |4 ++--
 src/tex2lyx/test/foo.eps  |2 +-
 22 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/lib/configure.py b/lib/configure.py
index 946d8f7..3dbfc38 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -572,12 +572,12 @@ def checkFormatEntries(dtl_tools):
 'nedit', 'gedit', 'notepad', 'geany', 'leafpad', 'mousepad'],
 rc_entry = [r'''\Format bibtex bibBibTeX %%
  text/x-bibtex''' ])
 #
-#checkProg('a Postscript interpreter', ['gs'],
+#checkProg('a PostScript interpreter', ['gs'],
 #  rc_entry = [ r'\ps_command %%' ])
-checkViewer('a Postscript previewer', ['kghostview', 'okular', 'evince', 
'gv', 'ghostview -swap'],
+checkViewer('a PostScript previewer', ['kghostview', 'okular', 'evince', 
'gv', 'ghostview -swap'],
 rc_entry = [r'''\Format epseps EPS 
%%vectorimage/x-eps
 \Format eps2   epsEPS (uncropped)%%
vector
-\Format ps ps  Postscript t  %%
document,vector,menu=export   application/postscript'''])
+\Format ps ps  PostScript t  %%
document,vector,menu=export   application/postscript'''])
 # for xdg-open issues look here: 
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg151818.html
 # the MIME type is set for pdf6, because that one needs to be 
autodetectable by libmime
 checkViewer('a PDF previewer', ['pdfview', 'kpdf', 'okular', 'evince', 
'kghostview', 'xpdf', 'acrobat', 'acroread', 'mupdf', \
diff --git a/lib/doc/EmbeddedObjects.lyx b/lib/doc/EmbeddedObjects.lyx
index 4dc2aa5..60ff0d3 100644
--- a/lib/doc/EmbeddedObjects.lyx
+++ b/lib/doc/EmbeddedObjects.lyx
@@ -41056,7 +41056,7 @@ You can export your document to PostScript using the 
menu
 \family sans
 File\SpecialChar \menuseparator
 Export\SpecialChar \menuseparator
-Postscript
+PostScript
 \family default
 .
  You can view your document as PostScript via the 
diff --git a/lib/doc/LaTeXConfig.lyx b/lib/doc/LaTeXConfig.lyx
index 53a123b..5a69841 100644
--- a/lib/doc/LaTeXConfig.lyx
+++ b/lib/doc/LaTeXConfig.lyx
@@ -6373,7 +6373,7 @@ Notes:
 dvipost
 \family default
  is a post-processor for DVI files created by LaTeX and TeX.
- It is needed by LyX to generate DVI or Postscript output of change tracking
+ It is needed by LyX to generate DVI or PostScript output of change tracking
  marks.
  To work properly, 
 \family sans
diff --git a/lib/doc/UserGuide.lyx b/lib/doc/UserGuide.lyx
index 5caf0b1..75f7544 100644
--- a/lib/doc/UserGuide.lyx
+++ b/lib/doc/UserGuide.lyx
@@ -38667,7 +38667,7 @@ text
 
 (ps2ascii)
 \family default
- text format, the document will first be converted to Postscript format
+ text format, the document will first be converted to PostScript format
  and then exported as text using the program 
 \family sans
 ps2ascii
@@ -38676,7 +38676,7 @@ ps2ascii
 \begin_layout Description
 
 \family sans
-Postscript
+PostScript
 \family default
  PostScript format using the program 
 \family typewriter
@@ -38720,7 +38720,7 @@ PDF
 \family default
  or 
 \family sans
-Postscript
+PostScript
 \family default
  is missing, you need to update your LaTeX

Re: Translations for 2.0.6

2013-04-25 Thread Richard Heck 

On 04/24/2013 02:19 PM, Pavel Sanda wrote:

Richard Heck wrote:

I thought I had done that right before. Should I remerge and send another
note?

I din't check extensively but I belive this will be concern to 2-3 people only.
git log -p po/ vs current status after remerge should give a clue.


I have a script that does this. It looks like maybe the commit failed. 
It was still sitting on my work machine yesterday.


rh

Re: Signals/Slots in Core (branch from UI improvements and non-linear enhancements)

2013-04-25 Thread Richard Heck 

On 04/22/2013 09:19 AM, Rob Oakes wrote:

Dear Developers,

If I remember correctly, as of the last developer meeting, QtCore
classes were being tolerated in the core of LyX.
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172533.html

Is this correct? Are there any examples of QtCore and Signals/Slots
being integrated into the core of LyX?

I've been corresponding with one of the GSOC students about using the
outline enhancements for a GSOC project, and it seems that moving
certain text insets to use QObject (or related) as their base class
might be an interesting goal. This would allow for insets to make use of
the signal/slot mechanism for communicating updates to the view.

In the case of the outline view and underlying TOC model, it wouldn't be
necessary to scan for changes, and would provide a nice speed boost to
the editing experience.

Would such a project be too ambitious?


There are other signal-slot mechanisms that could be used, I believe. 
Boost signals are used in the core already. I'm not sure exactly what 
the idea is here, though, so I'm not sure if that helps or not.


A larger question concerns whether this threatens to subvert the 
dispatch mechanism.


Richard

Re: Signals/Slots in Core (branch from UI improvements and non-linear enhancements)

2013-04-25 Thread Jean-Marc Lasgouttes 

I've been corresponding with one of the GSOC students about using the
outline enhancements for a GSOC project, and it seems that moving
certain text insets to use QObject (or related) as their base class
might be an interesting goal. This would allow for insets to make use of
the signal/slot mechanism for communicating updates to the view.

In the case of the outline view and underlying TOC model, it wouldn't be
necessary to scan for changes, and would provide a nice speed boost to
the editing experience.


Is scanning for changes so expensive? It seems to be that our 
updateBuffer mechanism is quite fast in practice. What is the use case?


What is the exact effect that is expected?

I agree with Richard that adding a way to avoid the dispatch mechanism 
just because that seems nice is not a good idea right now. We could move 
towards this indeed, but it should be done in all the core. Currently 
there are a lot of small things that happen in the dispatch mechanism to 
make things just work. Remember that the last 5% of the functionality is 
the most difficult to obtain :)


JMarc

Re: GSoC idea: UI improvements and non-linear writing enhancements (Technical)

2013-04-25 Thread Ashley Shan 
Hi Cyrille,

Thank you for your reply. I calculated my work time, and if I'm to work
full time for 12 weeks, then I will devote a total of 480 hours on the
project; according to my calculation, if I work full time for 9 weeks (40
hours a week) or more than 40 hours a week (50 hours a week, say), then I
still need 30 - 120 hours to finish in the 6 weeks of my summer school. I
think if I work part time during my summer school, I will be fine.

Since my school is on semester and our summer break begins from May 3, I
plan to begin my coding on May 5 and finish it by Aug 20. It's roughly 15
weeks, including 2 buffer weeks.

I will come up with a modified schedule after the first few weeks when I
get a better sense of the project, and another modified schedule after the
midterm evaluation, which I put in the 7th week.

Xueqing Shan

*Xueqing Shan*
Vanderbilt University, '16


On Wed, Apr 24, 2013 at 11:56 PM, Cyrille Artho c.ar...@aist.go.jp wrote:

 Hi Xueqing Shan,
 If it is possible for you to start coding a bit earlier than the official
 start, that would be very helpful. I appreciate your commitment of working
 almost 60 hours a week, but this may cause you to burn out in the middle
 of the project, so an alternative schedule would be preferable.

 It is OK if you cannot work for the entire 13 weeks that is assumed in the
 normal schedule, if you have courses or exams. Just plan your project
 accordingly; if you can work for the equivalent of 11 - 12 weeks full time,
 with a good plan and matching milestones, this is better than going
 overdrive to work around summer courses.

 Ashley Shan wrote:

 Hi Rob,

 Thank you for replying in such a busy schedule. Your emails are always
 helpful in clarification. I am working on my proposal and hopefully I can
 have a pretty much complete draft by the end of this week. I plan to
 submit
 and make further changes based on feedback I got if any.

 *Regarding time commitment*

 I have indicated this point in my proposal that I will have summer courses
 for 6 weeks, hence I sort of structured my schedule for the project
 accordingly. I plan to finish the majority of the work in the first 7
 weeks, during which I can work as much as 8 hours a day and 7 days a week.
 Then, when I'm having summer courses, I plan to work part-time, around
 15-20 hours a week for 6 weeks. I also put two buffer weeks in the 6 weeks
 of class. After that, I have another 2 free weeks, which I plan to put the
 last part of the project there. Hence, there are 15 weeks in total on my
 proposal.

 *Regarding setting milestones*

 Currently I'm buried in finals so I haven't got time to systematically
 familiarize myself with LyX internals. I searched the web but didn't see
 any clear route map about where I should get started or at least a good
 overview for a beginner of LyX so I can plan my project. I have emailed
 Abdel Younes about LyX internals. I will continue to look for resources.
 I would appreciate if we can set up a Google Chat some time next week
 after
 your deadline. Right now, I can work on other parts first and get help
 from
 Abdel and other people in the mailing list.

 *Regarding proposal details*

 I have finished my schedule for first week; it has daily milestones. I
 plan
 to familiarize myself with LyX development, Qt, and git in the first week
 (the basics). I plan to work on the second or the second and the third
 week
 tomorrow, which would have daily milestones as well if they are devoted to
 studying the basics. I have two buffer weeks, weekly progress reports,
 three progress evaluations (including one mid term), and one final
 evaluation.
 I realize that I know very little about terminologies, but I'm trying to
 be
 as strict as possible regarding term usage.

 I look forward to hearing from you. Good luck with the project you are
 working on.

 Xueqing Shan
 --**--
 *Xueqing Shan*

 Vanderbilt University, '16


 On Wed, Apr 24, 2013 at 10:16 AM, Rob Oakes lyx-de...@oak-tree.us
 mailto:lyx-de...@oak-tree.us** wrote:

 Hi Xueqing,

 Again, this is a brief reply. I've got a massive deadline looming on
 Monday and I will not have much time to respond until after then.
 Hopefully the notes below will be enough to get you started. If not,
 let
 me know and we can set up a time to visit via Skype/Google Chat.

 A lot of this would be much faster to explain than to write out.

 On Tue, 2013-04-23 at 01:18 -0500, Ashley Shan wrote

   Thank you for all the information and materials. It took me a
 while to
   read all your emails and linked blogs/infos, so please correct me
 if
   I'm being unclear or if I omit anything. Again, thank you for your
   patience and help.

 Glad to hear that they were helpful.


 # Proposal Contents #
  
   Non-linear writing process and the goal of this project
   There are several ways for a writer to write

Re: Customizing Lyx

2013-04-25 Thread Richard Heck 

On 04/25/2013 12:05 PM, Elmar Hinz wrote:

Hello all,

my name is Elmar and I am new to this list.

What I am interested in is customization of LyX for special usecases.
That means

* reducing features to a defined minimum
* setting custom sets of markup
* creating exporters for the new markup to new languages

To give an example, I am thinking to redesign LyX to a Markdown Edtior.
Lets call the product MarkdownLyx. The markup of markdown is rather 
minimal.

So I am thinking of a reduced interface to match this minimalism.

Now my questions are:

1.) Are the sources and configurations of LyX modularized in a way,
that I could reach this goal as a one-man-show?


Reducing the interface is pretty trivial, in a sense, since all the menu 
defintions are simply kept in text files. These can be found, in a 
typical installation, at /usr/share/lyx/ui/. All you would need to do is 
write new menu definitions. The same goes for toolbars, etc. Since what 
menu set one uses can be chosen from within LyX, you do not really need 
a separate application.


Exporting the markup syntax is a different issue. I can think of a 
couple ways to do it. The first, and most involved, would be to write 
export routines, in the LyX source itself, similar to the LyXHTML export 
routines. Another would be to write some kind of simple converter that 
would convert some format LyX already exports (perhaps the plaintext 
format?) to Markdown.



2.) Are there already projectes like this?


Not so far as I know.

3.) Is there a documentation that describes the customization process 
of LyX?


This depends what you mean. But see the Customization manual, under the 
Help menu.


4.) Where do you suggest to host such a project, as branch of the LyX 
repository or external?


The kind of thing you are describing would be welcome in the LyX 
sources, I believe. As I said, you don't really need a separate 
application, unless you really want one. Presumably, you'd want to 
benefit from other bug-fixing work that gets done.


Richard

Re: [PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Vincent van Ravesteijn 

Op 25-4-2013 12:21, Hugo Hinterberger schreef:

On Thu, 25 Apr 2013 09:59:04 +, Hugo Hinterberger wrote:


IMHO one issue needs to be fixed in the repository.
I attached (tried to - first post with Pan) a patch file that resolves
the issue for me.

Since I do not see the patch attached I put it in the message body:

= CPack-NSIS.patch =
  


Hi Hugo,

The CPACK stuff is highly experimental (at least on Windows it is). 
Although your patch is indeed correct, the generated NSIS installer 
doesn't do me much good.


I can't find why you would need regex2.dll .. I don't have it and I 
don't need it. Where did you see that this was a problem.


Vincent

Re: \centerline{} support for wide graphics and tables

2013-04-25 Thread Vincent van Ravesteijn 

Op 19-3-2013 4:35, Scott Kostyshak schreef:

When inserting a graphic or table whose width is larger than
\textwidth, the extra width spills over to the right margin. This
might be desired in some cases, but in other cases it is nice to
center the graphic or table on the page. Using \centerline{}, the
extra width is split evenly across the left and right margins.

The following .lyx file shows a couple of ways to address this:
http://paste.debian.net/242737/. One way is to sandwich the table or
graphic between '\centerline{' and '}' ERT boxes. Another way is to
use the adjustbox package. I'm not sure if there are advantages to one
over the other, but since \centerline does not require another
package, I propose to use it over the adjustbox package.

I would like to implement support for it in the tabular settings and
graphics settings as a check box.

The option could be labelled one of the following:

(1) center across both margins
(2) center on page across both margins
(3) center a wide table / center a wide graphic



It should be clear that this option is only used when the image is too 
wide.


If you want to implement this, you need to detect when an image is too 
wide.. How do you plan to dot that ?


Vincent

Re: Customizing Lyx

2013-04-25 Thread Guenter Milde 
On 2013-04-25, Richard Heck wrote:
 On 04/25/2013 12:05 PM, Elmar Hinz wrote:

 What I am interested in is customization of LyX for special usecases.
 That means

 * reducing features to a defined minimum
 * setting custom sets of markup
 * creating exporters for the new markup to new languages

 To give an example, I am thinking to redesign LyX to a Markdown Edtior.
 Lets call the product MarkdownLyx. The markup of markdown is rather 
 minimal.
 So I am thinking of a reduced interface to match this minimalism.

 2.) Are there already projectes like this?

 Not so far as I know.

This project seems related to the idea to use LyX as reStructuredText
frontend also proposed as GSoC project. There is potential for a lot of
synergy between these two.


Günter

Re: Changing sizes of GuiTabular combo boxes

2013-04-25 Thread Vincent van Ravesteijn 

Op 19-3-2013 8:43, Scott Kostyshak schreef:

Make a table and go to the tabular settings. Toggle multicolumn or
multirow and you'll see the combo boxes and the text box changing
width because At Decimal Separator is no longer an option. This did
not happen before. I think commit 6f157533 triggered this.

I could not figure out how to prevent this behavior. Changing the
horizontal policy did not seem to lead to a fix. If I set
hAlignCO-setMinimumWidth() manually with a hard coded size then it
works, but this is not a real solution.

Any ideas?

Thanks,

Scott

I fixed this at 262f58d.

Vincent

Re: textsubscript and textsuperscript bug?

2013-04-25 Thread Vincent van Ravesteijn 

Op 27-3-2013 16:00, Richard Heck schreef:

On 03/26/2013 08:41 PM, Scott Kostyshak wrote:
On Mon, Feb 4, 2013 at 7:47 AM, Csikos Bela bcsikos...@freemail.hu 
wrote:

Hello:

I guess this is a bug in lyx 2.0.5:
When a subscript (\textsubscript) or superscript (\textsuperscript) 
character is inserted in a text that has different font size than 
default, the size of the sub- or superscript character is incorrect 
in the output; it has the same size as text. This occurs if the sub- 
or superscript character is inserted in a text (that has different 
font size than default) afterwards. If the text including the sub- 
or superscript character is written in normal size and the font size 
is changed subsequently (by selecting text including the sub- or 
superscript character and changing size), the sizes are correct.

See the attached lyx example and the corresponding pdf output.

Hi bcsikos,

Was this addressed? I don't know enough to know if this is a bug. If
no one else chimes in, please post a ticket on
http://www.lyx.org/trac/

Also note that emails regarding bug reports should be sent to the
developers list.


This got reported as #8610. The problem is that we are generating some 
default CSS for this inset, and we are doing that because the font is 
set by default, in the InsetLayout constructor, to sane_font, which 
specifies values for everything. If I add

Font
EndFont
to the Script:superscript InsetLayout declaration, then things work 
fine, since this sets effectively sets the font to inherit_font.


That seems like the right thing to me: that, by default, an 
InsetLayout should get an empty font that does not do anything, not 
a fully specified font that resets everything. Yes?


I.e., I am proposing:

diff --git a/src/insets/InsetLayout.cpp b/src/insets/InsetLayout.cpp
index 7729485..aa35f50 100644
--- a/src/insets/InsetLayout.cpp
+++ b/src/insets/InsetLayout.cpp
@@ -34,7 +34,7 @@ namespace lyx {
 InsetLayout::InsetLayout() :
 name_(from_ascii(undefined)), lyxtype_(STANDARD),
 labelstring_(from_ascii(UNDEFINED)), contentaslabel_(false),
-decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(sane_font),
+decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(inherit_font),
 labelfont_(sane_font), bgcolor_(Color_error),
 htmlforcecss_ (false), htmlisblock_(true),
 multipar_(true), custompars_(true), forceplain_(false),

Richard



I didn't look at whether the change is good, but I am wondering whether 
you just did not commit it, or whether you've retracted your proposal ?


Vincent

Re: [PATCH] (Incomplete) Nonexistent debug flag now throws an error

2013-04-25 Thread Vincent van Ravesteijn 

Op 1-4-2013 6:07, Scott Kostyshak schreef:

On Sat, Mar 30, 2013 at 10:02 AM, Vincent van Ravesteijn v...@lyx.org wrote:

Op 30-3-2013 6:08, Scott Kostyshak schreef:


The following command now throws an error:

lyx -dbg doesNotExist

NOTE: THIS PATCH IS INCOMPLETE. I think I have the right condition
for detecting the error, but I don't know what to do with it.

I see two ways of throwing an error:
(1) create a new enum value for Type, THROWERROR, which
LyX.cpp::parse_dbg() would test for on return and, if true,
it would handle the error message and exit

(2) from LyX.cpp::parse_dbg(), test lowercase(arg) to make sure it is not
NONE (or 0).
Then, if that is true and if debug.cpp::value(arg) returns NONE, throw
the error.

None of the two seems elegant to me so I'm guessing there is a better
way. Any ideas?


You can make a function

bool Debug::isKnownValue(string const  val)

Then in LyX.cpp::parse_dbg:

if (Debug::isKnownValue(arg)) {
 ..
} else {
 docstring const error_message =

 bformat(_(The following debug flag does not exist:\n %1$s\n
 Please see 'lyx -dbg' for a list of valid debug flags.),
 from_utf8(tmp));
 lyxerr  to_utf8(error_message)  endl;
 exit(0);
}

Vincent

I think this is something I need to get used to: I would not have
thought that this duplication of code (e.g. reparsing the string in
the same way) was a good solution but I do see this a lot in C++ so
it's something I need learn.


What do you mean ?

Vincent

Re: textsubscript and textsuperscript bug?

2013-04-25 Thread Richard Heck 

On 04/25/2013 04:45 PM, Vincent van Ravesteijn wrote:

Op 27-3-2013 16:00, Richard Heck schreef:

On 03/26/2013 08:41 PM, Scott Kostyshak wrote:
On Mon, Feb 4, 2013 at 7:47 AM, Csikos Bela bcsikos...@freemail.hu 
wrote:

Hello:

I guess this is a bug in lyx 2.0.5:
When a subscript (\textsubscript) or superscript (\textsuperscript) 
character is inserted in a text that has different font size than 
default, the size of the sub- or superscript character is incorrect 
in the output; it has the same size as text. This occurs if the 
sub- or superscript character is inserted in a text (that has 
different font size than default) afterwards. If the text including 
the sub- or superscript character is written in normal size and the 
font size is changed subsequently (by selecting text including the 
sub- or superscript character and changing size), the sizes are 
correct.

See the attached lyx example and the corresponding pdf output.

Hi bcsikos,

Was this addressed? I don't know enough to know if this is a bug. If
no one else chimes in, please post a ticket on
http://www.lyx.org/trac/

Also note that emails regarding bug reports should be sent to the
developers list.


This got reported as #8610. The problem is that we are generating 
some default CSS for this inset, and we are doing that because the 
font is set by default, in the InsetLayout constructor, to sane_font, 
which specifies values for everything. If I add

Font
EndFont
to the Script:superscript InsetLayout declaration, then things work 
fine, since this sets effectively sets the font to inherit_font.


That seems like the right thing to me: that, by default, an 
InsetLayout should get an empty font that does not do anything, not 
a fully specified font that resets everything. Yes?


I.e., I am proposing:

diff --git a/src/insets/InsetLayout.cpp b/src/insets/InsetLayout.cpp
index 7729485..aa35f50 100644
--- a/src/insets/InsetLayout.cpp
+++ b/src/insets/InsetLayout.cpp
@@ -34,7 +34,7 @@ namespace lyx {
 InsetLayout::InsetLayout() :
 name_(from_ascii(undefined)), lyxtype_(STANDARD),
 labelstring_(from_ascii(UNDEFINED)), contentaslabel_(false),
-decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(sane_font),
+decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(inherit_font),
 labelfont_(sane_font), bgcolor_(Color_error),
 htmlforcecss_ (false), htmlisblock_(true),
 multipar_(true), custompars_(true), forceplain_(false),

Richard



I didn't look at whether the change is good, but I am wondering 
whether you just did not commit it, or whether you've retracted your 
proposal ?


No, no one replied, and I wasn't sure what was best. But it would really 
surprise me if it caused some problem. I.e., I would regard THAT as a bug.


I'll go ahead and commit to trunk.

rh

Re: [PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Hugo Hinterberger 

Vincent van Ravesteijn  wrote in message news:51797f11@lyx.org...


The CPACK stuff is highly experimental (at least on Windows it is).


I know, I just wanted to be able to see any new developments by including it 
in my build.


Although your patch is indeed correct, the generated NSIS installer 
doesn't do me much good.


Same here.

I can't find why you would need regex2.dll .. I don't have it and I don't 
need it. Where did you see that this was a problem.


I could not find any reference in the source files either, but the 
executable generated by my build environment (see below and feel free to ask 
for more details) will not run without it and it tells me so by referencing 
the DLL by name.


Since I am using a development build I am trying to keep a current build at 
hand in case I find an issue with the build I am using in production.


Currently I am having some problems with my build:
1 ) CMake-GUI will not complete successfully -- I just noticed that you made 
some changes to development/cmake/modules/FindQt4.cmake , I will try to 
build it again tomorrow.
2 ) Qt Creator was able to successfully run CMake without your fix but 
failed at some other point during compiling.


btw, does anybody know about any nightly builds of LyX for Windows? Are 
there any free Windows build servers for OSS publicly available?


Kind regards,
Hugo


Some information about my build environment:
Windows 7 x64
CMake 2.8.10
Visual C++ Express 2010
Qt 4.8.4 [1] / Qt 5.0.2 + Qt Creator


[1] 
http://download.qt-project.org/official_releases/qt/4.8/4.8.4/qt-win-opensource-4.8.4-vs2010.exe

Re: Introduction

2013-04-25 Thread Cyrille Artho 

Dear Pulkit,
Thank you for your interest in the LyX community. Many projects have 
already been discussed extensively in the last two weeks. Please take a 
look at the mailing list archive:


http://www.mail-archive.com/lyx-devel@lists.lyx.org/

However, I am not sure if the LyX presentation mode has been brought up 
yet. The basic problem there is that LyX is designed to edit text, not 
presentations. So there are a number of things that would make editing 
presentations more intuitive; in particular, a preview of the given 
slide/page within LyX would be very nice.


pulkit jain wrote:

Hi all,

My name is Pulkit Jain and I am a fourth year undergraduate at the Indian
Institute of Technology Kharagpur enrolled in the course of Mathematics and
Computing. I wish to participate in Google Summer of code, 2013. Browsing
through the list of organisations, I came across LyX GSoC'13 page. I
visited the Ideas page and *LyX Presentaiton Mode *and*Toolbar
customization dialog* projects caught my interest.

I have significant programming experience and have been coding for the past
6 years. I have had courses in Algorithms, Database Management Systems,
  Switching and Finite Automata Theory, Object Oriented Systems, System
Programming, Compiler Design, Operating Systems, Computer Software, etc. I
have also done a research project related to improvement of methods used
for Credit Card Fraud Detection using Genetic Algorithm and Hidden Markow
Models and another project related to optimization of data transfer in
networks. I have substantial skill in C, *C++*, Java, Python. I am ready to
learn anything which will be required to complete the project.

I hope that my background is good enough. I am highly keen to participate
in GSoc'13 in your organisation. I shall be grateful if anyone can point to
me where should I start in order to make a good proposal for the above
mentioned ideas.

Sorry for this late introduction, as I was busy with my college examinations.
Thanking You,

Yours sincerely,
Pulkit


--
Regards,
Cyrille Artho - http://artho.com/
There's nothing wrong with you that reincarnation won't cure.
-- Jack E. Leonard

Re: Customizing Lyx

2013-04-25 Thread Elmar Hinz 
 Exporting the markup syntax is a different issue. I can think of a couple
 ways to do it. The first, and most involved, would be to write export
 routines, in the LyX source itself, similar to the LyXHTML export routines.
 Another would be to write some kind of simple converter that would convert
 some format LyX already exports (perhaps the plaintext format?) to Markdown.


Hello Richard,

if I would like to transform LyXHTML to Markdown, I would need an XSL
library or at least an XML parser.
Is there already something like this contained in the sources? If not, what
is your suggestion to use?

Regards

Elmar

-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: [LyX master] Audit all the LASSERT calls, and try to do something sensible at each failure.

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 5:29 PM, Richard Heck rgh...@lyx.org wrote:
 The branch, master, has been updated.

 - Log -

 commit 1b1f8dd235ba8e168348cd23c824063f2595a0c5
 Author: Richard Heck rgh...@lyx.org
 Date:   Thu Apr 25 17:27:10 2013 -0400

 Audit all the LASSERT calls, and try to do something sensible at
 each failure.

 There are several places I was not sure what to do. These are marked
 by comments beginning LASSERT: so they can be found easily. At the
 moment, they are at:

 Author.cpp:105: // LASSERT: What should we do here?
 Author.cpp:121: // LASSERT: What should we do here?
 Buffer.cpp:4525:// LASSERT: Is it safe to continue here, or 
 should we just return?
 Cursor.cpp:345: // LASSERT: Is it safe to continue here, or 
 should we return?
 Cursor.cpp:403: // LASSERT: Is it safe to continue here, or 
 should we return?
 Cursor.cpp:1143:// LASSERT: There have been several bugs 
 around this code, that seem
 CursorSlice.cpp:83: // LASSERT: This should only ever be called from 
 an InsetMath.
 CursorSlice.cpp:92: // LASSERT: This should only ever be called from 
 an InsetMath.
 LayoutFile.cpp:303: // LASSERT: Why would this fail?
 Text.cpp:995:   // LASSERT: Is it safe to continue here?

I'm getting an assertion now whenever I try to insert a table or
graphics or float:
ASSERTION false VIOLATED IN
/home/scott/lyxbuilds/master/build/src/Paragraph.cpp:1853

Scott

Re: Changing sizes of GuiTabular combo boxes

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 4:38 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Op 19-3-2013 8:43, Scott Kostyshak schreef:

 Make a table and go to the tabular settings. Toggle multicolumn or
 multirow and you'll see the combo boxes and the text box changing
 width because At Decimal Separator is no longer an option. This did
 not happen before. I think commit 6f157533 triggered this.

 I could not figure out how to prevent this behavior. Changing the
 horizontal policy did not seem to lead to a fix. If I set
 hAlignCO-setMinimumWidth() manually with a hard coded size then it
 works, but this is not a real solution.

 Any ideas?

 Thanks,

 Scott

 I fixed this at 262f58d.

Works well. Thanks, Scott

Re: [PATCH] (Incomplete) Nonexistent debug flag now throws an error

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 4:49 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Op 1-4-2013 6:07, Scott Kostyshak schreef:
 I think this is something I need to get used to: I would not have
 thought that this duplication of code (e.g. reparsing the string in
 the same way) was a good solution but I do see this a lot in C++ so
 it's something I need learn.


 What do you mean ?

Checking whether a debug flag is valid and then setting that debug
flag both involve looping through all the debug flags. When initially
looking at this, the most natural thing seemed to me that there should
be only one loop. But I think this separation of validation and
processing is common in C++ and that I should learn to not worry about
looping twice instead of once. Especially for such a small vector,
this does not have any real performance issue.

Besides performance though it still seems to me that the code could be
more simple if there were just one loop. Is there a reason why it
would be bad in this case to have one loop and throw an exception if a
debug flag does not exist? Would it be reasonable to do a try/catch
around lyxerr.setLevel(Debug::value(arg)) and obviate the need for
Debug::isKnownValue(tmp) ?

Scott

Re: \centerline{} support for wide graphics and tables

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 3:33 PM, Vincent van Ravesteijn v...@lyx.org wrote:
 Op 19-3-2013 4:35, Scott Kostyshak schreef:

 When inserting a graphic or table whose width is larger than
 \textwidth, the extra width spills over to the right margin. This
 might be desired in some cases, but in other cases it is nice to
 center the graphic or table on the page. Using \centerline{}, the
 extra width is split evenly across the left and right margins.

 The following .lyx file shows a couple of ways to address this:
 http://paste.debian.net/242737/. One way is to sandwich the table or
 graphic between '\centerline{' and '}' ERT boxes. Another way is to
 use the adjustbox package. I'm not sure if there are advantages to one
 over the other, but since \centerline does not require another
 package, I propose to use it over the adjustbox package.

 I would like to implement support for it in the tabular settings and
 graphics settings as a check box.

 The option could be labelled one of the following:

 (1) center across both margins
 (2) center on page across both margins
 (3) center a wide table / center a wide graphic


 It should be clear that this option is only used when the image is too wide.

 If you want to implement this, you need to detect when an image is too
 wide.. How do you plan to dot that ?

I was not planning on doing that. I was thinking that in many cases
the user knows when it is too large and would manually set this
option. There has been some very preliminary discussion (in the email
thread on the GSoC horizontal scrollbar project) of parsing the log
for specific overfull hboxes; but I do not think it makes sense to
automatically detect this and set \centerline without the user
knowing.

Scott

Re: Interested in GSOC Project:

2013-04-25 Thread Hashini Senaratne 
Jean-Marc Lasgouttes lasgouttes at lyx.org writes:
 To be frank, I do not know. Sometimes (I will write about it in another 
 thread to vary a bit) I think that an horizontal scrollbar for the whole 
 workarea would actually be enough (but anyway the effect should be 
 obtained through changes to TextMetrics.cpp as I described).
 
 Note that a table only requires one Row as I understand it. Therefore 
 the whole table would move as a simple object. OTOH in a paragraph, only 
 one line of the paragraph would move. Of course some UI would be needed 
 to make this understandable.

I like to experiment on this in the coming week. Thank you for your guidance.

As the student application term is running on, I drafted my application and 
submitted it already. I am thankful to you and Scott (or may be any potential 
developer) if can review my application and give me some feedback to improve.

Thank you
Hashini

Re: Fwd: GSOC: reStructuredText support for LyX?

2013-04-25 Thread Guenter Milde 
On 2013-04-24, Nico Williams wrote:
> On Wed, Apr 24, 2013 at 4:40 PM, Guenter Milde  wrote:

>> This means it might be easier to use XML as intermediate format: Docutils
>> can generate a native XML representation of a reStructuredText document and
>> also re-generate a document tree from this representation.
>> There are attempts to have a "native LyX XML" format (either replacing the
>> current fileformat or as an alternative representation), so XSLT
>> transformations may help to transform between these two.

> LyX -> XML converter:

> https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml
> https://github.com/nicowilliams/lyx2rfc/blob/master/src/lyx2xml.py
> https://github.com/nicowilliams/lyx2rfc/blob/master/src/xml_streamer.py

> After that apply an XSL to change schemas.

Yes, this was my idea. 

However, going the XML/XSL way we still need to handle the
incompatibilities between the document models.

I don't know XSL, so my contributions to such a project would be limited to
answering questions about Docutils/reStructuredText and testing.

If you are interested, there is reference material in
http://docutils.sourceforge.net/docs/ref/ including the
Docutils Generic DTD http://docutils.sourceforge.net/docs/ref/docutils.dtd
and an (incomplete) description of the document model
http://docutils.sourceforge.net/docs/ref/doctree.html

Thanks, 

Günter

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

2013-04-25 Thread Jean-Marc Lasgouttes 

24/04/2013 21:41, pdv:

Why do you add 0x61 to the values?


That's just for easy reading when looking at what exactly gets written
to the map; In this way the codes are a, b, c ...


That makes sense.


I do not think there is a need to have a map per document. A shared map
stored in TextLetrics should be OK (like singleWidth currently).


I was worried that the map might grow out of proportion, e.g. when
leaving the application open for a long time and since there are more
words than characters this will be worse than for singleWidth.


I would start with the simple solution and then worry about a more 
complicated one. A shared map will take less total memory. If acces time 
is bad, then it may be worth implementing qHash(docstring) (by aping the 
QString version) and use a QHash.



When typing it's unavoidable to generate all partials of a word; these
are removed again from the map so that only the final word remains;
However nothing is done to remedy the reverse: when deleting a word
character by character all partials will end-up in the map;


Did you do some measurement to ensure that there is a gain of doing that?


I don't think it makes so much difference in time. It was merely to
avoid filling the map with useless entries, especially if a single map
is used.


My policy in these kind of situation is to implement the simple solution 
and do optimization only when some measurement (profiling) proved that 
there is a problem to solve. Remember Knuth quote: "Premature 
optimization is the root of all evil (or at least most of it) in 
programming."


Do not hesitate to post patches as often as needed. While I do not have 
time to look at the hard parts of the patch right now, I think we move 
in the right direction.


JMarc

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

2013-04-25 Thread Jean-Marc Lasgouttes 

24/04/2013 21:14, pdv:

Sorry, the problem is obvious.
I'm using cmake and although --enable-stdlib-debug is mentioned in the
install notes, I can't set that option.
Once (more or less) ready I build manually with the
LyX-Mac-binary-release.sh script, which by default disables this option.
When I enable it, lyx crashes right away when starting. Don't know yet
whether this signals other problems or if there is a problem with this
option.


Actually the stdlib-debug option does not work on OS X (it may depend on 
gcc and boost versions, I do not know). But I can use it on linux and 
tell you what I find :)


JMarc

Re: [LyX master] Hungarian Tutorial.lyx: revert last change

2013-04-25 Thread Scott Kostyshak 
On Mon, Apr 22, 2013 at 3:58 PM, Scott Kostyshak  wrote:
> On Sun, Apr 21, 2013 at 3:32 PM, Uwe Stöhr  wrote:
>> Am 20.04.2013 07:51, schrieb Scott Kostyshak:
>>> To make sure, you are asking me to backport all of the recent changes
>>> I've made to the manuals and example files in trunk?
>>
>> I mean the changes where you encountered export problems and therefore set
>> the default output format to pdf2.
>
> Ah, I'm glad I asked. OK I will look through the commits and
> cherry-pick the ones that set the default output format. I don't think
> it's always to pdf2. IIRC, some required format pdf.

Done starting at edd91d5e.

Scott

[PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Hugo Hinterberger 
Hallo,

I am using a development build in order to have SVN 1.7 support and I 
noticed some issues with the build environment on Windows.

IMHO one issue needs to be fixed in the repository.
I attached (tried to - first post with Pan) a patch file that resolves 
the issue for me.

The other issue I noticed is that the "regex2.dll" library and possibly 
other files are missing from the "msvc2010-deps" package.

Kind regards,
Hugo

Re: Beamer goto buttons and text hyperlinks

2013-04-25 Thread Scott Kostyshak 
On Tue, Apr 23, 2013 at 11:32 AM, Jean-Marc Lasgouttes
 wrote:
> Le 20/04/2013 09:06, Jürgen Spitzmüller a écrit :
>
>> Scott Kostyshak wrote:
>>>
>>> Do you think it's better to add \hyperlink support to the label inset
>>> or to make a separate, collapsable hypertarget inset? \hypertarget
>>> takes two arguments: the name and the text. The name could be set in
>>> the settings, and the text in the collapsable inset.
>>
>>
>> I'd prefer not to add too many different insets for similar functions. But
>> the
>> collapsable solution adds some convenience.
>
>
> We could maybe have an inset that is only a button when no extra text is
> needed and a collapsablme inset otherwise. Somethin in between InsetCommand
> and InsetCollapsable.

I find this very interesting. If I understand correctly, it would work
like this:

When I go to insert > label, it inserts a button and everything works
exactly as it does now, except that if I click on the "hypertarget"
checkbox in the label settings dialog, the button is now a collapsable
inset. And if there is a selection, insert > label can default to
having the hypertarget checkbox checked and having that text put in
the collapsable box. The current behavior when there is text selected
is for the text to be deleted.

Would we also want to do this for the cross ref inset? It could work
in a similar way: there is a checkbox for "hyperlink". If checked, the
inset becomes a collapsable inset. Note that in this case more is done
if hyperlinkCB is checked: the hypertargets would be shown along with
the labels, either in the same tree widget (perhaps we could give the
hypertargets a prefix so that when grouped it's easy to navigate) or
there could be a split tree widget, more clearly separating labels
from hypertargets.

Jürgen, do you still prefer to have the cross ref code copied over to
the hyperref inset? My hesitation is that there would be a lot of
duplicate code. Also, I think that the text hyperlinks have more in
common with references than they do with hrefs to web, emails, and
files. However, I think your argument is that overloading the cross
ref dialog would make the user experience more complicated and there
would be a larger chance of a regression for this important part of
the code. This makes sense to me also.

Scott

Re: [PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Hugo Hinterberger 
On Thu, 25 Apr 2013 09:59:04 +, Hugo Hinterberger wrote:

> IMHO one issue needs to be fixed in the repository.
> I attached (tried to - first post with Pan) a patch file that resolves
> the issue for me.

Since I do not see the patch attached I put it in the message body:

= CPack-NSIS.patch =>
 development/cmake/LyxPackaging.cmake | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/development/cmake/LyxPackaging.cmake b/development/cmake/
LyxPackaging.cmake
index 4f9091b..1788b0a 100644
--- a/development/cmake/LyxPackaging.cmake
+++ b/development/cmake/LyxPackaging.cmake
@@ -32,9 +32,13 @@ FILE(STRINGS "${TOP_CMAKE_PATH}/LyX_summary.txt" 
CPACK_PACKAGE_DESCRIPTION_SUMMA
 
 set(CPACK_PACKAGE_INSTALL_DIRECTORY "CMake ${LYX_INSTALL_SUFFIX}")
 
-#
-# needed by rpm
-set(CPACK_SET_DESTDIR "ON")
+if(WIN32)
+   # does not work on Windows, and NSIS
+   set(CPACK_SET_DESTDIR "OFF")
+else()
+# needed by rpm
+   set(CPACK_SET_DESTDIR "ON")
+endif()
 FILE(READ "${TOP_CMAKE_PATH}/LyX_license.txt" CPACK_RPM_PACKAGE_LICENSE)
 set(CPACK_RPM_PACKAGE_GROUP "Applications/Publishing")
 set(CPACK_RPM_PACKAGE_VENDOR "The LyX team")
<= CPack-NSIS.patch =

Re: ps2pdf13 -> ps2pdf14 ?

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 11, 2013 at 5:20 AM, Jean-Marc Lasgouttes
 wrote:
> 08/04/2013 08:04, Jürgen Spitzmüller:
>
>> Scott Kostyshak wrote:
>>>
>>> I don't have any particular reason for changing it and the safe thing
>>> would be to leave it alone, but I'm curious what others think.
>>
>>
>> My vote would be to use plain "ps2pdf" without any format binding.
>
>
> +1

It's in at 959d2c5.

Scott

Re: [PATCH] Spelling: "Postscript" -> "PostScript"

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 11, 2013 at 3:46 AM, Jean-Marc Lasgouttes
 wrote:
> 11/04/2013 04:51, Scott Kostyshak:
>
>>  From what I understand, "PostScript" is the correct way to write it.
>>
>> Does anyone have an opinion on this?
>
>
> Why not. If you go this way, "git grep" tells me that there are other places
> needing attention.

Is the attached patch OK? I did not make the change in the translated
manuals. Should I? I don't know how the translation process works for
the manuals.

Scott
From d31db4ee94d433a9a57fe58e79a13a6f4e06ddb3 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak 
Date: Wed, 10 Apr 2013 22:47:44 -0400
Subject: [PATCH] Spelling: "Postscript" -> "PostScript"

---
 lib/configure.py  |6 +++---
 lib/doc/EmbeddedObjects.lyx   |2 +-
 lib/doc/LaTeXConfig.lyx   |2 +-
 lib/doc/UserGuide.lyx |6 +++---
 lib/examples/CV-image.eps |2 +-
 lib/examples/ItemizeBullets.lyx   |4 ++--
 lib/examples/ca/ItemizeBullets.lyx|2 +-
 lib/examples/es/ItemizeBullets.lyx|2 +-
 lib/examples/fr/ListesPuces.lyx   |2 +-
 lib/examples/instant_preview.lyx  |4 ++--
 lib/examples/powerdot-example.lyx |4 ++--
 lib/examples/seminar.lyx  |4 ++--
 lib/scripts/lyxpreview2bitmap.py  |4 ++--
 lyx.1in   |2 +-
 src/Length.h  |2 +-
 src/LyXAction.cpp |4 ++--
 src/frontends/qt4/GuiDocument.cpp |2 +-
 src/frontends/qt4/ui/PrefPrinterUi.ui |2 +-
 src/graphics/GraphicsParams.cpp   |4 ++--
 src/graphics/epstools.cpp |2 +-
 src/insets/InsetGraphics.cpp  |4 ++--
 src/tex2lyx/test/foo.eps  |2 +-
 22 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/lib/configure.py b/lib/configure.py
index 946d8f7..3dbfc38 100644
--- a/lib/configure.py
+++ b/lib/configure.py
@@ -572,12 +572,12 @@ def checkFormatEntries(dtl_tools):
 'nedit', 'gedit', 'notepad', 'geany', 'leafpad', 'mousepad'],
 rc_entry = [r'''\Format bibtex bib"BibTeX" "" ""   "%%"
""  "text/x-bibtex"''' ])
 #
-#checkProg('a Postscript interpreter', ['gs'],
+#checkProg('a PostScript interpreter', ['gs'],
 #  rc_entry = [ r'\ps_command "%%"' ])
-checkViewer('a Postscript previewer', ['kghostview', 'okular', 'evince', 
'gv', 'ghostview -swap'],
+checkViewer('a PostScript previewer', ['kghostview', 'okular', 'evince', 
'gv', 'ghostview -swap'],
 rc_entry = [r'''\Format epseps EPS"" 
"%%"  ""  "vector""image/x-eps"
 \Format eps2   eps"EPS (uncropped)"   "" "%%"  ""  
"vector"""
-\Format ps ps  Postscript t  "%%"  ""  
"document,vector,menu=export"   "application/postscript"'''])
+\Format ps ps  PostScript t  "%%"  ""  
"document,vector,menu=export"   "application/postscript"'''])
 # for xdg-open issues look here: 
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg151818.html
 # the MIME type is set for pdf6, because that one needs to be 
autodetectable by libmime
 checkViewer('a PDF previewer', ['pdfview', 'kpdf', 'okular', 'evince', 
'kghostview', 'xpdf', 'acrobat', 'acroread', 'mupdf', \
diff --git a/lib/doc/EmbeddedObjects.lyx b/lib/doc/EmbeddedObjects.lyx
index 4dc2aa5..60ff0d3 100644
--- a/lib/doc/EmbeddedObjects.lyx
+++ b/lib/doc/EmbeddedObjects.lyx
@@ -41056,7 +41056,7 @@ You can export your document to PostScript using the 
menu
 \family sans
 File\SpecialChar \menuseparator
 Export\SpecialChar \menuseparator
-Postscript
+PostScript
 \family default
 .
  You can view your document as PostScript via the 
diff --git a/lib/doc/LaTeXConfig.lyx b/lib/doc/LaTeXConfig.lyx
index 53a123b..5a69841 100644
--- a/lib/doc/LaTeXConfig.lyx
+++ b/lib/doc/LaTeXConfig.lyx
@@ -6373,7 +6373,7 @@ Notes:
 dvipost
 \family default
  is a post-processor for DVI files created by LaTeX and TeX.
- It is needed by LyX to generate DVI or Postscript output of change tracking
+ It is needed by LyX to generate DVI or PostScript output of change tracking
  marks.
  To work properly, 
 \family sans
diff --git a/lib/doc/UserGuide.lyx b/lib/doc/UserGuide.lyx
index 5caf0b1..75f7544 100644
--- a/lib/doc/UserGuide.lyx
+++ b/lib/doc/UserGuide.lyx
@@ -38667,7 +38667,7 @@ text
 
 (ps2ascii)
 \family default
- text format, the document will first be converted to Postscript format
+ text format, the document will first be converted to PostScript format
  and then exported as text using the program 
 \family sans
 ps2ascii
@@ -38676,7 +38676,7 @@ ps2ascii
 \begin_layout Description
 
 \family sans
-Postscript
+PostScript
 \family default
  PostScript format using the program 
 \family typewriter
@@ -38720,7 +38720,7 @@ PDF
 \family default
  or 
 \family sans
-Postscript

Re: Translations for 2.0.6

2013-04-25 Thread Richard Heck 

On 04/24/2013 02:19 PM, Pavel Sanda wrote:

Richard Heck wrote:

I thought I had done that right before. Should I remerge and send another
note?

I din't check extensively but I belive this will be concern to 2-3 people only.
git log -p po/ vs current status after remerge should give a clue.


I have a script that does this. It looks like maybe the commit failed. 
It was still sitting on my work machine yesterday.


rh

Re: Signals/Slots in Core (branch from UI improvements and non-linear enhancements)

2013-04-25 Thread Richard Heck 

On 04/22/2013 09:19 AM, Rob Oakes wrote:

Dear Developers,

If I remember correctly, as of the last developer meeting, QtCore
classes were being tolerated in the core of LyX.
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg172533.html

Is this correct? Are there any examples of QtCore and Signals/Slots
being integrated into the core of LyX?

I've been corresponding with one of the GSOC students about using the
outline enhancements for a GSOC project, and it seems that moving
certain text insets to use QObject (or related) as their base class
might be an interesting goal. This would allow for insets to make use of
the signal/slot mechanism for communicating updates to the view.

In the case of the outline view and underlying TOC model, it wouldn't be
necessary to scan for changes, and would provide a nice speed boost to
the editing experience.

Would such a project be too ambitious?


There are other signal-slot mechanisms that could be used, I believe. 
Boost signals are used in the core already. I'm not sure exactly what 
the idea is here, though, so I'm not sure if that helps or not.


A larger question concerns whether this threatens to subvert the 
dispatch mechanism.


Richard

Re: Signals/Slots in Core (branch from UI improvements and non-linear enhancements)

2013-04-25 Thread Jean-Marc Lasgouttes 

I've been corresponding with one of the GSOC students about using the
outline enhancements for a GSOC project, and it seems that moving
certain text insets to use QObject (or related) as their base class
might be an interesting goal. This would allow for insets to make use of
the signal/slot mechanism for communicating updates to the view.

In the case of the outline view and underlying TOC model, it wouldn't be
necessary to scan for changes, and would provide a nice speed boost to
the editing experience.


Is scanning for changes so expensive? It seems to be that our 
updateBuffer mechanism is quite fast in practice. What is the use case?


What is the exact effect that is expected?

I agree with Richard that adding a way to avoid the dispatch mechanism 
just because that seems nice is not a good idea right now. We could move 
towards this indeed, but it should be done in all the core. Currently 
there are a lot of small things that happen in the dispatch mechanism to 
make things just work. Remember that the last 5% of the functionality is 
the most difficult to obtain :)


JMarc

Re: GSoC idea: UI improvements and non-linear writing enhancements (Technical)

2013-04-25 Thread Ashley Shan 
Hi Cyrille,

Thank you for your reply. I calculated my work time, and if I'm to work
full time for 12 weeks, then I will devote a total of 480 hours on the
project; according to my calculation, if I work full time for 9 weeks (40
hours a week) or more than 40 hours a week (50 hours a week, say), then I
still need 30 - 120 hours to finish in the 6 weeks of my summer school. I
think if I work part time during my summer school, I will be fine.

Since my school is on semester and our summer break begins from May 3, I
plan to begin my coding on May 5 and finish it by Aug 20. It's roughly 15
weeks, including 2 buffer weeks.

I will come up with a modified schedule after the first few weeks when I
get a better sense of the project, and another modified schedule after the
midterm evaluation, which I put in the 7th week.

Xueqing Shan

*Xueqing Shan*
Vanderbilt University, '16


On Wed, Apr 24, 2013 at 11:56 PM, Cyrille Artho  wrote:

> Hi Xueqing Shan,
> If it is possible for you to start coding a bit earlier than the official
> start, that would be very helpful. I appreciate your commitment of working
> almost 60 hours a week, but this may cause you to "burn out" in the middle
> of the project, so an alternative schedule would be preferable.
>
> It is OK if you cannot work for the entire 13 weeks that is assumed in the
> normal schedule, if you have courses or exams. Just plan your project
> accordingly; if you can work for the equivalent of 11 - 12 weeks full time,
> with a good plan and matching milestones, this is better than going
> "overdrive" to work around summer courses.
>
> Ashley Shan wrote:
>
>> Hi Rob,
>>
>> Thank you for replying in such a busy schedule. Your emails are always
>> helpful in clarification. I am working on my proposal and hopefully I can
>> have a pretty much complete draft by the end of this week. I plan to
>> submit
>> and make further changes based on feedback I got if any.
>>
>> *Regarding time commitment*
>>
>> I have indicated this point in my proposal that I will have summer courses
>> for 6 weeks, hence I sort of structured my schedule for the project
>> accordingly. I plan to finish the majority of the work in the first 7
>> weeks, during which I can work as much as 8 hours a day and 7 days a week.
>> Then, when I'm having summer courses, I plan to work part-time, around
>> 15-20 hours a week for 6 weeks. I also put two buffer weeks in the 6 weeks
>> of class. After that, I have another 2 free weeks, which I plan to put the
>> last part of the project there. Hence, there are 15 weeks in total on my
>> proposal.
>>
>> *Regarding setting milestones*
>>
>> Currently I'm buried in finals so I haven't got time to systematically
>> familiarize myself with LyX internals. I searched the web but didn't see
>> any clear route map about where I should get started or at least a good
>> overview for a beginner of LyX so I can plan my project. I have emailed
>> Abdel Younes about LyX internals. I will continue to look for resources.
>> I would appreciate if we can set up a Google Chat some time next week
>> after
>> your deadline. Right now, I can work on other parts first and get help
>> from
>> Abdel and other people in the mailing list.
>>
>> *Regarding proposal details*
>>
>> I have finished my schedule for first week; it has daily milestones. I
>> plan
>> to familiarize myself with LyX development, Qt, and git in the first week
>> (the basics). I plan to work on the second or the second and the third
>> week
>> tomorrow, which would have daily milestones as well if they are devoted to
>> studying the basics. I have two buffer weeks, weekly progress reports,
>> three progress evaluations (including one mid term), and one final
>> evaluation.
>> I realize that I know very little about terminologies, but I'm trying to
>> be
>> as strict as possible regarding term usage.
>>
>> I look forward to hearing from you. Good luck with the project you are
>> working on.
>>
>> Xueqing Shan
>> --**--
>> *Xueqing Shan*
>>
>> Vanderbilt University, '16
>>
>>
>> On Wed, Apr 24, 2013 at 10:16 AM, Rob Oakes > **> wrote:
>>
>> Hi Xueqing,
>>
>> Again, this is a brief reply. I've got a massive deadline looming on
>> Monday and I will not have much time to respond until after then.
>> Hopefully the notes below will be enough to get you started. If not,
>> let
>> me know and we can set up a time to visit via Skype/Google Chat.
>>
>> A lot of this would be much faster to explain than to write out.
>>
>> On Tue, 2013-04-23 at 01:18 -0500, Ashley Shan wrote
>>
>>  > Thank you for all the information and materials. It took me a
>> while to
>>  > read all your emails and linked blogs/infos, so please correct me
>> if
>>  > I'm being unclear or if I omit anything. Again, thank you for your
>>  > patience and help.
>>
>> Glad to

Re: Customizing Lyx

2013-04-25 Thread Richard Heck 

On 04/25/2013 12:05 PM, Elmar Hinz wrote:

Hello all,

my name is Elmar and I am new to this list.

What I am interested in is customization of LyX for special usecases.
That means

* reducing features to a defined minimum
* setting custom sets of markup
* creating exporters for the new markup to new languages

To give an example, I am thinking to redesign LyX to a Markdown Edtior.
Lets call the product MarkdownLyx. The markup of markdown is rather 
minimal.

So I am thinking of a reduced interface to match this minimalism.

Now my questions are:

1.) Are the sources and configurations of LyX modularized in a way,
that I could reach this goal as a one-man-show?


Reducing the interface is pretty trivial, in a sense, since all the menu 
defintions are simply kept in text files. These can be found, in a 
typical installation, at /usr/share/lyx/ui/. All you would need to do is 
write new menu definitions. The same goes for toolbars, etc. Since what 
menu set one uses can be chosen from within LyX, you do not really need 
a separate application.


Exporting the markup syntax is a different issue. I can think of a 
couple ways to do it. The first, and most involved, would be to write 
export routines, in the LyX source itself, similar to the LyXHTML export 
routines. Another would be to write some kind of simple converter that 
would convert some format LyX already exports (perhaps the plaintext 
format?) to Markdown.



2.) Are there already projectes like this?


Not so far as I know.

3.) Is there a documentation that describes the customization process 
of LyX?


This depends what you mean. But see the Customization manual, under the 
Help menu.


4.) Where do you suggest to host such a project, as branch of the LyX 
repository or external?


The kind of thing you are describing would be welcome in the LyX 
sources, I believe. As I said, you don't really need a separate 
application, unless you really want one. Presumably, you'd want to 
benefit from other bug-fixing work that gets done.


Richard

Re: [PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Vincent van Ravesteijn 

Op 25-4-2013 12:21, Hugo Hinterberger schreef:

On Thu, 25 Apr 2013 09:59:04 +, Hugo Hinterberger wrote:


IMHO one issue needs to be fixed in the repository.
I attached (tried to - first post with Pan) a patch file that resolves
the issue for me.

Since I do not see the patch attached I put it in the message body:

= CPack-NSIS.patch =>
  


Hi Hugo,

The CPACK stuff is highly experimental (at least on Windows it is). 
Although your patch is indeed correct, the generated NSIS installer 
doesn't do me much good.


I can't find why you would need regex2.dll .. I don't have it and I 
don't need it. Where did you see that this was a problem.


Vincent

Re: \centerline{} support for wide graphics and tables

2013-04-25 Thread Vincent van Ravesteijn 

Op 19-3-2013 4:35, Scott Kostyshak schreef:

When inserting a graphic or table whose width is larger than
\textwidth, the extra width spills over to the right margin. This
might be desired in some cases, but in other cases it is nice to
center the graphic or table on the page. Using \centerline{}, the
extra width is split evenly across the left and right margins.

The following .lyx file shows a couple of ways to address this:
http://paste.debian.net/242737/. One way is to sandwich the table or
graphic between '\centerline{' and '}' ERT boxes. Another way is to
use the adjustbox package. I'm not sure if there are advantages to one
over the other, but since \centerline does not require another
package, I propose to use it over the adjustbox package.

I would like to implement support for it in the tabular settings and
graphics settings as a check box.

The option could be labelled one of the following:

(1) "center across both margins"
(2) "center on page across both margins"
(3) "center a wide table" / "center a wide graphic"



It should be clear that this option is only used when the image is too 
wide.


If you want to implement this, you need to detect when an image is too 
wide.. How do you plan to dot that ?


Vincent

Re: Customizing Lyx

2013-04-25 Thread Guenter Milde 
On 2013-04-25, Richard Heck wrote:
> On 04/25/2013 12:05 PM, Elmar Hinz wrote:

>> What I am interested in is customization of LyX for special usecases.
>> That means

>> * reducing features to a defined minimum
>> * setting custom sets of markup
>> * creating exporters for the new markup to new languages

>> To give an example, I am thinking to redesign LyX to a Markdown Edtior.
>> Lets call the product MarkdownLyx. The markup of markdown is rather 
>> minimal.
>> So I am thinking of a reduced interface to match this minimalism.

>> 2.) Are there already projectes like this?

> Not so far as I know.

This project seems related to the idea to use LyX as reStructuredText
frontend also proposed as GSoC project. There is potential for a lot of
synergy between these two.


Günter

Re: Changing sizes of GuiTabular combo boxes

2013-04-25 Thread Vincent van Ravesteijn 

Op 19-3-2013 8:43, Scott Kostyshak schreef:

Make a table and go to the tabular settings. Toggle multicolumn or
multirow and you'll see the combo boxes and the text box changing
width because "At Decimal Separator" is no longer an option. This did
not happen before. I think commit 6f157533 triggered this.

I could not figure out how to prevent this behavior. Changing the
horizontal policy did not seem to lead to a fix. If I set
hAlignCO->setMinimumWidth() manually with a hard coded size then it
works, but this is not a real solution.

Any ideas?

Thanks,

Scott

I fixed this at 262f58d.

Vincent

Re: textsubscript and textsuperscript bug?

2013-04-25 Thread Vincent van Ravesteijn 

Op 27-3-2013 16:00, Richard Heck schreef:

On 03/26/2013 08:41 PM, Scott Kostyshak wrote:
On Mon, Feb 4, 2013 at 7:47 AM, Csikos Bela  
wrote:

Hello:

I guess this is a bug in lyx 2.0.5:
When a subscript (\textsubscript) or superscript (\textsuperscript) 
character is inserted in a text that has different font size than 
default, the size of the sub- or superscript character is incorrect 
in the output; it has the same size as text. This occurs if the sub- 
or superscript character is inserted in a text (that has different 
font size than default) afterwards. If the text including the sub- 
or superscript character is written in normal size and the font size 
is changed subsequently (by selecting text including the sub- or 
superscript character and changing size), the sizes are correct.

See the attached lyx example and the corresponding pdf output.

Hi bcsikos,

Was this addressed? I don't know enough to know if this is a bug. If
no one else chimes in, please post a ticket on
http://www.lyx.org/trac/

Also note that emails regarding bug reports should be sent to the
developers list.


This got reported as #8610. The problem is that we are generating some 
default CSS for this inset, and we are doing that because the font is 
set by default, in the InsetLayout constructor, to sane_font, which 
specifies values for everything. If I add

Font
EndFont
to the Script:superscript InsetLayout declaration, then things work 
fine, since this sets effectively sets the font to inherit_font.


That seems like the right thing to me: that, by default, an 
InsetLayout should get an "empty" font that does not do anything, not 
a fully specified font that resets everything. Yes?


I.e., I am proposing:

diff --git a/src/insets/InsetLayout.cpp b/src/insets/InsetLayout.cpp
index 7729485..aa35f50 100644
--- a/src/insets/InsetLayout.cpp
+++ b/src/insets/InsetLayout.cpp
@@ -34,7 +34,7 @@ namespace lyx {
 InsetLayout::InsetLayout() :
 name_(from_ascii("undefined")), lyxtype_(STANDARD),
 labelstring_(from_ascii("UNDEFINED")), contentaslabel_(false),
-decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(sane_font),
+decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(inherit_font),
 labelfont_(sane_font), bgcolor_(Color_error),
 htmlforcecss_ (false), htmlisblock_(true),
 multipar_(true), custompars_(true), forceplain_(false),

Richard



I didn't look at whether the change is good, but I am wondering whether 
you just did not commit it, or whether you've retracted your proposal ?


Vincent

Re: [PATCH] (Incomplete) Nonexistent debug flag now throws an error

2013-04-25 Thread Vincent van Ravesteijn 

Op 1-4-2013 6:07, Scott Kostyshak schreef:

On Sat, Mar 30, 2013 at 10:02 AM, Vincent van Ravesteijn  wrote:

Op 30-3-2013 6:08, Scott Kostyshak schreef:


The following command now throws an error:

lyx -dbg doesNotExist

NOTE: THIS PATCH IS INCOMPLETE. I think I have the right condition
for detecting the error, but I don't know what to do with it.

I see two ways of throwing an error:
(1) create a new enum value for Type, THROWERROR, which
LyX.cpp::parse_dbg() would test for on return and, if true,
it would handle the error message and exit

(2) from LyX.cpp::parse_dbg(), test lowercase(arg) to make sure it is not
NONE (or 0).
Then, if that is true and if debug.cpp::value(arg) returns NONE, throw
the error.

None of the two seems elegant to me so I'm guessing there is a better
way. Any ideas?


You can make a function

bool Debug::isKnownValue(string const & val)

Then in LyX.cpp::parse_dbg:

if (Debug::isKnownValue(arg)) {
 ..
} else {
 docstring const error_message =

 bformat(_("The following debug flag does not exist:\n %1$s\n"
 "Please see 'lyx -dbg' for a list of valid debug flags."),
 from_utf8(tmp));
 lyxerr << to_utf8(error_message) << endl;
 exit(0);
}

Vincent

I think this is something I need to get used to: I would not have
thought that this duplication of code (e.g. reparsing the string in
the same way) was a good solution but I do see this a lot in C++ so
it's something I need learn.


What do you mean ?

Vincent

Re: textsubscript and textsuperscript bug?

2013-04-25 Thread Richard Heck 

On 04/25/2013 04:45 PM, Vincent van Ravesteijn wrote:

Op 27-3-2013 16:00, Richard Heck schreef:

On 03/26/2013 08:41 PM, Scott Kostyshak wrote:
On Mon, Feb 4, 2013 at 7:47 AM, Csikos Bela  
wrote:

Hello:

I guess this is a bug in lyx 2.0.5:
When a subscript (\textsubscript) or superscript (\textsuperscript) 
character is inserted in a text that has different font size than 
default, the size of the sub- or superscript character is incorrect 
in the output; it has the same size as text. This occurs if the 
sub- or superscript character is inserted in a text (that has 
different font size than default) afterwards. If the text including 
the sub- or superscript character is written in normal size and the 
font size is changed subsequently (by selecting text including the 
sub- or superscript character and changing size), the sizes are 
correct.

See the attached lyx example and the corresponding pdf output.

Hi bcsikos,

Was this addressed? I don't know enough to know if this is a bug. If
no one else chimes in, please post a ticket on
http://www.lyx.org/trac/

Also note that emails regarding bug reports should be sent to the
developers list.


This got reported as #8610. The problem is that we are generating 
some default CSS for this inset, and we are doing that because the 
font is set by default, in the InsetLayout constructor, to sane_font, 
which specifies values for everything. If I add

Font
EndFont
to the Script:superscript InsetLayout declaration, then things work 
fine, since this sets effectively sets the font to inherit_font.


That seems like the right thing to me: that, by default, an 
InsetLayout should get an "empty" font that does not do anything, not 
a fully specified font that resets everything. Yes?


I.e., I am proposing:

diff --git a/src/insets/InsetLayout.cpp b/src/insets/InsetLayout.cpp
index 7729485..aa35f50 100644
--- a/src/insets/InsetLayout.cpp
+++ b/src/insets/InsetLayout.cpp
@@ -34,7 +34,7 @@ namespace lyx {
 InsetLayout::InsetLayout() :
 name_(from_ascii("undefined")), lyxtype_(STANDARD),
 labelstring_(from_ascii("UNDEFINED")), contentaslabel_(false),
-decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(sane_font),
+decoration_(DEFAULT), latextype_(NOLATEXTYPE), font_(inherit_font),
 labelfont_(sane_font), bgcolor_(Color_error),
 htmlforcecss_ (false), htmlisblock_(true),
 multipar_(true), custompars_(true), forceplain_(false),

Richard



I didn't look at whether the change is good, but I am wondering 
whether you just did not commit it, or whether you've retracted your 
proposal ?


No, no one replied, and I wasn't sure what was best. But it would really 
surprise me if it caused some problem. I.e., I would regard THAT as a bug.


I'll go ahead and commit to trunk.

rh

Re: [PATCH] CPack, NSIS: CPACK_SET_DESTDIR not compatible with NSIS

2013-04-25 Thread Hugo Hinterberger 

"Vincent van Ravesteijn"  wrote in message news:51797f11@lyx.org...


The CPACK stuff is highly experimental (at least on Windows it is).


I know, I just wanted to be able to see any new developments by including it 
in my build.


Although your patch is indeed correct, the generated NSIS installer 
doesn't do me much good.


Same here.

I can't find why you would need regex2.dll .. I don't have it and I don't 
need it. Where did you see that this was a problem.


I could not find any reference in the source files either, but the 
executable generated by my build environment (see below and feel free to ask 
for more details) will not run without it and it tells me so by referencing 
the DLL by name.


Since I am using a development build I am trying to keep a current build at 
hand in case I find an issue with the build I am using "in production".


Currently I am having some problems with my build:
1 ) CMake-GUI will not complete successfully -- I just noticed that you made 
some changes to development/cmake/modules/FindQt4.cmake , I will try to 
build it again tomorrow.
2 ) Qt Creator was able to successfully run CMake without your fix but 
failed at some other point during compiling.


btw, does anybody know about any nightly builds of LyX for Windows? Are 
there any free Windows build servers for OSS publicly available?


Kind regards,
Hugo


Some information about my build environment:
Windows 7 x64
CMake 2.8.10
Visual C++ Express 2010
Qt 4.8.4 [1] / Qt 5.0.2 + Qt Creator


[1] 
http://download.qt-project.org/official_releases/qt/4.8/4.8.4/qt-win-opensource-4.8.4-vs2010.exe

Re: Introduction

2013-04-25 Thread Cyrille Artho 

Dear Pulkit,
Thank you for your interest in the LyX community. Many projects have 
already been discussed extensively in the last two weeks. Please take a 
look at the mailing list archive:


http://www.mail-archive.com/lyx-devel@lists.lyx.org/

However, I am not sure if the "LyX presentation mode" has been brought up 
yet. The basic problem there is that LyX is designed to edit text, not 
presentations. So there are a number of things that would make editing 
presentations more intuitive; in particular, a preview of the given 
slide/"page" within LyX would be very nice.


pulkit jain wrote:

Hi all,

My name is Pulkit Jain and I am a fourth year undergraduate at the Indian
Institute of Technology Kharagpur enrolled in the course of Mathematics and
Computing. I wish to participate in Google Summer of code, 2013. Browsing
through the list of organisations, I came across LyX GSoC'13 page. I
visited the Ideas page and "*LyX Presentaiton Mode *and*Toolbar
customization dialog*" projects caught my interest.

I have significant programming experience and have been coding for the past
6 years. I have had courses in Algorithms, Database Management Systems,
  Switching and Finite Automata Theory, Object Oriented Systems, System
Programming, Compiler Design, Operating Systems, Computer Software, etc. I
have also done a research project related to improvement of methods used
for Credit Card Fraud Detection using Genetic Algorithm and Hidden Markow
Models and another project related to optimization of data transfer in
networks. I have substantial skill in C, *C++*, Java, Python. I am ready to
learn anything which will be required to complete the project.

I hope that my background is good enough. I am highly keen to participate
in GSoc'13 in your organisation. I shall be grateful if anyone can point to
me where should I start in order to make a good proposal for the above
mentioned ideas.

Sorry for this late introduction, as I was busy with my college examinations.
Thanking You,

Yours sincerely,
Pulkit


--
Regards,
Cyrille Artho - http://artho.com/
There's nothing wrong with you that reincarnation won't cure.
-- Jack E. Leonard

Re: Customizing Lyx

2013-04-25 Thread Elmar Hinz 
> Exporting the markup syntax is a different issue. I can think of a couple
> ways to do it. The first, and most involved, would be to write export
> routines, in the LyX source itself, similar to the LyXHTML export routines.
> Another would be to write some kind of simple converter that would convert
> some format LyX already exports (perhaps the plaintext format?) to Markdown.


Hello Richard,

if I would like to transform LyXHTML to Markdown, I would need an XSL
library or at least an XML parser.
Is there already something like this contained in the sources? If not, what
is your suggestion to use?

Regards

Elmar

-- 
Elmar Hinz
Freiherr-vom-Stein-Str. 1
33014 Bad Driburg

TYPO3 community contact: t.3.e.l.m.a...@.g.m.a.i.l.dot.c.o.m
personal contact: e.l.m.a.r.dot.h.i.n...@.g.m.a.i.l.dot.c.o.m

Re: [LyX master] Audit all the LASSERT calls, and try to do something sensible at each failure.

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 5:29 PM, Richard Heck  wrote:
> The branch, master, has been updated.
>
> - Log -
>
> commit 1b1f8dd235ba8e168348cd23c824063f2595a0c5
> Author: Richard Heck 
> Date:   Thu Apr 25 17:27:10 2013 -0400
>
> Audit all the LASSERT calls, and try to do something sensible at
> each failure.
>
> There are several places I was not sure what to do. These are marked
> by comments beginning "LASSERT:" so they can be found easily. At the
> moment, they are at:
>
> Author.cpp:105: // LASSERT: What should we do here?
> Author.cpp:121: // LASSERT: What should we do here?
> Buffer.cpp:4525:// LASSERT: Is it safe to continue here, or 
> should we just return?
> Cursor.cpp:345: // LASSERT: Is it safe to continue here, or 
> should we return?
> Cursor.cpp:403: // LASSERT: Is it safe to continue here, or 
> should we return?
> Cursor.cpp:1143:// LASSERT: There have been several bugs 
> around this code, that seem
> CursorSlice.cpp:83: // LASSERT: This should only ever be called from 
> an InsetMath.
> CursorSlice.cpp:92: // LASSERT: This should only ever be called from 
> an InsetMath.
> LayoutFile.cpp:303: // LASSERT: Why would this fail?
> Text.cpp:995:   // LASSERT: Is it safe to continue here?

I'm getting an assertion now whenever I try to insert a table or
graphics or float:
ASSERTION false VIOLATED IN
/home/scott/lyxbuilds/master/build/src/Paragraph.cpp:1853

Scott

Re: Changing sizes of GuiTabular combo boxes

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 4:38 PM, Vincent van Ravesteijn  wrote:
> Op 19-3-2013 8:43, Scott Kostyshak schreef:
>
>> Make a table and go to the tabular settings. Toggle multicolumn or
>> multirow and you'll see the combo boxes and the text box changing
>> width because "At Decimal Separator" is no longer an option. This did
>> not happen before. I think commit 6f157533 triggered this.
>>
>> I could not figure out how to prevent this behavior. Changing the
>> horizontal policy did not seem to lead to a fix. If I set
>> hAlignCO->setMinimumWidth() manually with a hard coded size then it
>> works, but this is not a real solution.
>>
>> Any ideas?
>>
>> Thanks,
>>
>> Scott
>
> I fixed this at 262f58d.

Works well. Thanks, Scott

Re: [PATCH] (Incomplete) Nonexistent debug flag now throws an error

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 4:49 PM, Vincent van Ravesteijn  wrote:
> Op 1-4-2013 6:07, Scott Kostyshak schreef:
>> I think this is something I need to get used to: I would not have
>> thought that this duplication of code (e.g. reparsing the string in
>> the same way) was a good solution but I do see this a lot in C++ so
>> it's something I need learn.
>
>
> What do you mean ?

Checking whether a debug flag is valid and then setting that debug
flag both involve looping through all the debug flags. When initially
looking at this, the most natural thing seemed to me that there should
be only one loop. But I think this separation of validation and
processing is common in C++ and that I should learn to not worry about
looping twice instead of once. Especially for such a small vector,
this does not have any real performance issue.

Besides performance though it still seems to me that the code could be
more simple if there were just one loop. Is there a reason why it
would be bad in this case to have one loop and throw an exception if a
debug flag does not exist? Would it be reasonable to do a try/catch
around lyxerr.setLevel(Debug::value(arg)) and obviate the need for
Debug::isKnownValue(tmp) ?

Scott

Re: \centerline{} support for wide graphics and tables

2013-04-25 Thread Scott Kostyshak 
On Thu, Apr 25, 2013 at 3:33 PM, Vincent van Ravesteijn  wrote:
> Op 19-3-2013 4:35, Scott Kostyshak schreef:
>
>> When inserting a graphic or table whose width is larger than
>> \textwidth, the extra width spills over to the right margin. This
>> might be desired in some cases, but in other cases it is nice to
>> center the graphic or table on the page. Using \centerline{}, the
>> extra width is split evenly across the left and right margins.
>>
>> The following .lyx file shows a couple of ways to address this:
>> http://paste.debian.net/242737/. One way is to sandwich the table or
>> graphic between '\centerline{' and '}' ERT boxes. Another way is to
>> use the adjustbox package. I'm not sure if there are advantages to one
>> over the other, but since \centerline does not require another
>> package, I propose to use it over the adjustbox package.
>>
>> I would like to implement support for it in the tabular settings and
>> graphics settings as a check box.
>>
>> The option could be labelled one of the following:
>>
>> (1) "center across both margins"
>> (2) "center on page across both margins"
>> (3) "center a wide table" / "center a wide graphic"
>>
>
> It should be clear that this option is only used when the image is too wide.
>
> If you want to implement this, you need to detect when an image is too
> wide.. How do you plan to dot that ?

I was not planning on doing that. I was thinking that in many cases
the user knows when it is too large and would manually set this
option. There has been some very preliminary discussion (in the email
thread on the GSoC horizontal scrollbar project) of parsing the log
for specific overfull hboxes; but I do not think it makes sense to
automatically detect this and set \centerline without the user
knowing.

Scott

Re: Interested in GSOC Project:

2013-04-25 Thread Hashini Senaratne 
Jean-Marc Lasgouttes  lyx.org> writes:
> To be frank, I do not know. Sometimes (I will write about it in another 
> thread to vary a bit) I think that an horizontal scrollbar for the whole 
> workarea would actually be enough (but anyway the effect should be 
> obtained through changes to TextMetrics.cpp as I described).
> 
> Note that a table only requires one Row as I understand it. Therefore 
> the whole table would move as a simple object. OTOH in a paragraph, only 
> one line of the paragraph would move. Of course some UI would be needed 
> to make this understandable.

I like to experiment on this in the coming week. Thank you for your guidance.

As the student application term is running on, I drafted my application and 
submitted it already. I am thankful to you and Scott (or may be any potential 
developer) if can review my application and give me some feedback to improve.

Thank you
Hashini