Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Georg Baum]

Richard Heck wrote:

> On 09/06/2016 06:10 PM, Georg Baum wrote:
>> Richard Heck wrote:
>>
>>> On 09/05/2016 04:56 PM, Georg Baum wrote:
 I think he meant the missing .xlsx extension in the external material
 file dialog. I added this in master at df8e0ed9e0c37ab7.
>>> Fine for stable too.
>> I need 646d47ae9393bc for stable too, otherwise I only see one filter
>> "All files".
> 
> That is fine with me.

Thanks, both changes are in.


Georg

RE: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Jannick]

From: Helge Hafting [mailto:helge.haft...@ntnu.no] 
Sent: Monday, September 5, 2016 3:07 PM

Den 05. sep. 2016 00:53, skrev Jannick:
> Currently lyx deals with *.xls files only, while the Excel world 
> rather turns around .xlsx files. It would be great if lyx could be 
> extended including the file handler where ssconvert appears to 
> faithfully extract data from *.xlsx files.
>
> I am not subscribed to the devel list, so please copy me in if you 
> need any more information on this from my side.
>
LyX already support .xlsx, so I am not sure what you are asking for here?

I created a LyX document, inserted a file (external material). I selected
spreadsheet, and typed in "testfile.xlsx". This worked fine, the PDF
contained the spreadsheet. Anything "ssconvert" supports should indeed work.
I don't know if ssconvert handles all xlsx files, but it certainly handled
my testfile well.

I tested with LyX 2.2.1, but this sould work for most earlier versions too -
as there haven't been much changes since the excel support went in.
Conversion is handled by ssconvert, so anything ssconvert handles should
work, (unless the spreadsheet is wider than the page).

Do you have an xlsx file that ssconvert handles, but LyX does not? If so,
please send me such a file so I can look into it.

Helge Hafting

_

Thanks. What I am suggesting is an enhancement of lyx' ssconvert interface
(i.e. for external material/tables), namely:

1 - adding *.xlsx to the file filter of the file selection dialog window (to
avoid manual entering the file name - as you suggested - and not to be
cluttered with all files in the specific folder after selecting the file
filter *.* provided as second option in the file selection dialog window)

2 - add *.xlsx in the default file handler configuration which does not
appear to exist in the default configuration (in lyx 2.1.5 (on Win10) there
is only one explicitly saying that it deals with *.xls). 

Regards,
J. 

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Richard Heck]

On 09/06/2016 06:10 PM, Georg Baum wrote:
> Richard Heck wrote:
>
>> On 09/05/2016 04:56 PM, Georg Baum wrote:
>>> I think he meant the missing .xlsx extension in the external material
>>> file dialog. I added this in master at df8e0ed9e0c37ab7.
>> Fine for stable too.
> I need 646d47ae9393bc for stable too, otherwise I only see one filter "All 
> files". 

That is fine with me.

> Does anybody understand the old code? 

No.

Richard

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Georg Baum]

Richard Heck wrote:

> On 09/05/2016 04:56 PM, Georg Baum wrote:
>> I think he meant the missing .xlsx extension in the external material
>> file dialog. I added this in master at df8e0ed9e0c37ab7.
> 
> Fine for stable too.

I need 646d47ae9393bc for stable too, otherwise I only see one filter "All 
files". Does anybody understand the old code? Does anybody see the same 
problem with current branch (no file browse dialog of an external inset has 
a specific filter)?


Georg

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Richard Heck]

On 09/05/2016 04:56 PM, Georg Baum wrote:
> Helge Hafting wrote:
>
>> Den 05. sep. 2016 00:53, skrev Jannick:
>>> Currently lyx deals with *.xls files only, while the Excel world rather
>>> turns around .xlsx files. It would be great if lyx could be extended
>>> including the file handler where ssconvert appears to faithfully extract
>>> data from *.xlsx files.
>>>
>>> I am not subscribed to the devel list, so please copy me in if you need
>>> any more information on this from my side.
>>>
>> LyX already support .xlsx, so I am not sure what you are asking for here?
> I think he meant the missing .xlsx extension in the external material file 
> dialog. I added this in master at df8e0ed9e0c37ab7.

Fine for stable too.

rh

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Georg Baum]

Helge Hafting wrote:

> Den 05. sep. 2016 00:53, skrev Jannick:
>> Currently lyx deals with *.xls files only, while the Excel world rather
>> turns around .xlsx files. It would be great if lyx could be extended
>> including the file handler where ssconvert appears to faithfully extract
>> data from *.xlsx files.
>>
>> I am not subscribed to the devel list, so please copy me in if you need
>> any more information on this from my side.
>>
> LyX already support .xlsx, so I am not sure what you are asking for here?

I think he meant the missing .xlsx extension in the external material file 
dialog. I added this in master at df8e0ed9e0c37ab7.


Georg

Re: [enhancement] add *.xlsx to external data material dialog (table) and file handler

[Helge Hafting]

Den 05. sep. 2016 00:53, skrev Jannick:

Currently lyx deals with *.xls files only, while the Excel world rather
turns around .xlsx files. It would be great if lyx could be extended
including the file handler where ssconvert appears to faithfully extract
data from *.xlsx files.

I am not subscribed to the devel list, so please copy me in if you need any
more information on this from my side.


LyX already support .xlsx, so I am not sure what you are asking for here?

I created a LyX document, inserted a file (external material). I 
selected spreadsheet, and typed in "testfile.xlsx". This worked fine, 
the PDF contained the spreadsheet. Anything "ssconvert" supports should 
indeed work. I don't know if ssconvert handles all xlsx files, but it 
certainly handled my testfile well.


I tested with LyX 2.2.1, but this sould work for most earlier versions 
too - as there haven't been much changes since the excel support went 
in. Conversion is handled by ssconvert, so anything ssconvert handles 
should work, (unless the spreadsheet is wider than the page).


Do you have an xlsx file that ssconvert handles, but LyX does not? If 
so, please send me such a file so I can look into it.


Helge Hafting

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 15.04.2016 um 11:06 schrieb Scott Kostyshak :
> 
> On Fri, Apr 15, 2016 at 10:36:59AM +0200, Stephan Witt wrote:
>> Am 15.04.2016 um 09:51 schrieb Scott Kostyshak :
>>> 
>>> On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:
 Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> 
> Le 14/04/2016 19:05, Stephan Witt a écrit :
>> 
>> Yes, it’s attached. Thanks for testing.
>> 
> 
> 
> Works well on Linux+qt{4,5}.
> 
> Two remarks:
> 
> * isFixedPitch() would be in an anonymous namespace by what I know of 
> LyX's code style.
> * In my patch I compute typewriterFontName() from typewriterSystemFont. 
> Would you make this change?
 
 Like this one?
>>> 
>>> If you do not set the font to 12 point on Mac, it is too small?
>> 
>> Yes, this is what Joel said I’d say it too.
> 
> True, and comparing with the size on my system, it does seem to be a
> difference in platforms and not a difference in what we consider to be
> small.
> 
>>> I did read the thread and that you tried to configure Qt system
>>> settings, but it seems unfortunate to introduce platform-dependent
>>> code for something like this.
>>> 
>>> Just to confirm: hard-coding the font size should not change anything
>>> for HiDPI right?
>> 
>> It does the Right Thing - because it’s not in pixels but in points.
> 
> OK.
> 
>>> Doing a grep for "setPointSize" does not show any other examples of
>>> hardcoding, if I understand correctly. Why is it only needed here?
>> 
>> Because it’s a system font to paint with being used only here.
>> 
>> I’ve extended the patch with comments and I’ll provide some screen shots 
>> to illustrate the font sizes.
> 
> I see.
> 
> Please commit.
> 
> Scott

Done with 87c85303c5c5980b1189867c5dc9e711acf77c07.

Stephan

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Scott Kostyshak]

On Fri, Apr 15, 2016 at 10:36:59AM +0200, Stephan Witt wrote:
> Am 15.04.2016 um 09:51 schrieb Scott Kostyshak :
> > 
> > On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:
> >> Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> >>> 
> >>> Le 14/04/2016 19:05, Stephan Witt a écrit :
>  
>  Yes, it’s attached. Thanks for testing.
>  
> >>> 
> >>> 
> >>> Works well on Linux+qt{4,5}.
> >>> 
> >>> Two remarks:
> >>> 
> >>> * isFixedPitch() would be in an anonymous namespace by what I know of 
> >>> LyX's code style.
> >>> * In my patch I compute typewriterFontName() from typewriterSystemFont. 
> >>> Would you make this change?
> >> 
> >> Like this one?
> > 
> > If you do not set the font to 12 point on Mac, it is too small?
> 
> Yes, this is what Joel said I’d say it too.

True, and comparing with the size on my system, it does seem to be a
difference in platforms and not a difference in what we consider to be
small.

> > I did read the thread and that you tried to configure Qt system
> > settings, but it seems unfortunate to introduce platform-dependent
> > code for something like this.
> > 
> > Just to confirm: hard-coding the font size should not change anything
> > for HiDPI right?
> 
> It does the Right Thing - because it’s not in pixels but in points.

OK.

> > Doing a grep for "setPointSize" does not show any other examples of
> > hardcoding, if I understand correctly. Why is it only needed here?
> 
> Because it’s a system font to paint with being used only here.
> 
> I’ve extended the patch with comments and I’ll provide some screen shots 
> to illustrate the font sizes.

I see.

Please commit.

Scott


signature.asc
Description: PGP signature

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Andrew Parsloe]

On 15/04/2016 7:51 p.m., Scott Kostyshak wrote:

On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:

Am 14.04.2016 um 20:16 schrieb Guillaume Munch :

Le 14/04/2016 19:05, Stephan Witt a écrit :

Yes, it’s attached. Thanks for testing.



Works well on Linux+qt{4,5}.

Two remarks:

* isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
code style.
* In my patch I compute typewriterFontName() from typewriterSystemFont. Would 
you make this change?

Like this one?

If you do not set the font to 12 point on Mac, it is too small?

I did read the thread and that you tried to configure Qt system
settings, but it seems unfortunate to introduce platform-dependent
code for something like this.

Just to confirm: hard-coding the font size should not change anything
for HiDPI right?

Doing a grep for "setPointSize" does not show any other examples of
hardcoding, if I understand correctly. Why is it only needed here?

Scott
On windows there has been a noticeable reduction in font size in the 
preamble window. In the attached file, the one on the left is 2.1.4, the 
one on the right rc1.


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Scott Kostyshak]

On Thu, Apr 14, 2016 at 08:53:24PM +0200, Stephan Witt wrote:
> Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> > 
> > Le 14/04/2016 19:05, Stephan Witt a écrit :
> >> 
> >> Yes, it’s attached. Thanks for testing.
> >> 
> > 
> > 
> > Works well on Linux+qt{4,5}.
> > 
> > Two remarks:
> > 
> > * isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
> > code style.
> > * In my patch I compute typewriterFontName() from typewriterSystemFont. 
> > Would you make this change?
> 
> Like this one?

If you do not set the font to 12 point on Mac, it is too small?

I did read the thread and that you tried to configure Qt system
settings, but it seems unfortunate to introduce platform-dependent
code for something like this.

Just to confirm: hard-coding the font size should not change anything
for HiDPI right?

Doing a grep for "setPointSize" does not show any other examples of
hardcoding, if I understand correctly. Why is it only needed here?

Scott


signature.asc
Description: PGP signature

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 19:53, Stephan Witt a écrit :

Am 14.04.2016 um 20:16 schrieb Guillaume Munch :


Le 14/04/2016 19:05, Stephan Witt a écrit :


Yes, it’s attached. Thanks for testing.




Works well on Linux+qt{4,5}.

Two remarks:

* isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
code style.
* In my patch I compute typewriterFontName() from typewriterSystemFont. Would 
you make this change?


Like this one?



+1

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 20:16 schrieb Guillaume Munch :
> 
> Le 14/04/2016 19:05, Stephan Witt a écrit :
>> 
>> Yes, it’s attached. Thanks for testing.
>> 
> 
> 
> Works well on Linux+qt{4,5}.
> 
> Two remarks:
> 
> * isFixedPitch() would be in an anonymous namespace by what I know of LyX's 
> code style.
> * In my patch I compute typewriterFontName() from typewriterSystemFont. Would 
> you make this change?

Like this one?

Stephan



typewriter-systemfont-patch-3.diff
Description: Binary data

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 19:05, Stephan Witt a écrit :


Yes, it’s attached. Thanks for testing.




Works well on Linux+qt{4,5}.

Two remarks:

* isFixedPitch() would be in an anonymous namespace by what I know of 
LyX's code style.
* In my patch I compute typewriterFontName() from typewriterSystemFont. 
Would you make this change?

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 19:46 schrieb Guillaume Munch :
> 
> Le 14/04/2016 18:41, Stephan Witt a écrit :
>> Am 14.04.2016 um 19:28 schrieb Guillaume Munch :
>>> 
>>> Le 14/04/2016 18:10, Stephan Witt a écrit :
 Am 14.04.2016 um 18:18 schrieb Joel Kulesza
 :
> 
> On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
> wrote:
> 
> Can you please try the attached patch?
> 
> That patch seemed to work to correct the issue in both places
> (see attached). The font seems small (I'm not sure if that's
> perception or reality).  Regardless, it is fixed width.  Thank
> you! 
 
 Good idea. I can confirm this. Though some refactoring should be
 done, IMO. See the attached patch. This allows some consistent
 tweaking of font site too.
 
 Stephan
 
>>> 
>>> Thanks for your patch. Then it should probably more be as the
>>> attached.
>> 
>> Yes, Qt < 5.2 doesn’t have the QFontDatabase::systemFont etc.
>> 
>> While googling I found this (and adapted it) for Mac:
> 
> Looks fine to me. Can you please make a patch out of it so that I can test?

Yes, it’s attached. Thanks for testing.

Stephan

> 
>> ...
>> 
>> 
>>> 
>>> The font size of 12 appears too big here.
>> 
>> I couldn’t come up with a solution to configure Qt system settings on
>> Mac. I already searched for something like that to solve the cursor
>> thickness issue (should be configurable too) and failed.
>> 
>>> I'm more thinking of a local configuration issue. I do not
>>> recommend keeping this font size line.
>> 
>> Yes, probably better.
> 
> I'm fine with the "#ifdef Q_OS_MAC"



typewriter-systemfont-patch-2.diff
Description: Binary data

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 18:41, Stephan Witt a écrit :

Am 14.04.2016 um 19:28 schrieb Guillaume Munch :


Le 14/04/2016 18:10, Stephan Witt a écrit :

Am 14.04.2016 um 18:18 schrieb Joel Kulesza
:


On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
wrote:

Can you please try the attached patch?

That patch seemed to work to correct the issue in both places
(see attached). The font seems small (I'm not sure if that's
perception or reality).  Regardless, it is fixed width.  Thank
you! 


Good idea. I can confirm this. Though some refactoring should be
done, IMO. See the attached patch. This allows some consistent
tweaking of font site too.

Stephan



Thanks for your patch. Then it should probably more be as the
attached.


Yes, Qt < 5.2 doesn’t have the QFontDatabase::systemFont etc.

While googling I found this (and adapted it) for Mac:


Looks fine to me. Can you please make a patch out of it so that I can test?


...




The font size of 12 appears too big here.


I couldn’t come up with a solution to configure Qt system settings on
Mac. I already searched for something like that to solve the cursor
thickness issue (should be configurable too) and failed.


I'm more thinking of a local configuration issue. I do not
recommend keeping this font size line.


Yes, probably better.


I'm fine with the "#ifdef Q_OS_MAC"

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 19:28 schrieb Guillaume Munch :
> 
> Le 14/04/2016 18:10, Stephan Witt a écrit :
>> Am 14.04.2016 um 18:18 schrieb Joel Kulesza :
>>> 
>>> On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
>>> wrote:
>>> 
>>> Can you please try the attached patch?
>>> 
>>> That patch seemed to work to correct the issue in both places (see
>>> attached). The font seems small (I'm not sure if that's perception
>>> or reality).  Regardless, it is fixed width.  Thank you! >> Shot 2016-04-14 at 12.18.34 PM.png>
>> 
>> Good idea. I can confirm this. Though some refactoring should be
>> done, IMO. See the attached patch. This allows some consistent
>> tweaking of font site too.
>> 
>> Stephan
>> 
> 
> Thanks for your patch. Then it should probably more be as the attached.

Yes, Qt < 5.2 doesn’t have the QFontDatabase::systemFont etc.

While googling I found this (and adapted it) for Mac:

=
static bool isFixedPitch(const QFont & font) {
const QFontInfo fi(font);
return fi.fixedPitch();
}


QFont const GuiApplication::typewriterSystemFont()
{
#if QT_VERSION >= 0x050200
QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
#else
QFont font("monospace");
#endif
if (!isFixedPitch(font)) {
font.setStyleHint(QFont::Monospace);
if (!isFixedPitch(font)) {
font.setStyleHint(QFont::TypeWriter);
if (!isFixedPitch(font)) font.setFamily("courier");
}
}
#ifdef Q_OS_MAC
font.setPointSize(12);
#endif 
return font;
}
=


> 
> The font size of 12 appears too big here.

I couldn’t come up with a solution to configure Qt system settings on Mac.
I already searched for something like that to solve the cursor thickness 
issue (should be configurable too) and failed.

> I'm more thinking of a local
> configuration issue. I do not recommend keeping this font size line.

Yes, probably better.

Stephan

> 
> <0001-Fix-monospace-fonts-on-Mac.patch>

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 18:10, Stephan Witt a écrit :

Am 14.04.2016 um 18:18 schrieb Joel Kulesza :


On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch 
wrote:

Can you please try the attached patch?

That patch seemed to work to correct the issue in both places (see
attached). The font seems small (I'm not sure if that's perception
or reality).  Regardless, it is fixed width.  Thank you! 


Good idea. I can confirm this. Though some refactoring should be
done, IMO. See the attached patch. This allows some consistent
tweaking of font site too.

Stephan



Thanks for your patch. Then it should probably more be as the attached.

The font size of 12 appears too big here. I'm more thinking of a local
configuration issue. I do not recommend keeping this font size line.

>From 45a1bffe5964965c39266fe606e0c20b895a0591 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Thu, 14 Apr 2016 18:17:46 +0100
Subject: [PATCH] Fix monospace fonts on Mac

Based on a patch by Stephan Witt

http://mid.gmane.org/caagogw97a-j9zxy6sdrj-g_-zewdz+fstkgudsso3udx3tp...@mail.gmail.com
---
 src/frontends/qt4/GuiApplication.cpp  | 16 ++--
 src/frontends/qt4/GuiApplication.h|  3 +++
 src/frontends/qt4/GuiDocument.cpp |  5 +
 src/frontends/qt4/GuiLog.cpp  |  5 +
 src/frontends/qt4/GuiProgressView.cpp |  5 +
 src/frontends/qt4/GuiViewSource.cpp   |  5 +
 6 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/src/frontends/qt4/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index 12f99d5..cde8a56 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -82,6 +82,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -2557,11 +2558,22 @@ QString const GuiApplication::sansFontName()
 
 QString const GuiApplication::typewriterFontName()
 {
+	return QFontInfo(typewriterSystemFont()).family();
+}
+
+
+QFont const GuiApplication::typewriterSystemFont()
+{
+#if QT_VERSION >= 0x050200
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
+#else
 	QFont font;
 	font.setStyleHint(QFont::TypeWriter);
 	font.setFamily("monospace");
-
-	return QFontInfo(font).family();
+	font.setFixedPitch(true);
+#endif
+	font.setPointSize(12);
+	return font;
 }
 
 
diff --git a/src/frontends/qt4/GuiApplication.h b/src/frontends/qt4/GuiApplication.h
index 350adc8..861810d 100644
--- a/src/frontends/qt4/GuiApplication.h
+++ b/src/frontends/qt4/GuiApplication.h
@@ -25,6 +25,7 @@
 class QAbstractItemModel;
 class QIcon;
 class QSessionManager;
+class QFont;
 
 namespace lyx {
 
@@ -145,6 +146,8 @@ public:
 
 	/// return a suitable monospaced font name.
 	QString const typewriterFontName();
+	QFont const typewriterSystemFont();
+
 	///
 	void unregisterView(GuiView * gv);
 	///
diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index e4dff1d..2eedec9 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,10 +453,7 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
-	QFont font(guiApp->typewriterFontName());
-	font.setFixedPitch(true);
-	font.setStyleHint(QFont::TypeWriter);
-	preambleTE->setFont(font);
+	preambleTE->setFont(guiApp->typewriterSystemFont());
 	preambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
 	connect(preambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
diff --git a/src/frontends/qt4/GuiLog.cpp b/src/frontends/qt4/GuiLog.cpp
index dec7c25..23ba276 100644
--- a/src/frontends/qt4/GuiLog.cpp
+++ b/src/frontends/qt4/GuiLog.cpp
@@ -133,10 +133,7 @@ GuiLog::GuiLog(GuiView & lv)
 	highlighter = new LogHighlighter(logTB->document());
 
 	logTB->setReadOnly(true);
-	QFont font(guiApp->typewriterFontName());
-	font.setFixedPitch(true);
-	font.setStyleHint(QFont::TypeWriter);
-	logTB->setFont(font);
+	logTB->setFont(guiApp->typewriterSystemFont());
 }
 
 
diff --git a/src/frontends/qt4/GuiProgressView.cpp b/src/frontends/qt4/GuiProgressView.cpp
index fa15786..af455f2 100644
--- a/src/frontends/qt4/GuiProgressView.cpp
+++ b/src/frontends/qt4/GuiProgressView.cpp
@@ -71,10 +71,7 @@ GuiProgressView::GuiProgressView(GuiView & parent, Qt::DockWidgetArea area,
 	widget_->adjustSize();
 	setWidget(widget_);
 
-	QFont font(guiApp->typewriterFontName());
-	font.setFixedPitch(true);
-	font.setStyleHint(QFont::TypeWriter);
-	widget_->outTE->setFont(font);
+	widget_->outTE->setFont(guiApp->typewriterSystemFont());
 	widget_->tabWidget->widget(0)->setContentsMargins(-5, -7, 0, -7);
 
 	connect(widget_->debugNoneRB, SIGNAL(clicked()),
diff --git a/src/frontends/qt4/GuiViewSource.cpp b/src/frontends/qt4/GuiViewSource.cpp
index e528222..192a163 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -86,10 +86,7 @@ 

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Stephan Witt]

Am 14.04.2016 um 18:18 schrieb Joel Kulesza :
> 
> On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch  wrote:
> 
> Can you please try the attached patch?
> 
> That patch seemed to work to correct the issue in both places (see attached). 
> The font seems small (I'm not sure if that's perception or reality).  
> Regardless, it is fixed width.  Thank you!
> 

Good idea. I can confirm this. Though some refactoring should be done, IMO. See 
the attached patch.
This allows some consistent tweaking of font site too.

Stephan



typewriter-systemfont-patch.diff
Description: Binary data

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 17:18, Joel Kulesza a écrit :

On Thu, Apr 14, 2016 at 10:24 AM, Guillaume Munch > wrote:


Can you please try the attached patch?


That patch seemed to work to correct the issue in both places (see
attached). The font seems small (I'm not sure if that's perception or
reality).  Regardless, it _is_ fixed width.  Thank you!


The font size did not change... Can you change it externally from your 
system settings?


Here's a cleaned-up patch that I will recommend for inclusion if 
successful. Can you please try it?
>From 959d6fc0a945f09fc383f86d915b2f29e5002117 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Thu, 14 Apr 2016 15:22:26 +0100
Subject: [PATCH] Fix monospace fonts in the source panel and preamble on Mac

http://mid.gmane.org/caagogw97a-j9zxy6sdrj-g_-zewdz+fstkgudsso3udx3tp...@mail.gmail.com
---
 src/frontends/qt4/GuiDocument.cpp   | 4 
 src/frontends/qt4/GuiViewSource.cpp | 4 
 2 files changed, 8 insertions(+)

diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index e4dff1d..f76c3fe 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,9 +453,13 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
+#if QT_VERSION >= 0x050200
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
+#else
 	QFont font(guiApp->typewriterFontName());
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
+#endif
 	preambleTE->setFont(font);
 	preambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
diff --git a/src/frontends/qt4/GuiViewSource.cpp b/src/frontends/qt4/GuiViewSource.cpp
index e528222..8506fb4 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -86,9 +86,13 @@ ViewSourceWidget::ViewSourceWidget()
 	viewSourceTV->setReadOnly(true);
 	///dialog_->viewSourceTV->setAcceptRichText(false);
 	// this is personal. I think source code should be in fixed-size font
+#if QT_VERSION >= 0x050200
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
+#else
 	QFont font(guiApp->typewriterFontName());
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
+#endif
 	viewSourceTV->setFont(font);
 	// again, personal taste
 	viewSourceTV->setWordWrapMode(QTextOption::NoWrap);
-- 
2.1.4

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 13:33, Joel Kulesza a écrit :

On Thu, Apr 14, 2016 at 8:29 AM, Joel Kulesza > wrote:

On Thu, Apr 14, 2016 at 8:18 AM, Guillaume Munch > wrote:

Yes it's there. Code is very now similar to the source panel.
What font
do you see on the source panel?


There is no apparent change; see attached.


Sorry for spam, I had an email misfire.  See attached for both screenshots.

There is no apparent change. The preamble appears consistent with the
source pane.  I would not have knowingly changed the source pane font —
how can I change it to fixed-width?  Better asked: how can we assure it
is fixed width by default?



Can you please try the attached patch?

>From e25849aeebddd2dd7fe139cba1c119c980ca7cad Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Thu, 14 Apr 2016 15:22:26 +0100
Subject: [PATCH] Fix monospace fonts in Mac

This requires qt >= 5.2
---
 src/frontends/qt4/GuiDocument.cpp   | 2 +-
 src/frontends/qt4/GuiViewSource.cpp | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index e4dff1d..9de5cfa 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,7 +453,7 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
-	QFont font(guiApp->typewriterFontName());
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
 	preambleTE->setFont(font);
diff --git a/src/frontends/qt4/GuiViewSource.cpp b/src/frontends/qt4/GuiViewSource.cpp
index e528222..2b70299 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -86,7 +86,7 @@ ViewSourceWidget::ViewSourceWidget()
 	viewSourceTV->setReadOnly(true);
 	///dialog_->viewSourceTV->setAcceptRichText(false);
 	// this is personal. I think source code should be in fixed-size font
-	QFont font(guiApp->typewriterFontName());
+	QFont font = QFontDatabase::systemFont(QFontDatabase::FixedFont);
 	font.setFixedPitch(true);
 	font.setStyleHint(QFont::TypeWriter);
 	viewSourceTV->setFont(font);
-- 
2.1.4

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 14/04/2016 12:13, Joel Kulesza a écrit :

On Wed, Feb 17, 2016 at 10:39 PM, Scott Kostyshak > wrote:

On Wed, Feb 17, 2016 at 10:11:27PM -0500, Richard Heck wrote:
> Seems to me a change better for 2.2.0, if Scott is all right with it.
Yes go ahead. And thanks for the patch.
Scott


Is this a feature that would have been included in 2.2.0rc1?  That was
my understanding but I'm not seeing it.




Yes it's there. Code is very now similar to the source panel. What font
do you see on the source panel?

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Joel Kulesza]

On Wed, Feb 17, 2016 at 10:39 PM, Scott Kostyshak  wrote:

> On Wed, Feb 17, 2016 at 10:11:27PM -0500, Richard Heck wrote:
> > Seems to me a change better for 2.2.0, if Scott is all right with it.
> Yes go ahead. And thanks for the patch.
> Scott
>

Is this a feature that would have been included in 2.2.0rc1?  That was my
understanding but I'm not seeing it.

Thank you,
Joel

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Scott Kostyshak]

On Wed, Feb 17, 2016 at 10:11:27PM -0500, Richard Heck wrote:
> On 02/17/2016 09:09 PM, Guillaume Munch wrote:
> > Le 18/02/2016 01:58, Richard Heck a écrit :
> >> On 02/17/2016 05:11 PM, Pavel Sanda wrote:
> >>> Guillaume Munch wrote:
>  The attached patch copies code from the source panel, so it is safe.
> >>> I don't know what is the current beta policy, if Scott is fine with
> >>> that it has my +1.
> >>
> >> Tested? If so, has my +1, too. (No time myself right now.)
> >>
> >
> > Yes. Thanks. I do not care whether it is for 2.2.0 or 2.2.1. Scott's
> > call.
> 
> Seems to me a change better for 2.2.0, if Scott is all right with it.

Yes go ahead. And thanks for the patch.

Scott


signature.asc
Description: PGP signature

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Richard Heck]

On 02/17/2016 09:09 PM, Guillaume Munch wrote:
> Le 18/02/2016 01:58, Richard Heck a écrit :
>> On 02/17/2016 05:11 PM, Pavel Sanda wrote:
>>> Guillaume Munch wrote:
 The attached patch copies code from the source panel, so it is safe.
>>> I don't know what is the current beta policy, if Scott is fine with
>>> that it has my +1.
>>
>> Tested? If so, has my +1, too. (No time myself right now.)
>>
>
> Yes. Thanks. I do not care whether it is for 2.2.0 or 2.2.1. Scott's
> call.

Seems to me a change better for 2.2.0, if Scott is all right with it.

Richard

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 18/02/2016 01:58, Richard Heck a écrit :

On 02/17/2016 05:11 PM, Pavel Sanda wrote:

Guillaume Munch wrote:

The attached patch copies code from the source panel, so it is safe.

I don't know what is the current beta policy, if Scott is fine with that it has 
my +1.


Tested? If so, has my +1, too. (No time myself right now.)



Yes. Thanks. I do not care whether it is for 2.2.0 or 2.2.1. Scott's call.

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Richard Heck]

On 02/17/2016 05:11 PM, Pavel Sanda wrote:
> Guillaume Munch wrote:
>> The attached patch copies code from the source panel, so it is safe.
> I don't know what is the current beta policy, if Scott is fine with that it 
> has my +1.

Tested? If so, has my +1, too. (No time myself right now.)

rh

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Pavel Sanda]

Guillaume Munch wrote:
> The attached patch copies code from the source panel, so it is safe.

I don't know what is the current beta policy, if Scott is fine with that
it has my +1.
Pavel

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guenter Milde]

On 2016-02-17, Guillaume Munch wrote:

> [-- Type: text/plain, Encoding: 8bit --]

> Le 17/02/2016 19:10, Pavel Sanda a écrit :
>> Joel Kulesza wrote:
>>> My suggestion is to change the default font of the Settings->Preamble text
>>> box to a fixed-width font because the content is effectively code.  This
>>> change should improve readability for those that make extensive use of the
>>> preamble.

>>> Going a step further with the topic: would it also make sense to disable
>>> (or make optional) line-wrapping in the preamble dialog?

>>> I would appreciate hearing your thoughts on this.

>> Seems like trivial and sensible fix, if anyone comes with patch it can make
>> it into 2.2.0/x.

+1 for the idea

> The attached patch copies code from the source panel, so it is safe.

I hope so, but would prefer someone with C++ experience to review.

Günter

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Guillaume Munch]

Le 17/02/2016 19:10, Pavel Sanda a écrit :

Joel Kulesza wrote:

My suggestion is to change the default font of the Settings->Preamble text
box to a fixed-width font because the content is effectively code.  This
change should improve readability for those that make extensive use of the
preamble.

Going a step further with the topic: would it also make sense to disable
(or make optional) line-wrapping in the preamble dialog?

I would appreciate hearing your thoughts on this.


Seems like trivial and sensible fix, if anyone comes with patch it can make
it into 2.2.0/x.




The attached patch copies code from the source panel, so it is safe.


>From 3339ed951d8bec5ac1783182baca7d51f6516326 Mon Sep 17 00:00:00 2001
From: Guillaume Munch 
Date: Wed, 17 Feb 2016 21:45:44 +
Subject: [PATCH] Set the preamble in fixed-width font and without line breaks
 (#9966)

---
 src/frontends/qt4/GuiDocument.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/frontends/qt4/GuiDocument.cpp b/src/frontends/qt4/GuiDocument.cpp
index cf64849..60aee1c 100644
--- a/src/frontends/qt4/GuiDocument.cpp
+++ b/src/frontends/qt4/GuiDocument.cpp
@@ -453,6 +453,11 @@ PreambleModule::PreambleModule() : current_id_(0)
 	// This is not a memory leak. The object will be destroyed
 	// with this.
 	(void) new LaTeXHighlighter(preambleTE->document());
+	QFont font(guiApp->typewriterFontName());
+	font.setFixedPitch(true);
+	font.setStyleHint(QFont::TypeWriter);
+	preambleTE->setFont(font);
+	preambleTE->setWordWrapMode(QTextOption::NoWrap);
 	setFocusProxy(preambleTE);
 	connect(preambleTE, SIGNAL(textChanged()), this, SIGNAL(changed()));
 }
-- 
2.1.4

Re: Enhancement Suggestion: Preamble Fixed-width Font

[Pavel Sanda]

Joel Kulesza wrote:
> My suggestion is to change the default font of the Settings->Preamble text
> box to a fixed-width font because the content is effectively code.  This
> change should improve readability for those that make extensive use of the
> preamble.
> 
> Going a step further with the topic: would it also make sense to disable
> (or make optional) line-wrapping in the preamble dialog?
> 
> I would appreciate hearing your thoughts on this.

Seems like trivial and sensible fix, if anyone comes with patch it can make
it into 2.2.0/x.

Pavel

Re: Re: enhancement request: support biblatex

[Neal Becker]

José Matos wrote:

 On Monday 28 April 2014 08:13:49 Neal Becker wrote:
 https://bugzilla.redhat.com/show_bug.cgi?id=584063
 
 Seems fedora is not shipping biber, it is still an open bug
 
 Why don't you install the package from the copr repository pointed there?
 
 With some feedback it will possible to place this package in Fedora.
 
 FWIW I had/have a copr repository for lyx-2.1 before it was released.
 
 Regards,
Oh thanks!  I didn't know about biber in copr.

Re: Re: enhancement request: support biblatex

[Neal Becker]

José Matos wrote:

> On Monday 28 April 2014 08:13:49 Neal Becker wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=584063
>> 
>> Seems fedora is not shipping biber, it is still an open bug
> 
> Why don't you install the package from the copr repository pointed there?
> 
> With some feedback it will possible to place this package in Fedora.
> 
> FWIW I had/have a copr repository for lyx-2.1 before it was released.
> 
> Regards,
Oh thanks!  I didn't know about biber in copr.

Re: Re: enhancement request: support biblatex

[José Matos]

On Monday 28 April 2014 08:13:49 Neal Becker wrote:
 https://bugzilla.redhat.com/show_bug.cgi?id=584063
 
 Seems fedora is not shipping biber, it is still an open bug

Why don't you install the package from the copr repository pointed there?

With some feedback it will possible to place this package in Fedora.

FWIW I had/have a copr repository for lyx-2.1 before it was released.

Regards,
-- 
José Abílio

Re: Re: enhancement request: support biblatex

[José Matos]

On Monday 28 April 2014 08:13:49 Neal Becker wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=584063
> 
> Seems fedora is not shipping biber, it is still an open bug

Why don't you install the package from the copr repository pointed there?

With some feedback it will possible to place this package in Fedora.

FWIW I had/have a copr repository for lyx-2.1 before it was released.

Regards,
-- 
José Abílio

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com wrote:

 I have read that biblatex is the way of the future.  Unfortunately, I
 understand
 that lyx does not currently support biblatex.


Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
workarounds, all detailed in the corresponding wiki page:
http://wiki.lyx.org/BibTeX/Biblatex.

In short, you have to load biblatex and the bib files manually in the
preamble, and you have to enter a command in ERT in your text to instruct
LyX to print out the list of references. You are still able to enter
references through a dialog box as you would when using bibtex. In
practical terms, using biblatex in lyx is not much different from using
bibtex, at least if you use the standard styles and citing commands.
Having full support would be great, but the current setup is more than
usable.


Cheers,

Stefano



-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

stefano franchi wrote:

 On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com wrote:
 
 I have read that biblatex is the way of the future.  Unfortunately, I
 understand
 that lyx does not currently support biblatex.

 
 Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
 workarounds, all detailed in the corresponding wiki page:
 http://wiki.lyx.org/BibTeX/Biblatex.
 
 In short, you have to load biblatex and the bib files manually in the
 preamble, and you have to enter a command in ERT in your text to instruct
 LyX to print out the list of references. You are still able to enter
 references through a dialog box as you would when using bibtex. In
 practical terms, using biblatex in lyx is not much different from using
 bibtex, at least if you use the standard styles and citing commands.
 Having full support would be great, but the current setup is more than
 usable.
 
 
 Cheers,
 
 Stefano
 
 
 

Oh, thanks!

One note.  It seems biber is not supported at least on Fedora linux.  Fedora 
ships texlive 2013.  I can't seem to find any biber there, and from what 
messages I found on google, I think maybe it's not maintained?  I have used 
biblatex using bibtex backend instead of biber.

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker ndbeck...@gmail.com wrote:

 stefano franchi wrote:

  On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com
 wrote:
 
  I have read that biblatex is the way of the future.  Unfortunately, I
  understand
  that lyx does not currently support biblatex.
 
 
  Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
  workarounds, all detailed in the corresponding wiki page:
  http://wiki.lyx.org/BibTeX/Biblatex.
 
  In short, you have to load biblatex and the bib files manually in the
  preamble, and you have to enter a command in ERT in your text to instruct
  LyX to print out the list of references. You are still able to enter
  references through a dialog box as you would when using bibtex. In
  practical terms, using biblatex in lyx is not much different from using
  bibtex, at least if you use the standard styles and citing commands.
  Having full support would be great, but the current setup is more than
  usable.
 
 
  Cheers,
 
  Stefano
 
 
 

 Oh, thanks!

 One note.  It seems biber is not supported at least on Fedora linux.
  Fedora
 ships texlive 2013.  I can't seem to find any biber there, and from what
 messages I found on google, I think maybe it's not maintained?  I have used
 biblatex using bibtex backend instead of biber.


Biber is under active development, actually, and well maintained. I use the
version distributed with TexLive 2013, which is now frozen at 1.8 (TexLive
2013 is frozen, since the TexLive 2014 is about to come out). I don't know
how Fedora packages Texlive (I'm on Archlnux), perhaps it behaves like
Debian/Ubuntu and splits it into several packages? In hat case you may be
missing one of the extra packages.

Cheers,

Stefano


-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug


On Mon, Apr 28, 2014 at 8:07 AM, stefano franchi
stefano.fran...@gmail.comwrote:




 On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker ndbeck...@gmail.com wrote:

 stefano franchi wrote:

  On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker ndbeck...@gmail.com
 wrote:
 
  I have read that biblatex is the way of the future.  Unfortunately, I
  understand
  that lyx does not currently support biblatex.
 
 
  Lyx supports biblatex *partially*. You can use biblatex in lyx with a
 few
  workarounds, all detailed in the corresponding wiki page:
  http://wiki.lyx.org/BibTeX/Biblatex.
 
  In short, you have to load biblatex and the bib files manually in the
  preamble, and you have to enter a command in ERT in your text to
 instruct
  LyX to print out the list of references. You are still able to enter
  references through a dialog box as you would when using bibtex. In
  practical terms, using biblatex in lyx is not much different from using
  bibtex, at least if you use the standard styles and citing commands.
  Having full support would be great, but the current setup is more than
  usable.
 
 
  Cheers,
 
  Stefano
 
 
 

 Oh, thanks!

 One note.  It seems biber is not supported at least on Fedora linux.
  Fedora
 ships texlive 2013.  I can't seem to find any biber there, and from what
 messages I found on google, I think maybe it's not maintained?  I have
 used
 biblatex using bibtex backend instead of biber.


 Biber is under active development, actually, and well maintained. I use
 the version distributed with TexLive 2013, which is now frozen at 1.8
 (TexLive 2013 is frozen, since the TexLive 2014 is about to come out). I
 don't know how Fedora packages Texlive (I'm on Archlnux), perhaps it
 behaves like Debian/Ubuntu and splits it into several packages? In hat case
 you may be missing one of the extra packages.

 Cheers,

 Stefano


 --
 __
 Stefano Franchi
 Associate Research Professor
 Department of Hispanic Studies Ph:   +1 (979) 845-2125
 Texas AM University  Fax:  +1 (979) 845-6421
 College Station, Texas, USA

 stef...@tamu.edu
 http://stefano.cleinias.org

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker ndbeck...@gmail.com wrote:

 https://bugzilla.redhat.com/show_bug.cgi?id=584063

 Seems fedora is not shipping biber, it is still an open bug



You can always install it from their site, if you are willing to bypass
Fedora's package management system:
http://biblatex-biber.sourceforge.net/

Cheers,

S.

-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas AM University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Richard Heck]

On 04/28/2014 08:37 AM, stefano franchi wrote:




On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker ndbeck...@gmail.com 
mailto:ndbeck...@gmail.com wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug



You can always install it from their site, if you are willing to 
bypass Fedora's package management system:

http://biblatex-biber.sourceforge.net/


Recommended course would be to install it under /usr/local/. Then there 
is no potential conflict.


Richard

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker  wrote:

> I have read that biblatex is the way of the future.  Unfortunately, I
> understand
> that lyx does not currently support biblatex.
>

Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
workarounds, all detailed in the corresponding wiki page:
http://wiki.lyx.org/BibTeX/Biblatex.

In short, you have to load biblatex and the bib files manually in the
preamble, and you have to enter a command in ERT in your text to instruct
LyX to print out the list of references. You are still able to enter
references through a dialog box as you would when using bibtex. In
practical terms, using biblatex in lyx is not much different from using
bibtex, at least if you use the standard styles and citing commands.
Having full support would be great, but the current setup is more than
usable.


Cheers,

Stefano



-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

stefano franchi wrote:

> On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker  wrote:
> 
>> I have read that biblatex is the way of the future.  Unfortunately, I
>> understand
>> that lyx does not currently support biblatex.
>>
> 
> Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
> workarounds, all detailed in the corresponding wiki page:
> http://wiki.lyx.org/BibTeX/Biblatex.
> 
> In short, you have to load biblatex and the bib files manually in the
> preamble, and you have to enter a command in ERT in your text to instruct
> LyX to print out the list of references. You are still able to enter
> references through a dialog box as you would when using bibtex. In
> practical terms, using biblatex in lyx is not much different from using
> bibtex, at least if you use the standard styles and citing commands.
> Having full support would be great, but the current setup is more than
> usable.
> 
> 
> Cheers,
> 
> Stefano
> 
> 
> 

Oh, thanks!

One note.  It seems biber is not supported at least on Fedora linux.  Fedora 
ships texlive 2013.  I can't seem to find any biber there, and from what 
messages I found on google, I think maybe it's not maintained?  I have used 
biblatex using bibtex backend instead of biber.

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker  wrote:

> stefano franchi wrote:
>
> > On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker 
> wrote:
> >
> >> I have read that biblatex is the way of the future.  Unfortunately, I
> >> understand
> >> that lyx does not currently support biblatex.
> >>
> >
> > Lyx supports biblatex *partially*. You can use biblatex in lyx with a few
> > workarounds, all detailed in the corresponding wiki page:
> > http://wiki.lyx.org/BibTeX/Biblatex.
> >
> > In short, you have to load biblatex and the bib files manually in the
> > preamble, and you have to enter a command in ERT in your text to instruct
> > LyX to print out the list of references. You are still able to enter
> > references through a dialog box as you would when using bibtex. In
> > practical terms, using biblatex in lyx is not much different from using
> > bibtex, at least if you use the standard styles and citing commands.
> > Having full support would be great, but the current setup is more than
> > usable.
> >
> >
> > Cheers,
> >
> > Stefano
> >
> >
> >
>
> Oh, thanks!
>
> One note.  It seems biber is not supported at least on Fedora linux.
>  Fedora
> ships texlive 2013.  I can't seem to find any biber there, and from what
> messages I found on google, I think maybe it's not maintained?  I have used
> biblatex using bibtex backend instead of biber.
>
>
Biber is under active development, actually, and well maintained. I use the
version distributed with TexLive 2013, which is now frozen at 1.8 (TexLive
2013 is frozen, since the TexLive 2014 is about to come out). I don't know
how Fedora packages Texlive (I'm on Archlnux), perhaps it behaves like
Debian/Ubuntu and splits it into several packages? In hat case you may be
missing one of the extra packages.

Cheers,

Stefano


-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Neal Becker]

https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug


On Mon, Apr 28, 2014 at 8:07 AM, stefano franchi
wrote:

>
>
>
> On Mon, Apr 28, 2014 at 7:02 AM, Neal Becker  wrote:
>
>> stefano franchi wrote:
>>
>> > On Mon, Apr 28, 2014 at 6:29 AM, Neal Becker 
>> wrote:
>> >
>> >> I have read that biblatex is the way of the future.  Unfortunately, I
>> >> understand
>> >> that lyx does not currently support biblatex.
>> >>
>> >
>> > Lyx supports biblatex *partially*. You can use biblatex in lyx with a
>> few
>> > workarounds, all detailed in the corresponding wiki page:
>> > http://wiki.lyx.org/BibTeX/Biblatex.
>> >
>> > In short, you have to load biblatex and the bib files manually in the
>> > preamble, and you have to enter a command in ERT in your text to
>> instruct
>> > LyX to print out the list of references. You are still able to enter
>> > references through a dialog box as you would when using bibtex. In
>> > practical terms, using biblatex in lyx is not much different from using
>> > bibtex, at least if you use the standard styles and citing commands.
>> > Having full support would be great, but the current setup is more than
>> > usable.
>> >
>> >
>> > Cheers,
>> >
>> > Stefano
>> >
>> >
>> >
>>
>> Oh, thanks!
>>
>> One note.  It seems biber is not supported at least on Fedora linux.
>>  Fedora
>> ships texlive 2013.  I can't seem to find any biber there, and from what
>> messages I found on google, I think maybe it's not maintained?  I have
>> used
>> biblatex using bibtex backend instead of biber.
>>
>>
> Biber is under active development, actually, and well maintained. I use
> the version distributed with TexLive 2013, which is now frozen at 1.8
> (TexLive 2013 is frozen, since the TexLive 2014 is about to come out). I
> don't know how Fedora packages Texlive (I'm on Archlnux), perhaps it
> behaves like Debian/Ubuntu and splits it into several packages? In hat case
> you may be missing one of the extra packages.
>
> Cheers,
>
> Stefano
>
>
> --
> __
> Stefano Franchi
> Associate Research Professor
> Department of Hispanic Studies Ph:   +1 (979) 845-2125
> Texas A University  Fax:  +1 (979) 845-6421
> College Station, Texas, USA
>
> stef...@tamu.edu
> http://stefano.cleinias.org
>

Re: enhancement request: support biblatex

[stefano franchi]

On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker  wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=584063
>
> Seems fedora is not shipping biber, it is still an open bug
>
>

You can always install it from their site, if you are willing to bypass
Fedora's package management system:
http://biblatex-biber.sourceforge.net/

Cheers,

S.

-- 
__
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph:   +1 (979) 845-2125
Texas A University  Fax:  +1 (979) 845-6421
College Station, Texas, USA

stef...@tamu.edu
http://stefano.cleinias.org

Re: enhancement request: support biblatex

[Richard Heck]

On 04/28/2014 08:37 AM, stefano franchi wrote:




On Mon, Apr 28, 2014 at 7:13 AM, Neal Becker > wrote:


https://bugzilla.redhat.com/show_bug.cgi?id=584063

Seems fedora is not shipping biber, it is still an open bug



You can always install it from their site, if you are willing to 
bypass Fedora's package management system:

http://biblatex-biber.sourceforge.net/


Recommended course would be to install it under /usr/local/. Then there 
is no potential conflict.


Richard

Re: enhancement suggestion: include combine class

[Richard Heck]

On 08/26/2010 10:00 AM, Peter Gamalrevicz wrote:

Dear LyX-developers,

first off: thanks for a great piece of software. I have one 
suggestion: the combine class is very handy for having several 
documents in one, which is especially useful for collections of 
articles. The class can be found on CTAN: 
http://www.ctan.org/tex-archive/macros/latex/contrib/combine/


Getting this class into LyX myself is way beyond my abilities, so 
maybe there's a chance of officially including it?


This is an interesting idea, but not one I have time to implement right 
now. There is some work that would need to be done, mostly, to implement 
the \import command, as a variant of our existing include command. The 
reason this is not trivial is that we'd need to convince LyX actually to 
generate the *full* LaTeX for an \import'ed document, with preamble, 
etc, rather than just the LaTeX for an \include'd document. This is so 
the titlepage would be generated as normal, etc.


I'm not sure what other class options we might want to support and what 
to leave for inclusion in the manual preamble.


I'd suggest that you add an enhancement request to trac, and perhaps 
include the text of this email, as a pointer to what needs doing.


Richard

Re: enhancement suggestion: include combine class

[Richard Heck]

On 08/26/2010 10:00 AM, Peter Gamalrevicz wrote:

Dear LyX-developers,

first off: thanks for a great piece of software. I have one 
suggestion: the combine class is very handy for having several 
documents in one, which is especially useful for collections of 
articles. The class can be found on CTAN: 
http://www.ctan.org/tex-archive/macros/latex/contrib/combine/


Getting this class into LyX myself is way beyond my abilities, so 
maybe there's a chance of officially including it?


This is an interesting idea, but not one I have time to implement right 
now. There is some work that would need to be done, mostly, to implement 
the \import command, as a variant of our existing include command. The 
reason this is not trivial is that we'd need to convince LyX actually to 
generate the *full* LaTeX for an \import'ed document, with preamble, 
etc, rather than just the LaTeX for an \include'd document. This is so 
the titlepage would be generated as normal, etc.


I'm not sure what other class options we might want to support and what 
to leave for inclusion in the manual preamble.


I'd suggest that you add an enhancement request to trac, and perhaps 
include the text of this email, as a pointer to what needs doing.


Richard

Re: Enhancement bugs for 2.0

[Guenter Milde]

On 2010-04-01, Jean-Marc Lasgouttes wrote:
 Le 31/03/2010 13:07, Guenter Milde a écrit :

 I wonder if we could use utf-8 as default latex source encoding for most
 (all) languages if the locale is UTF-8.

 AFAIK, UTF8 support is too weak in LaTeX right now. 

While it is weak in LaTeX, LyX's own UTF8 support is fine and also kicks
in if the latex-source is in UTF-8.

In a modern system, it really does not make sense to write the source in
iso8859-15, say, if the locale is UTF-8.

 And people should be able to chose the encoding they want.

Of course they should. However, this is not prevented by using a
different *default*.

Günter

Re: Enhancement bugs for 2.0

[Guenter Milde]

On 2010-04-01, Jean-Marc Lasgouttes wrote:
> Le 31/03/2010 13:07, Guenter Milde a écrit :

>> I wonder if we could use utf-8 as default latex source encoding for most
>> (all) languages if the locale is UTF-8.

> AFAIK, UTF8 support is too weak in LaTeX right now. 

While it is weak in LaTeX, LyX's own UTF8 support is fine and also kicks
in if the latex-source is in UTF-8.

In a modern system, it really does not make sense to write the source in
iso8859-15, say, if the locale is UTF-8.

> And people should be able to chose the encoding they want.

Of course they should. However, this is not prevented by using a
different *default*.

Günter

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 31/03/2010 13:07, Guenter Milde a écrit :

On 2010-03-30, Jean-Marc Lasgouttes wrote:

Pavel Sandasa...@lyx.org  writes:

last call for 2.0 feature requests we have reported.



- currently, Sweave reads the files in the encoding of the current
   locale. This fails as soon as the locale is UTF-8 and the document is
   8bit (because the characters themselves are ruined). We need to find a
   way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I wonder if we could use utf-8 as default latex source encoding for most
(all) languages if the locale is UTF-8.


AFAIK, UTF8 support is too weak in LaTeX right now. And people should be 
able to chose the encoding they want.


Note that a good workaround for this bug is to use ascii encoding.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 30/03/2010 14:01, Jean-Marc Lasgouttes a écrit :

- pass the noae option to Sweave to make sure it does not ruin our
   font settings.
http://www.lyx.org/trac/ticket/6624


This one is fixed now.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 31/03/2010 13:07, Guenter Milde a écrit :

On 2010-03-30, Jean-Marc Lasgouttes wrote:

Pavel Sanda  writes:

last call for 2.0 feature requests we have reported.



- currently, Sweave reads the files in the encoding of the current
   locale. This fails as soon as the locale is UTF-8 and the document is
   8bit (because the characters themselves are ruined). We need to find a
   way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I wonder if we could use utf-8 as default latex source encoding for most
(all) languages if the locale is UTF-8.


AFAIK, UTF8 support is too weak in LaTeX right now. And people should be 
able to chose the encoding they want.


Note that a good workaround for this bug is to use ascii encoding.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Le 30/03/2010 14:01, Jean-Marc Lasgouttes a écrit :

- pass the "noae" option to Sweave to make sure it does not ruin our
   font settings.
http://www.lyx.org/trac/ticket/6624


This one is fixed now.

JMarc

Re: Enhancement bugs for 2.0

[Guenter Milde]

On 2010-03-30, Jean-Marc Lasgouttes wrote:
 Pavel Sanda sa...@lyx.org writes:
 last call for 2.0 feature requests we have reported.

 - currently, Sweave reads the files in the encoding of the current
   locale. This fails as soon as the locale is UTF-8 and the document is
   8bit (because the characters themselves are ruined). We need to find a
   way to pass the encoding to the function.
 http://www.lyx.org/trac/ticket/6625

I wonder if we could use utf-8 as default latex source encoding for most
(all) languages if the locale is UTF-8.

Günter

Re: Enhancement bugs for 2.0

[Guenter Milde]

On 2010-03-30, Jean-Marc Lasgouttes wrote:
> Pavel Sanda  writes:
>> last call for 2.0 feature requests we have reported.

> - currently, Sweave reads the files in the encoding of the current
>   locale. This fails as soon as the locale is UTF-8 and the document is
>   8bit (because the characters themselves are ruined). We need to find a
>   way to pass the encoding to the function.
> http://www.lyx.org/trac/ticket/6625

I wonder if we could use utf-8 as default latex source encoding for most
(all) languages if the locale is UTF-8.

Günter

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Pavel Sanda sa...@lyx.org writes:
 last call for 2.0 feature requests we have reported.

I am really late with this, but I am a bit overwhelmed by work and baby,


 * http://www.lyx.org/trac/ticket/4072
 Default document settings in .layout files


Personnally, I am against this feature as it is presented.
The layout file can already set the latex defaults.

 * http://www.lyx.org/trac/ticket/4286
 Improved statistics (SWeave) support

 JMarc?  btw i'm generally lost whats the sweave status.
 are there some issues you still plan to do
 or just documentation is missing now?

I marked the bug as fixedintrunk and opened new ones for each separate
problem. The milestone is 2.0.0 for now, but we have to discuss this.

Here is what is not yet done in sweave support:

- find a way to read local files. If I have a 
   read.table(foo.txt)
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
http://www.lyx.org/trac/ticket/6623

- pass the noae option to Sweave to make sure it does not ruin our
  font settings.
http://www.lyx.org/trac/ticket/6624

- currently, Sweave reads the files in the encoding of the current
  locale. This fails as soon as the locale is UTF-8 and the document is
  8bit (because the characters themselves are ruined). We need to find a
  way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I have also work that I did not finish to allow creating insets for
verbatim contents (like ERT, but not hardcoded). I would have liked to
finish this before 2.0, but my time is very scarce.

JMarc

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 I marked the bug as fixedintrunk and opened new ones for each separate
 problem. The milestone is 2.0.0 for now, but we have to discuss this.

something to be done with these two?
http://www.lyx.org/trac/ticket/48
http://www.lyx.org/trac/ticket/6137

 I have also work that I did not finish to allow creating insets for
 verbatim contents (like ERT, but not hardcoded). I would have liked to
 finish this before 2.0, but my time is very scarce.

yes.
pavel

Re: Enhancement bugs for 2.0

[Gregor GORJANC]

Hi,

Please read bellow.

On 30 March 2010 14:01, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
...
 - find a way to read local files. If I have a
   read.table(foo.txt)
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
 http://www.lyx.org/trac/ticket/6623

I still think that the way I described at [1] is the best it could be done.

 [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

gg

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

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

 Jean-Marc Lasgouttes wrote:
 I marked the bug as fixedintrunk and opened new ones for each separate
 problem. The milestone is 2.0.0 for now, but we have to discuss this.

 something to be done with these two?
 http://www.lyx.org/trac/ticket/48

This one I do not know. But I would be surprised to see it magically
fixed. This is probably not very difficult, though.

 http://www.lyx.org/trac/ticket/6137

I have no clear idea about this, except that usinf listing is a hack,
probably only to obtain something simpler to use. If I ever finish the
work below, it will become simpler.

 I have also work that I did not finish to allow creating insets for
 verbatim contents (like ERT, but not hardcoded). I would have liked to
 finish this before 2.0, but my time is very scarce.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Gregor GORJANC gregor.gorj...@bfro.uni-lj.si writes:
 On 30 March 2010 14:01, Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
 ...
 - find a way to read local files. If I have a
   read.table(foo.txt)
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
 http://www.lyx.org/trac/ticket/6623

 I still think that the way I described at [1] is the best it could be done.

  [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

Yes, it looks indeed the best thing to do. Could you add the description
and your tests in the relevant bug? I am not ignoring you, just running
out of time :) In this case, it is always the task that need more
thinking that get delayed.

JMarc

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
  JMarc?  btw i'm generally lost whats the sweave status.
  are there some issues you still plan to do
  or just documentation is missing now?

one more thing - adding entry to newinlyx20 wiki section, so documentation
is not forgotten. i would add it myself if i had a clue what was exactly
done ;)

pavel

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Pavel Sanda  writes:
> last call for 2.0 feature requests we have reported.

I am really late with this, but I am a bit overwhelmed by work and baby,

>
> * http://www.lyx.org/trac/ticket/4072
> Default document settings in .layout files
>

Personnally, I am against this feature as it is presented.
The layout file can already set the latex defaults.

> * http://www.lyx.org/trac/ticket/4286
> Improved statistics (SWeave) support
>
> JMarc?  btw i'm generally lost whats the sweave status.
> are there some issues you still plan to do
> or just documentation is missing now?

I marked the bug as fixedintrunk and opened new ones for each separate
problem. The milestone is 2.0.0 for now, but we have to discuss this.

Here is what is not yet done in sweave support:

- find a way to read local files. If I have a 
   read.table("foo.txt")
  in the file, it will fail because R is ran from the tmp dir. Since
   there is no PATH-like support in R, I do not know how to solve the
   problem. I should try to contact R developers about this
http://www.lyx.org/trac/ticket/6623

- pass the "noae" option to Sweave to make sure it does not ruin our
  font settings.
http://www.lyx.org/trac/ticket/6624

- currently, Sweave reads the files in the encoding of the current
  locale. This fails as soon as the locale is UTF-8 and the document is
  8bit (because the characters themselves are ruined). We need to find a
  way to pass the encoding to the function.
http://www.lyx.org/trac/ticket/6625


I have also work that I did not finish to allow creating insets for
verbatim contents (like ERT, but not hardcoded). I would have liked to
finish this before 2.0, but my time is very scarce.

JMarc

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> I marked the bug as fixedintrunk and opened new ones for each separate
> problem. The milestone is 2.0.0 for now, but we have to discuss this.

something to be done with these two?
http://www.lyx.org/trac/ticket/48
http://www.lyx.org/trac/ticket/6137

> I have also work that I did not finish to allow creating insets for
> verbatim contents (like ERT, but not hardcoded). I would have liked to
> finish this before 2.0, but my time is very scarce.

yes.
pavel

Re: Enhancement bugs for 2.0

[Gregor GORJANC]

Hi,

Please read bellow.

On 30 March 2010 14:01, Jean-Marc Lasgouttes  wrote:
...
> - find a way to read local files. If I have a
>   read.table("foo.txt")
>  in the file, it will fail because R is ran from the tmp dir. Since
>   there is no PATH-like support in R, I do not know how to solve the
>   problem. I should try to contact R developers about this
> http://www.lyx.org/trac/ticket/6623

I still think that the way I described at [1] is the best it could be done.

 [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

gg

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Pavel Sanda  writes:

> Jean-Marc Lasgouttes wrote:
>> I marked the bug as fixedintrunk and opened new ones for each separate
>> problem. The milestone is 2.0.0 for now, but we have to discuss this.
>
> something to be done with these two?
> http://www.lyx.org/trac/ticket/48

This one I do not know. But I would be surprised to see it magically
fixed. This is probably not very difficult, though.

> http://www.lyx.org/trac/ticket/6137

I have no clear idea about this, except that usinf listing is a hack,
probably only to obtain something simpler to use. If I ever finish the
work below, it will become simpler.

>> I have also work that I did not finish to allow creating insets for
>> verbatim contents (like ERT, but not hardcoded). I would have liked to
>> finish this before 2.0, but my time is very scarce.

JMarc

Re: Enhancement bugs for 2.0

[Jean-Marc Lasgouttes]

Gregor GORJANC  writes:
> On 30 March 2010 14:01, Jean-Marc Lasgouttes  wrote:
> ...
>> - find a way to read local files. If I have a
>>   read.table("foo.txt")
>>  in the file, it will fail because R is ran from the tmp dir. Since
>>   there is no PATH-like support in R, I do not know how to solve the
>>   problem. I should try to contact R developers about this
>> http://www.lyx.org/trac/ticket/6623
>
> I still think that the way I described at [1] is the best it could be done.
>
>  [1]http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152966.html

Yes, it looks indeed the best thing to do. Could you add the description
and your tests in the relevant bug? I am not ignoring you, just running
out of time :) In this case, it is always the task that need more
thinking that get delayed.

JMarc

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> > JMarc?  btw i'm generally lost whats the sweave status.
> > are there some issues you still plan to do
> > or just documentation is missing now?

one more thing - adding entry to newinlyx20 wiki section, so documentation
is not forgotten. i would add it myself if i had a clue what was exactly
done ;)

pavel

Re: Enhancement bugs for 2.0

[Uwe Stöhr]

 * http://www.lyx.org/trac/ticket/3865
 implement to define color definitions in document settings

 i guess c. Uwe?

 This issue is very complicated because we have to store all colors that the 
user might already
 have defined previously in a document. For stability reasons of 2.0, I would 
strongly recommend
 to postpone this to 2.1.

This statement was wrong because I mixed
http://www.lyx.org/trac/ticket/3865
with
http://www.lyx.org/trac/ticket/1841

I fix for http://www.lyx.org/trac/ticket/3865 is easy. The fix for 
http://www.lyx.org/trac/ticket/3865 too.

The only question I have is where to place the button to select the color for 
notes in the UI.
Any idea?

regards Uwe

Re: Enhancement bugs for 2.0

[Uwe Stöhr]

>> * http://www.lyx.org/trac/ticket/3865
>> implement to define color definitions in document settings
>>
>> i guess c. Uwe?
>
> This issue is very complicated because we have to store all colors that the 
user might already
> have defined previously in a document. For stability reasons of 2.0, I would 
strongly recommend
> to postpone this to 2.1.

This statement was wrong because I mixed
http://www.lyx.org/trac/ticket/3865
with
http://www.lyx.org/trac/ticket/1841

I fix for http://www.lyx.org/trac/ticket/3865 is easy. The fix for 
http://www.lyx.org/trac/ticket/3865 too.

The only question I have is where to place the button to select the color for 
notes in the UI.
Any idea?

regards Uwe

Re: Enhancement bugs for 2.0

[Tommaso Cucinotta]

Vincent van Ravesteijn - TNW wrote:

to me it was fixed by new search pane. Vincent however have idea
to convert the current simple search dialog into search bar. opinions?
anybody wants to work on it? otherwise c.



I've already done some work on it. I really want to have this in 2.0.0,
so we have a polished brand new search and replace functionality.

If not before 2.0.0, it must be done as soon as possible, so never c).
  
Leuven recently proposed a rework of the current simple-search dialog. 
Are we going to have 3 search facilities ?

- simple-search dialog
- advanced-search pane
- simple-search bar ?

Or, are you thinking to just replace the simple-search dialog with the bar ?

   T.

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Tommaso Cucinotta wrote:
 Or, are you thinking to just replace the simple-search dialog with the bar 
 ?

yes that was the proposal.
pavel

Re: Enhancement bugs for 2.0

[Vincent van Ravesteijn]

Leuven recently proposed a rework of the current simple-search dialog. 
Are we going to have 3 search facilities ?

- simple-search dialog
- advanced-search pane
- simple-search bar ?


I'm not sure I remember what Edwin proposed.



Or, are you thinking to just replace the simple-search dialog with the 
bar ?

Yes.

Vincent

Re: Enhancement bugs for 2.0

[Tommaso Cucinotta]

Vincent van Ravesteijn - TNW wrote:

to me it was fixed by new search pane. Vincent however have idea
to convert the current simple search dialog into search bar. opinions?
anybody wants to work on it? otherwise c.



I've already done some work on it. I really want to have this in 2.0.0,
so we have a polished brand new search and replace functionality.

If not before 2.0.0, it must be done as soon as possible, so never c).
  
Leuven recently proposed a rework of the current simple-search dialog. 
Are we going to have 3 search facilities ?

- simple-search dialog
- advanced-search pane
- simple-search bar ?

Or, are you thinking to just replace the simple-search dialog with the bar ?

   T.

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Tommaso Cucinotta wrote:
> Or, are you thinking to just replace the simple-search dialog with the bar 
> ?

yes that was the proposal.
pavel

Re: Enhancement bugs for 2.0

[Vincent van Ravesteijn]

Leuven recently proposed a rework of the current simple-search dialog. 
Are we going to have 3 search facilities ?

- simple-search dialog
- advanced-search pane
- simple-search bar ?


I'm not sure I remember what Edwin proposed.



Or, are you thinking to just replace the simple-search dialog with the 
bar ?

Yes.

Vincent

Re: Enhancement bugs for 2.0

[rgheck]

On 03/25/2010 09:52 AM, Pavel Sanda wrote:

hi,

last call for 2.0 feature requests we have reported.

i'm going to cleanup bugzilla from enhacenments we wont offer
in 2.0. i have listed those which are not clear and we have to
decide which action should we take on each of the requests.
a) do it for 2.0
b) postpone for 2.1 in case you want to work on it later
or if you think its really needed
c) kill milestone completely

please take 10 mins to go through the whole mail and help me to
clean things out by signing a/b/c.

   

We need 2.0.x and 2.1 milestones now then.


* http://www.lyx.org/trac/ticket/1714
LyX doesn't allow environments with options
- actually support for environments (and commands) with
multiple mandatory arguments,

JMarc, Juergen?

   
I'm interested in this one, but I don't think we will make it for 2.0 
unless someone has code waiting. And in that case, it has to be 
postponed until 2.1.



* http://www.lyx.org/trac/ticket/2625
add support for textsuperscript and textsubscript

Uwe, anybodye else?

   
This could be done with a simple module defining a custom inset. Easy. 
Maybe it should just be added to logicalmkup.



* http://www.lyx.org/trac/ticket/3221
\nameref and \autoref support in cross-references

Uwe, Richard?

   
Leave this one. I'm working on some cross-ref stuff and may be able to 
do something here.



* http://www.lyx.org/trac/ticket/3452
Need LayoutGroup Properties for Various Reasons

we agreed its not for 2.0, so the question is b/c.
Vincent,Richard,Juergen?

   

Postpone.


* http://www.lyx.org/trac/ticket/4578
Easy way to convert footnote to marginal note

We have to find the (sequence of) command(s) that
turns a footnote into a marginal note. (via inset-forall)
If we have no idea then c?

   

This could be left for the 2.0.x series. It isn't a format change.


* http://www.lyx.org/trac/ticket/4595
content of label inset is LaTeX code

Richard?

   
This actually should be pretty easy, as described in the bug report, I 
don't know I'll have time to get to it. Still, maybe don't postpone yet.



* http://www.lyx.org/trac/ticket/4072
Default document settings in .layout files

Richard?

   

Postpone. I have too much on my plate already.


* http://www.lyx.org/trac/ticket/6455
Multiple index UI polishment
- index inset should display something besides just  Idx
- InsertToc menu should probably say Index: Names rather  than just Names.

Juegen, Richard?

   
We'll fix this. Note that it is OK for the 2.0.x series, too, even if we 
do not get to it.


rh

RE: Enhancement bugs for 2.0

[Vincent van Ravesteijn - TNW]

last call for 2.0 feature requests we have reported.

i'm going to cleanup bugzilla from enhacenments we wont offer in 2.0. i
have listed those which are not clear and we have to decide which action
should we take on each of the requests.
a) do it for 2.0
b) postpone for 2.1 in case you want to work on it later
   or if you think its really needed
c) kill milestone completely

please take 10 mins to go through the whole mail and help me to clean
things out by signing a/b/c.


* http://www.lyx.org/trac/ticket/2591
text inset for tipa

Juergen, Uwe?


I don't understand this completely. Anyway, this was slightly related to
the insetPreview, which I should be able to move into trunk pretty soon.


* http://www.lyx.org/trac/ticket/2625
convert the search dialog to a search bar

to me it was fixed by new search pane. Vincent however have idea
to convert the current simple search dialog into search bar. opinions?
anybody wants to work on it? otherwise c.

I've already done some work on it. I really want to have this in 2.0.0,
so we have a polished brand new search and replace functionality.

If not before 2.0.0, it must be done as soon as possible, so never c).

Anyway, sign me up for this one.


* http://www.lyx.org/trac/ticket/3452
Need LayoutGroup Properties for Various Reasons

we agreed its not for 2.0, so he question is b/c.
Vincent,Richard,Juergen?


This is pretty much related to the first one (bug 1714).


* http://www.lyx.org/trac/ticket/3865
implement to define color definitions in document settings

i guess c. Uwe?


This should be done as soon as possible.

Why do you want to remove all milestones almost ?

* http://www.lyx.org/trac/ticket/5603
multiple text selections the same time

it seems except Uwe there is no interest and looks also quite tricky
to do, perhaps c.

I guess it's difficult to do. We probably need an anchor-cursor
stack/vector in stead of a single one.

It would also be useful for the search facility. To highlight all found
occurences.

I think this is interesting if I have spare time :S



I've no opinion/interest about the other ones.

Vincent

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Richard Heck wrote:
 We need 2.0.x and 2.1 milestones now then.

i have already asked about this.
pavel

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
 * http://www.lyx.org/trac/ticket/3865
 implement to define color definitions in document settings
 
 i guess c. Uwe?
 
 
 This should be done as soon as possible.
 
 Why do you want to remove all milestones almost ?

this list was little bit biased because i havent wrote about
those which i consider to have milestone. secondly indicating
c is more probably to trigger some reaction ;)

pavel

Re: Enhancement bugs for 2.0

[Uwe Stöhr]

 * http://www.lyx.org/trac/ticket/2591
 text inset for tipa

 Juergen, Uwe?

I won't have time to work on that for 2.0.

 * http://www.lyx.org/trac/ticket/2605
 Add checkbox for automatic equation, figure and table
 numbering corresponding to section number

 no activity for 3 years. c?

I will have a look if I can provide a patch. It shouldn't be too 
complicated to achieve this and this topic appears very often on the 
lyx-users list - therefore priority a.


 * http://www.lyx.org/trac/ticket/2625
 add support for textsuperscript and textsubscript

 Uwe, anybodye else?

I have no time for this before 2.0.

 * http://www.lyx.org/trac/ticket/3221
 \nameref and \autoref support in cross-references

 Uwe, Richard?

Not me, but I can help Richard with the hyperref handling and testing.

 * http://www.lyx.org/trac/ticket/3865
 implement to define color definitions in document settings

 i guess c. Uwe?

This issue is very complicated because we have to store all colors that 
the user might already have defined previously in a document. For 
stability reasons of 2.0, I would strongly recommend to postpone this to 
2.1.


 * http://www.lyx.org/trac/ticket/3881
 support for the libertines font families
 * http://www.lyx.org/trac/ticket/4332
 support for the TeX Gyre fonts

 anybody?

Jürgen wanted to have some font code cleanup before this can go in. 
Jürgen, what's the status?


 * http://www.lyx.org/trac/ticket/5077
 ability to customize line thickness in the box dialog

 anybody touched this. c?

That's still on my todo list, but I have to postpone this to 2.1 due to 
lack of time.


 * http://www.lyx.org/trac/ticket/5603
 multiple text selections the same time

 it seems except Uwe there is no interest and
 looks also quite tricky to do, perhaps c.

It is tricky - postponing, but LyX should nevertheless someday support 
this as all other text editors support this.


regards Uwe

Re: Enhancement bugs for 2.0

[Jürgen Spitzmüller]

Pavel Sanda wrote:
 * http://www.lyx.org/trac/ticket/1714
 LyX doesn't allow environments with options
 - actually support for environments (and commands) with
 multiple mandatory arguments,
 
 JMarc, Juergen?

I have started to implement that some time ago, but I got no time to finish 
it, and that tree is now completely broken. I'm afraid I won't have time to 
return to this in the near future
(but it would be a crucial enhancement).
 
 * http://www.lyx.org/trac/ticket/2591
 text inset for tipa
 
 Juergen, Uwe?

This requires inset preview. If we have a Preview [0|1] tag for 
InsetLayout, this can be implemented within 5 minutes.
 
 * http://www.lyx.org/trac/ticket/2605
 Add checkbox for automatic equation, figure and table
 numbering corresponding to section number
 
 no activity for 3 years. c?

Not very pressing, since we have modules for this now. I generally vote for 
cleaning up the modules and to get proper GUI for some of the features 
instead. But this can wait.

 * http://www.lyx.org/trac/ticket/2625
 add support for textsuperscript and textsubscript
 
 Uwe, anybodye else?

Again, this requires either instant preview and/or an inset that shows up as 
proper index. 

 * http://www.lyx.org/trac/ticket/3881
 support for the libertines font families
 * http://www.lyx.org/trac/ticket/4332
 support for the TeX Gyre fonts
 
 anybody?

I would prefer to add a generic font support (via config file) before we add 
support for new fonts. But again, no 2.0 stuff.

 * http://www.lyx.org/trac/ticket/5078
 Add pagebreak option to all box decoration types
 
 anybody?

Not me.

 * http://www.lyx.org/trac/ticket/6455
 Multiple index UI polishment
 - index inset should display something besides just  Idx
 - InsertToc menu should probably say Index: Names rather  than just
 Names.
 
 Juegen, Richard?

I don't see a quick way to fix these. And I think it's not crucial (for 
2.0).

 ufff... pavel

Thanks,
Jürgen

RE: Enhancement bugs for 2.0

[Charles de Miramon]

Vincent van Ravesteijn - TNW wrote:

* http://www.lyx.org/trac/ticket/2625
convert the search dialog to a search bar

to me it was fixed by new search pane. Vincent however have idea
to convert the current simple search dialog into search bar. opinions?
anybody wants to work on it? otherwise c.
 
 I've already done some work on it. I really want to have this in 2.0.0,
 so we have a polished brand new search and replace functionality.
 
 If not before 2.0.0, it must be done as soon as possible, so never c).
 
 Anyway, sign me up for this one.
 

I have just tried the svn trunk version and the new searchreplace. It is 
great and I have have been longing this feature for years. Thank you Tommaso 
and the others.

But do we really need two searchreplace items in the menu ? 

I have argued in the past and I still believe that LyX menus are suffering 
from Emacs-Disease and there are too many items. LyX should not be 
intimidating for new users and shows its power step by step.   

Would it not be better to have one searchreplace dialog and a button to 
toggle between simple mode and advanced mode.

Today the advanced mode pane design is different than the simple one in term 
of place of the find button, replace button, replace all button, locations 
of the checkboxes. 

Usability wise, it is not optimal.

Cheers,
Charles

RE: Enhancement bugs for 2.0

[Vincent van Ravesteijn - TNW]

Would it not be better to have one searchreplace dialog and a
button to toggle between simple mode and advanced mode.

The simple search will be a toolbar if it's up to me.

Today the advanced mode pane design is different than the simple one in
term of place of the find button, replace button, replace all button,
locations
of the checkboxes. 

Usability wise, it is not optimal.

Did you update today ? I think they are now exactly the same.

Vincent

RE: Enhancement bugs for 2.0

[Charles de Miramon]

Vincent van Ravesteijn - TNW wrote:

 
 Did you update today ? I think they are now exactly the same.
 

Thank you. It is much better. Still, I would go further and get rid of the 
advanced tab:

- At the top of the pane I would put the scope as a combo box
- Then a smaller Find TextEdit
- Then the Regular Expression combo
- Then on the left the Case Sensitive, Whole words only, Search backwards, 
Ignore Format checkboxes 
- On the right ; Search Next button

- A smaller Replace TextEdit
- Preserve first case on replace checkbox on the left (I don't really 
understand the option, should it not be 'preserve original formatting when 
replacing') 
- Replace
- Replace all

- I think there is a need for a reset button to erase everything and take 
away any formatting in the Search textedit

Would it also be possible that when you check 'Ignore format' any formatting 
in the Search TextEdit is suppressed ?

Nitpicks :
- F3 shortkey does not work in the advanced searchreplace
- Some shortkeys are different in the quick search and the advanced one


Cheers,
Charles

Re: Enhancement bugs for 2.0

[rgheck]

On 03/25/2010 02:16 PM, Jürgen Spitzmüller wrote:



* http://www.lyx.org/trac/ticket/6455
Multiple index UI polishment
- index inset should display something besides just  Idx
- InsertToc menu should probably say Index: Names rather  than just
Names.

Juegen, Richard?
 

I don't see a quick way to fix these. And I think it's not crucial (for
2.0).

   


The first, about display, I think can be fixed pretty easily, and I'll 
try to do that. The issue with the TOC is much more complex, since we 
only have one Index TOC at the moment. I.e., the TOC doesn't know about 
multiple indexes.


rh

Re: Enhancement bugs for 2.0

[rgheck]

On 03/25/2010 09:52 AM, Pavel Sanda wrote:

hi,

last call for 2.0 feature requests we have reported.

i'm going to cleanup bugzilla from enhacenments we wont offer
in 2.0. i have listed those which are not clear and we have to
decide which action should we take on each of the requests.
a) do it for 2.0
b) postpone for 2.1 in case you want to work on it later
or if you think its really needed
c) kill milestone completely

please take 10 mins to go through the whole mail and help me to
clean things out by signing a/b/c.

   

We need 2.0.x and 2.1 milestones now then.


* http://www.lyx.org/trac/ticket/1714
LyX doesn't allow environments with options
- actually support for environments (and commands) with
multiple mandatory arguments,

JMarc, Juergen?

   
I'm interested in this one, but I don't think we will make it for 2.0 
unless someone has code waiting. And in that case, it has to be 
postponed until 2.1.



* http://www.lyx.org/trac/ticket/2625
add support for textsuperscript and textsubscript

Uwe, anybodye else?

   
This could be done with a simple module defining a custom inset. Easy. 
Maybe it should just be added to logicalmkup.



* http://www.lyx.org/trac/ticket/3221
\nameref and \autoref support in cross-references

Uwe, Richard?

   
Leave this one. I'm working on some cross-ref stuff and may be able to 
do something here.



* http://www.lyx.org/trac/ticket/3452
Need LayoutGroup Properties for Various Reasons

we agreed its not for 2.0, so the question is b/c.
Vincent,Richard,Juergen?

   

Postpone.


* http://www.lyx.org/trac/ticket/4578
Easy way to convert footnote to marginal note

We have to find the (sequence of) command(s) that
turns a footnote into a marginal note. (via inset-forall)
If we have no idea then c?

   

This could be left for the 2.0.x series. It isn't a format change.


* http://www.lyx.org/trac/ticket/4595
content of label inset is LaTeX code

Richard?

   
This actually should be pretty easy, as described in the bug report, I 
don't know I'll have time to get to it. Still, maybe don't postpone yet.



* http://www.lyx.org/trac/ticket/4072
Default document settings in .layout files

Richard?

   

Postpone. I have too much on my plate already.


* http://www.lyx.org/trac/ticket/6455
Multiple index UI polishment
- index inset should display something besides just  "Idx"
- Insert>Toc menu should probably say "Index: Names" rather  than just "Names".

Juegen, Richard?

   
We'll fix this. Note that it is OK for the 2.0.x series, too, even if we 
do not get to it.


rh

RE: Enhancement bugs for 2.0

[Vincent van Ravesteijn - TNW]

last call for 2.0 feature requests we have reported.

i'm going to cleanup bugzilla from enhacenments we wont offer in 2.0. i
have listed those which are not clear and we have to decide which action
should we take on each of the requests.
a) do it for 2.0
b) postpone for 2.1 in case you want to work on it later
   or if you think its really needed
c) kill milestone completely

please take 10 mins to go through the whole mail and help me to clean
things out by signing a/b/c.


>* http://www.lyx.org/trac/ticket/2591
>text inset for tipa
>
>Juergen, Uwe?
>

I don't understand this completely. Anyway, this was slightly related to
the insetPreview, which I should be able to move into trunk pretty soon.


>* http://www.lyx.org/trac/ticket/2625
>convert the search dialog to a search bar
>
>to me it was fixed by new search pane. Vincent however have idea
>to convert the current simple search dialog into search bar. opinions?
>anybody wants to work on it? otherwise c.

I've already done some work on it. I really want to have this in 2.0.0,
so we have a polished brand new search and replace functionality.

If not before 2.0.0, it must be done as soon as possible, so never c).

Anyway, sign me up for this one.


>* http://www.lyx.org/trac/ticket/3452
>Need LayoutGroup Properties for Various Reasons
>
>we agreed its not for 2.0, so he question is b/c.
>Vincent,Richard,Juergen?
>

This is pretty much related to the first one (bug 1714).


>* http://www.lyx.org/trac/ticket/3865
>implement to define color definitions in document settings
>
>i guess c. Uwe?
>

This should be done as soon as possible.

Why do you want to remove all milestones almost ?

>* http://www.lyx.org/trac/ticket/5603
>multiple text selections the same time
>
>it seems except Uwe there is no interest and looks also quite tricky
>to do, perhaps c.

I guess it's difficult to do. We probably need an anchor-cursor
stack/vector in stead of a single one.

It would also be useful for the search facility. To highlight all found
occurences.

I think this is interesting if I have spare time :S



I've no opinion/interest about the other ones.

Vincent

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Richard Heck wrote:
> We need 2.0.x and 2.1 milestones now then.

i have already asked about this.
pavel

Re: Enhancement bugs for 2.0

[Pavel Sanda]

Vincent van Ravesteijn - TNW wrote:
> >* http://www.lyx.org/trac/ticket/3865
> >implement to define color definitions in document settings
> >
> >i guess c. Uwe?
> >
> 
> This should be done as soon as possible.
> 
> Why do you want to remove all milestones almost ?

this list was little bit biased because i havent wrote about
those which i consider to have milestone. secondly indicating
c is more probably to trigger some reaction ;)

pavel

Re: Enhancement bugs for 2.0

[Uwe Stöhr]

> * http://www.lyx.org/trac/ticket/2591
> text inset for tipa
>
> Juergen, Uwe?

I won't have time to work on that for 2.0.

> * http://www.lyx.org/trac/ticket/2605
> Add checkbox for automatic equation, figure and table
> numbering corresponding to section number
>
> no activity for 3 years. c?

I will have a look if I can provide a patch. It shouldn't be too 
complicated to achieve this and this topic appears very often on the 
lyx-users list - therefore priority a.


> * http://www.lyx.org/trac/ticket/2625
> add support for textsuperscript and textsubscript
>
> Uwe, anybodye else?

I have no time for this before 2.0.

> * http://www.lyx.org/trac/ticket/3221
> \nameref and \autoref support in cross-references
>
> Uwe, Richard?

Not me, but I can help Richard with the hyperref handling and testing.

> * http://www.lyx.org/trac/ticket/3865
> implement to define color definitions in document settings
>
> i guess c. Uwe?

This issue is very complicated because we have to store all colors that 
the user might already have defined previously in a document. For 
stability reasons of 2.0, I would strongly recommend to postpone this to 
2.1.


> * http://www.lyx.org/trac/ticket/3881
> support for the libertines font families
> * http://www.lyx.org/trac/ticket/4332
> support for the TeX Gyre fonts
>
> anybody?

Jürgen wanted to have some font code cleanup before this can go in. 
Jürgen, what's the status?


> * http://www.lyx.org/trac/ticket/5077
> ability to customize line thickness in the box dialog
>
> anybody touched this. c?

That's still on my todo list, but I have to postpone this to 2.1 due to 
lack of time.


> * http://www.lyx.org/trac/ticket/5603
> multiple text selections the same time
>
> it seems except Uwe there is no interest and
> looks also quite tricky to do, perhaps c.

It is tricky -> postponing, but LyX should nevertheless someday support 
this as all other text editors support this.


regards Uwe

Re: Enhancement bugs for 2.0

[Jürgen Spitzmüller]

Pavel Sanda wrote:
> * http://www.lyx.org/trac/ticket/1714
> LyX doesn't allow environments with options
> - actually support for environments (and commands) with
> multiple mandatory arguments,
> 
> JMarc, Juergen?

I have started to implement that some time ago, but I got no time to finish 
it, and that tree is now completely broken. I'm afraid I won't have time to 
return to this in the near future
(but it would be a crucial enhancement).
 
> * http://www.lyx.org/trac/ticket/2591
> text inset for tipa
> 
> Juergen, Uwe?

This requires inset preview. If we have a "Preview [0|1]" tag for 
InsetLayout, this can be implemented within 5 minutes.
 
> * http://www.lyx.org/trac/ticket/2605
> Add checkbox for automatic equation, figure and table
> numbering corresponding to section number
> 
> no activity for 3 years. c?

Not very pressing, since we have modules for this now. I generally vote for 
cleaning up the modules and to get proper GUI for some of the features 
instead. But this can wait.

> * http://www.lyx.org/trac/ticket/2625
> add support for textsuperscript and textsubscript
> 
> Uwe, anybodye else?

Again, this requires either instant preview and/or an inset that shows up as 
proper index. 

> * http://www.lyx.org/trac/ticket/3881
> support for the libertines font families
> * http://www.lyx.org/trac/ticket/4332
> support for the TeX Gyre fonts
> 
> anybody?

I would prefer to add a generic font support (via config file) before we add 
support for new fonts. But again, no 2.0 stuff.

> * http://www.lyx.org/trac/ticket/5078
> Add "pagebreak" option to all box decoration types
> 
> anybody?

Not me.

> * http://www.lyx.org/trac/ticket/6455
> Multiple index UI polishment
> - index inset should display something besides just  "Idx"
> - Insert>Toc menu should probably say "Index: Names" rather  than just
> "Names".
> 
> Juegen, Richard?

I don't see a quick way to fix these. And I think it's not crucial (for 
2.0).

> ufff... pavel

Thanks,
Jürgen

RE: Enhancement bugs for 2.0

[Charles de Miramon]

Vincent van Ravesteijn - TNW wrote:

>>* http://www.lyx.org/trac/ticket/2625
>>convert the search dialog to a search bar
>>
>>to me it was fixed by new search pane. Vincent however have idea
>>to convert the current simple search dialog into search bar. opinions?
>>anybody wants to work on it? otherwise c.
> 
> I've already done some work on it. I really want to have this in 2.0.0,
> so we have a polished brand new search and replace functionality.
> 
> If not before 2.0.0, it must be done as soon as possible, so never c).
> 
> Anyway, sign me up for this one.
> 

I have just tried the svn trunk version and the new search It is 
great and I have have been longing this feature for years. Thank you Tommaso 
and the others.

But do we really need two search items in the menu ? 

I have argued in the past and I still believe that LyX menus are suffering 
from Emacs-Disease and there are too many items. LyX should not be 
intimidating for new users and shows its power step by step.   

Would it not be better to have one search dialog and a button to 
toggle between simple mode and advanced mode.

Today the advanced mode pane design is different than the simple one in term 
of place of the find button, replace button, replace all button, locations 
of the checkboxes. 

Usability wise, it is not optimal.

Cheers,
Charles

RE: Enhancement bugs for 2.0

[Vincent van Ravesteijn - TNW]

>Would it not be better to have one search dialog and a
>button to toggle between simple mode and advanced mode.

The simple search will be a toolbar if it's up to me.

>Today the advanced mode pane design is different than the simple one in
>term of place of the find button, replace button, replace all button,
locations
>of the checkboxes. 
>
>Usability wise, it is not optimal.

Did you update today ? I think they are now exactly the same.

Vincent

RE: Enhancement bugs for 2.0

[Charles de Miramon]

Vincent van Ravesteijn - TNW wrote:

> 
> Did you update today ? I think they are now exactly the same.
> 

Thank you. It is much better. Still, I would go further and get rid of the 
advanced tab:

- At the top of the pane I would put the scope as a combo box
- Then a smaller Find TextEdit
- Then the Regular Expression combo
- Then on the left the Case Sensitive, Whole words only, Search backwards, 
Ignore Format checkboxes 
- On the right ; Search Next button

- A smaller Replace TextEdit
- Preserve first case on replace checkbox on the left (I don't really 
understand the option, should it not be 'preserve original formatting when 
replacing') 
- Replace
- Replace all

- I think there is a need for a reset button to erase everything and take 
away any formatting in the Search textedit

Would it also be possible that when you check 'Ignore format' any formatting 
in the Search TextEdit is suppressed ?

Nitpicks :
- F3 shortkey does not work in the advanced search
- Some shortkeys are different in the quick search and the advanced one


Cheers,
Charles

Re: Enhancement bugs for 2.0

[rgheck]

On 03/25/2010 02:16 PM, Jürgen Spitzmüller wrote:



* http://www.lyx.org/trac/ticket/6455
Multiple index UI polishment
- index inset should display something besides just  "Idx"
- Insert>Toc menu should probably say "Index: Names" rather  than just
"Names".

Juegen, Richard?
 

I don't see a quick way to fix these. And I think it's not crucial (for
2.0).

   


The first, about display, I think can be fixed pretty easily, and I'll 
try to do that. The issue with the TOC is much more complex, since we 
only have one Index TOC at the moment. I.e., the TOC doesn't know about 
multiple indexes.


rh

Re: [patch] Re: Enhancement? Documentation issue? Neither?

[Jürgen Spitzmüller]

Paul A. Rubin wrote:
 a.  inserting any note object other than a LyX Note in a caption blows
 up LaTeX; and

 b.  inserting a comment in a footnote blows up LaTeX (but inserting a
 Greyed, Framed or Shaded note in a footnote works just fine).

These are old bugs.

 This is with LyX 1.5.4, in case it matters.  That second one confuses
 me; I don't see any obvious reason why footnotes would allow nested
 environments but not comments specifically.

comment is a verbatim environment, and verbatim does not work within 
footnotes:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=verbwithin

 I couldn't tell whether your patch would catch those, and I'm not sure
 if they are worth defending against, but I thought I'd point it out.
 Perhaps the user manual (section 4.1) should note that LyX Notes can go
 anywhere, but placement of other notes is limited by LaTeX (and so they
 should be used outside ordinary body text with caution)?

We could forbid the insertion of the specific types within the specific 
problematic context.

Jürgen

Re: [patch] Re: Enhancement? Documentation issue? Neither?

[Paul A. Rubin]

Jürgen Spitzmüller wrote:


We could forbid the insertion of the specific types within the specific 
problematic context.




Unless someone had a huge need to insert boxed text in a caption, that 
would make sense to me.  For people who are not TeXperts, debugging a 
problem caused by a note in a place it ought not be can be difficult.


/Paul

Re: [patch] Re: Enhancement? Documentation issue? Neither?

[Jürgen Spitzmüller]

Paul A. Rubin wrote:
> a.  inserting any note object other than a LyX Note in a caption blows
> up LaTeX; and
>
> b.  inserting a comment in a footnote blows up LaTeX (but inserting a
> Greyed, Framed or Shaded note in a footnote works just fine).

These are old bugs.

> This is with LyX 1.5.4, in case it matters.  That second one confuses
> me; I don't see any obvious reason why footnotes would allow nested
> environments but not comments specifically.

comment is a verbatim environment, and verbatim does not work within 
footnotes:
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=verbwithin

> I couldn't tell whether your patch would catch those, and I'm not sure
> if they are worth defending against, but I thought I'd point it out.
> Perhaps the user manual (section 4.1) should note that LyX Notes can go
> anywhere, but placement of other notes is limited by LaTeX (and so they
> should be used outside ordinary body text with caution)?

We could forbid the insertion of the specific types within the specific 
problematic context.

Jürgen