RE: questions and proposal regarding enum FuncAttribs

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, July 12, 2012 5:20 AM

Le 12/07/2012 09:44, Scott Kostyshak a écrit :
 It seems that there are many LFUNs that would fall under the description
 of the Argument flag (currently help-open is the only LFUN to specify
 it). If this flag were accurately used, would it be desired to have a
 centralized checking of an empty argument?

I think theargument flag is not flexible enough to be useful.

Why not? The attached patch checks whether the LFUN being called in GuiView.cpp 
has the Argument flag and is trying to use an empty argument. If so, the 
command is disabled (from getStatus). I think it is similar to checking 
NoBuffer. Why should checking for whether there's no argument be treated 
differently from checking whether there's no open buffer? Shouldn't both be 
done in getStatus and not by each individual LFUN?

The patch adds the Argument property to a few LFUNs and removes some now 
unnecessary case-specific checks. These are just for examples though and the 
patch is not meant to be complete.

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..dddf86f 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -2177,7 +2177,7 @@ void LyXAction::init()
  * \li Origin: sanda, 13 Jan 2009
  * \endvar
  */
-		{ LFUN_VC_COMMAND, vc-command, NoBuffer | ReadOnly, System },
+		{ LFUN_VC_COMMAND, vc-command, NoBuffer | ReadOnly | Argument, System },
 /*!
  * \var lyx::FuncCode lyx::LFUN_VC_LOCKING_TOGGLE
  * \li Action: Toggles the locking property of the edited file.
@@ -2598,7 +2598,7 @@ void LyXAction::init()
  * \li Origin: Edwin, 21 May 2007
  * \endvar
  */
-		{ LFUN_TOOLBAR_TOGGLE, toolbar-toggle, NoBuffer, Buffer },
+		{ LFUN_TOOLBAR_TOGGLE, toolbar-toggle, NoBuffer | Argument, Buffer },
 /*!
  * \var lyx::FuncCode lyx::LFUN_MENU_OPEN
  * \li Action: Opens the menu given by its name.
@@ -2681,7 +2681,7 @@ void LyXAction::init()
  * \li Origin: leeming, 17 Jun 2003
  * \endvar
  */
-		{ LFUN_DIALOG_SHOW, dialog-show, NoBuffer, Edit },
+		{ LFUN_DIALOG_SHOW, dialog-show, NoBuffer | Argument, Edit },
 /*!
  * \var lyx::FuncCode lyx::LFUN_DIALOG_SHOW_NEW_INSET
  * \li Action: Shows hidden dialog or create new one for a given inset settings etc.
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 52a4379..b7eb4b6 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -1601,6 +1601,12 @@ void GuiView::resetAutosaveTimers()
 bool GuiView::getStatus(FuncRequest const  cmd, FuncStatus  flag)
 {
 	bool enable = true;
+	if (lyxaction.funcHasFlag(cmd.action(), LyXAction::Argument)  cmd.argument().empty()) {
+		flag.message(from_utf8(N_(Command not allowed with
+	out any argument)));
+		flag.setEnabled(false);
+		return true;
+	}
 	Buffer * buf = currentBufferView()
 		? currentBufferView()-buffer() : 0;
 	Buffer * doc_buffer = documentBufferView()
@@ -1860,8 +1866,6 @@ bool GuiView::getStatus(FuncRequest const  cmd, FuncStatus  flag)
 		enable = doc_buffer  doc_buffer-lyxvc().repoUpdateEnabled();
 		break;
 	case LFUN_VC_COMMAND: {
-		if (cmd.argument().empty())
-			enable = false;
 		if (!doc_buffer  contains(cmd.getArg(0), 'D'))
 			enable = false;
 		break;

checking whether a buffer is hidden

[Scott Kostyshak]

What is the correct way to check whether a buffer is hidden?

I am currently doing the following
bool const hidden = !(guiApp-currentView()  
guiApp-currentView()-workArea(*b));

which works fine but I'm not sure if it's the right way.

Thanks,

Scott

Re: checking whether a buffer is hidden

[Jean-Marc Lasgouttes]

Le 15/07/12 09:14, Scott Kostyshak a écrit :

What is the correct way to check whether a buffer is hidden?

I am currently doing the following
bool const hidden = !(guiApp-currentView() 
guiApp-currentView()-workArea(*b));

which works fine but I'm not sure if it's the right way.


This is the usual way, as ugly as it may seem.

JMarc

Re: questions and proposal regarding enum FuncAttribs

[Jean-Marc Lasgouttes]

Le 15/07/12 09:10, Scott Kostyshak a écrit :

I think theargument flag is not flexible enough to be useful.


Why not? The attached patch checks whether the LFUN being called in
GuiView.cpp has the Argument flag and is trying to use an empty
argument. If so, the command is disabled (from getStatus). I think it
is similar to checking NoBuffer. Why should checking for whether
there's no argument be treated differently from checking whether
there's no open buffer? Shouldn't both be done in getStatus and not
by each individual LFUN?

The patch adds the Argument property to a few LFUNs and removes some
now unnecessary case-specific checks. These are just for examples
though and the patch is not meant to be complete.


What I mean is that checking for no argument situation is only a small
part. We need at least to be able to say how many required and optional 
arguments are needed. Moreover, some arguments just use the remainder of 
the line. Also, to be useful, one needs to tell what the syntax is.

We could just be able to parse what we have in LyXAction.cpp, like:
 space-insert NAME [LEN]
telling that there is on required argument and one optional one.

NoBuffer is different, since it only describes the context in which the 
command can be used, which is much easier than its syntax.


JMarc

Line-styles for tables

[Julian Parker]

I think, it would be a great idea, if Lyx supports line-styles for
tables. Not too much. But besides the normal line a thicker line, a
dashed line and a dotted line, would be great.

Editing names for TOC, captions, ...

[Julian Parker]

It would be great, if the document-settings would also have a window,
where you can change the fixed names that Lyx uses for some elements.
E.g. fig. instead of figure, and the same for tables, TOC, etc.
Because often users have to use special terms that are given by the
university, the magazine,... I know this is possible with
LaTeX-syntax. But people who use Lyx do that because they don't want
to use LaTeX. A GUI for the naming of that elements would be
excellent.

Re: Line-styles for tables

[Richard Heck]

On 07/15/2012 10:37 AM, Julian Parker wrote:

I think, it would be a great idea, if Lyx supports line-styles for
tables. Not too much. But besides the normal line a thicker line, a
dashed line and a dotted line, would be great.


Please file an enhancement request for this.

rh

GUI for headers and footers with fancy page-style

[Julian Parker]

If you use fancy page-style you can use LaTeX-commands for what is
displayed in header (left, center, right) and footer (left, center,
right). And if a line is displayed or not. Because Lyx is for those
people who are no specialists for LaTeX it would be excellent, if
after activation of fancy page-style in the document-settings there
would be chechboxes for check/uncheck the lines and fields for all 6
positions where you can type your own text or choose variables like
page-number, date, section-title,... And when you use 2-page-layout
this shoule be automatically mirrored for the opposite pages. A GUI
for this often needed and by many beginners often wanted feature would
be a great step forward.

Re: Line-styles for tables

[Julian Parker]

2012/7/15 Richard Heck rgh...@lyx.org:
 On 07/15/2012 10:37 AM, Julian Parker wrote:

 I think, it would be a great idea, if Lyx supports line-styles for
 tables. Not too much. But besides the normal line a thicker line, a
 dashed line and a dotted line, would be great.

 Please file an enhancement request for this.

 rh


How do I do that?

Re: Line-styles for tables

[Richard Heck]

On 07/15/2012 11:06 AM, Julian Parker wrote:

2012/7/15 Richard Heck rgh...@lyx.org:

On 07/15/2012 10:37 AM, Julian Parker wrote:

I think, it would be a great idea, if Lyx supports line-styles for
tables. Not too much. But besides the normal line a thicker line, a
dashed line and a dotted line, would be great.


Please file an enhancement request for this.

rh


How do I do that?


http://www.lyx.org/trac/newticket

You'll need to create a user profile if you don't have one.

Richard

Re: Editing names for TOC, captions, ...

[Richard Heck]

On 07/15/2012 10:40 AM, Julian Parker wrote:

It would be great, if the document-settings would also have a window,
where you can change the fixed names that Lyx uses for some elements.
E.g. fig. instead of figure, and the same for tables, TOC, etc.
Because often users have to use special terms that are given by the
university, the magazine,... I know this is possible with
LaTeX-syntax. But people who use Lyx do that because they don't want
to use LaTeX. A GUI for the naming of that elements would be
excellent.

This is harder than it seems, to do in a general way, since different 
LaTeX classes have quite

different ways of changing these things. But it's worth thinking about.

Richard

Bug: Zoom of editor doesn't zoom mathematical expression

[Julian Parker]

When you zoom in/out the editor (Alt+ / Alt-), everything is zoomed, but
 not the mathematical expressions. E.g. I have an x with a dash about it in
 the text (arithmetic mean) that is not zoomed in/out when I zoom in/out
 the editor.

Lyx 2.0.4 on Windows 7

Re: GUI for headers and footers with fancy page-style

[Richard Heck]

On 07/15/2012 10:55 AM, Julian Parker wrote:

If you use fancy page-style you can use LaTeX-commands for what is
displayed in header (left, center, right) and footer (left, center,
right). And if a line is displayed or not. Because Lyx is for those
people who are no specialists for LaTeX it would be excellent, if
after activation of fancy page-style in the document-settings there
would be chechboxes for check/uncheck the lines and fields for all 6
positions where you can type your own text or choose variables like
page-number, date, section-title,... And when you use 2-page-layout
this shoule be automatically mirrored for the opposite pages. A GUI
for this often needed and by many beginners often wanted feature would
be a great step forward.

This has been discussed in the past. The problem is this. Simply 
providing a text field in a
dialog where you can enter some LaTeX isn't terribly helpful. What would 
be more helpful
would be if there were a way you could enter the text like you do in 
LyX. There have been
attempts to do this, using a module, but it's a bit hackish. The other 
issue is that, in many
cases, what you want to enter won't be something LyX can easily provide, 
e.g., the page

number. So you'd end up using a lot of ERT.

Richard

Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Julian Parker]

When you have the pop-up list with paragraph-environments open and
want to jump to certain styles by typing the first letters, the pop-up
window shrinks smaller and there comes a scroll-bar when there are too
many hits. It's annoying to not see the whole list of hits, because
the unfiltered complete list is even longer. The length should be as
long as needed. Not longer and not shorter.

Lyx 2.0.4 on Windows 7

Re: GUI for headers and footers with fancy page-style

[Julian Parker]

2012/7/15 Richard Heck rgh...@lyx.org:
 On 07/15/2012 10:55 AM, Julian Parker wrote:

 If you use fancy page-style you can use LaTeX-commands for what is
 displayed in header (left, center, right) and footer (left, center,
 right). And if a line is displayed or not. Because Lyx is for those
 people who are no specialists for LaTeX it would be excellent, if
 after activation of fancy page-style in the document-settings there
 would be chechboxes for check/uncheck the lines and fields for all 6
 positions where you can type your own text or choose variables like
 page-number, date, section-title,... And when you use 2-page-layout
 this shoule be automatically mirrored for the opposite pages. A GUI
 for this often needed and by many beginners often wanted feature would
 be a great step forward.

 This has been discussed in the past. The problem is this. Simply providing a
 text field in a
 dialog where you can enter some LaTeX isn't terribly helpful. What would be
 more helpful
 would be if there were a way you could enter the text like you do in LyX.
 There have been
 attempts to do this, using a module, but it's a bit hackish. The other issue
 is that, in many
 cases, what you want to enter won't be something LyX can easily provide,
 e.g., the page
 number. So you'd end up using a lot of ERT.

 Richard



Yes, I meant not fields for typing LaTeX again, but for typing text
you want and additonal the option to choose things like page-number,
date, section-title...

Would be great if it works some day.

Re: Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Richard Heck]

On 07/15/2012 02:17 PM, Julian Parker wrote:

When you have the pop-up list with paragraph-environments open and
want to jump to certain styles by typing the first letters, the pop-up
window shrinks smaller and there comes a scroll-bar when there are too
many hits. It's annoying to not see the whole list of hits, because
the unfiltered complete list is even longer. The length should be as
long as needed. Not longer and not shorter.

I see that. I'm not sure what causes it.

Richard

RE: questions and proposal regarding enum FuncAttribs

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 9:41 AM

Le 15/07/12 09:10, Scott Kostyshak a écrit :
 I think theargument flag is not flexible enough to be useful.

 Why not? The attached patch checks whether the LFUN being called in
 GuiView.cpp has the Argument flag and is trying to use an empty
 argument. If so, the command is disabled (from getStatus). I think it
 is similar to checking NoBuffer. Why should checking for whether
 there's no argument be treated differently from checking whether
 there's no open buffer? Shouldn't both be done in getStatus and not
 by each individual LFUN?

 The patch adds the Argument property to a few LFUNs and removes some
 now unnecessary case-specific checks. These are just for examples
 though and the patch is not meant to be complete.

What I mean is that checking for no argument situation is only a small
part. We need at least to be able to say how many required and optional
arguments are needed. Moreover, some arguments just use the remainder of
the line. Also, to be useful, one needs to tell what the syntax is.
We could just be able to parse what we have in LyXAction.cpp, like:
  space-insert NAME [LEN]
telling that there is on required argument and one optional one.

NoBuffer is different, since it only describes the context in which the
command can be used, which is much easier than its syntax.

Ah, I see what you mean. Do you have an idea for the best way to parse 
LyXAction.cpp? Would any of the following strategies work well?
(1) Parse LyXAction.cpp when building and store a map in lib and then load that 
map on runtime

Is parsing LFUNs.lyx a bad idea? This would allow

(2) Parse LFUNs.lyx during configure and store a map in lib
(3) Parse LFUNs.lyx on run-time

If this is a conversation best left for another time, let me know.

Thanks,

Scott

doxygen command for LyXAction.cpp -- LFUNs.lyx

[Scott Kostyshak]

How do I turn LyXAction.cpp into LFUNs.lyx?

Thanks,

Scott

[PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

Attached is a patch that implements LFUN_BUFFER_FORALL, which applies a passed 
LFUN command to all buffers. My motivation was that I sometimes need to do the 
same thing in all of the buffers that I have open. Another advantage of 
implementing this LFUN is that it allows buffer-specific settings to be made 
global. For example, if a user wants to be able to toggle track changes for all 
documents, he can do that (similarly for read only).

Here are some sample uses:

Close all Notes in all documents: \n
buffer-forall inset-forall Note inset-toggle close \n
Toggle change tracking on all documents: \n
buffer-forall changes-track \n
Toggle read-only for all documents: \n
buffer-forall buffer-toggle-read-only \n
Show statistics for each document: \n
buffer-forall statistics \n
Activate the branch named Solutions in all documents: \n
buffer-forall branch-activate Solutions \n

I tested several potential special uses, such as nested calls, repeated calls, 
uses with other special commands like command-sequence, and uses with LFUNs 
that create and close buffers. The following all work fine:
buffer-forall buffer-forall self-insert testing
repeat 3 buffer-forall repeat 3 self-insert 1
buffer-forall buffer-close
buffer-forall buffer-new
buffer-forall inset-forall Note inset-toggle close

When a buffer-forall command is issued and the command passed to it is disabled 
on one of the buffers, currently buffer-forall continues on to the other 
buffers and tries to execute the passed command. I think this is the correct 
behavior. Alternatively, buffer-forall could stop whenever it finds a buffer 
where the command is disabled.

buffer-forall allows for an optional flag, includehidden. If includehidden is 
not specified, hidden buffers are ignored. If includehidden is specified, the 
action is applied to the hidden buffers and then they are hidden again. I might 
extend this option to allow for onlyhidden, which would not apply the command 
to non-hidden buffers. This would allow, e.g., to close all hidden buffers.

Any comments?

Thanks,

Scott
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..a066234 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..bed84c6 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3139,27 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all non-hidden buffers, optionally including hidden buffers.
+ * \li Syntax: buffer-forall [INCLUDEHIDDEN] LFUN-COMMAND
+ * \li Params: LFUN-COMMAND: The command that is to be applied to the buffers.
+   INCLUDEHIDDEN: 'includehidden' to iterate over hidden buffers.
+Otherwise they are skipped
+ * \li Sample: Close all Notes in all non-hidden documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall includehidden changes-track \n
+   Toggle read-only for all non-hidden documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall includehidden statistics \n
+   Activate the branch named Solutions in all non-hidden documents: \n
+	   buffer-forall branch-activate Solutions \n
+ * \li Origin: scottkostyshak, 15 Jul 2012
+ * \endvar
+ */
+		{ LFUN_BUFFER_FORALL, buffer-forall, ReadOnly | Argument, Buffer },
+/*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_WRITE_ALL
  * \li Action: Save all changed documents.
  * \li Syntax: buffer-write-all
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index ca63632..bd06441 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -1679,6 +1683,7 @@ bool GuiView::getStatus(FuncRequest const  cmd, FuncStatus  flag)
 		break;
 	}
 
+	case LFUN_BUFFER_FORALL:
 	case LFUN_BUFFER_WRITE_AS:
 	case LFUN_BUFFER_EXPORT_AS:
 		enable = doc_buffer;
@@ -3332,6 +3337,54 @@ void GuiView::dispatch(FuncRequest const  cmd, DispatchResult  dr)
 			gotoNextOrPreviousBuffer(PREVBUFFER);
 			break;
 
+		case LFUN_BUFFER_FORALL: {
+			Buffer * const buf = currentBufferView()-buffer();
+			if (!buf)
+break;
+
+			bool processHidden = false;
+			string commandToRun = argument;
+			if (argument.substr(0,13) == includehidden) {
+processHidden = true;
+commandToRun = argument.substr(14, argument.size());
+			}
+
+			docstring const hiddenOrNot = processHidden ? _(all hidden and non-hidden) : _(all non-hidden

RE: checking whether a buffer is hidden

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 9:34 AM

Le 15/07/12 09:14, Scott Kostyshak a écrit :
 What is the correct way to check whether a buffer is hidden?

 I am currently doing the following
 bool const hidden = !(guiApp-currentView() 
 guiApp-currentView()-workArea(*b));

 which works fine but I'm not sure if it's the right way.

This is the usual way, as ugly as it may seem.

Could I add a buffer member function that does this or is it too uncommon?

Scott

Re: [LyX master] Fix bug #7741: incorrect locale when starting R from LyX?

[Jean-Marc Lasgouttes]

Le 15/07/12 22:30, Jean-Marc Lasgouttes a écrit :

commit 16fd47ad8f5d78a3b7266520b0868c1e2bd0dcac
Author: Jean-Marc Lasgouttes lasgout...@lyx.org
Date:   Sun Jul 15 22:22:10 2012 +0200

 Fix bug #7741: incorrect locale when starting R from LyX?

 The goal here is to get rid of the old code that modified variables
 LANGUAGE and LC_ALL, therefore creating the problems mentionned
 in the ticket.

 In the new system, there is no explicit GUI message handler, that
 needs to be reset at each language change. Instead, getGuiMessages
 calls getMessages with the correct parameter. This allows to simplify
 greatly the code and to remove a lot of old cruft.


This is basically a rewrite of the code that sets GUI language via 
lyxrc. The code is now much simpler in my opinion, which mitigates the risk.


I would appreciate feedback on how this work on linux, mac os and windows.

Since bug #7741 is very annoying for all external programs which do not 
like having weird locale settings, I think this should eventually go to 
branch.


JMarc

[PATCH] LFUN_BUFFER_EXPORT_ALL File menu reorganization

[Scott Kostyshak]

Attached is a patch that does the following:

(1) Creates LFUN_BUFFER_EXPORT_ALL. My motivation was that I'm often working on 
several problem sets or notes at once and would like to export all of them to 
pdf.

(2) Reorganizes the File menu: The current implementation places import next to 
export. Although this is logical in some sense because the two are opposites, I 
think it would make more sense to place export next to save because the two 
operations are similar. Someone going to the menu to save might realize that 
what he really wants to do is export. Similarly, I suggest moving Import next 
to Open.

I suggest that we have the file menu walk the user through a session: The first 
part of the File menu relates to getting started after you open LyX. You're 
either going to start a new buffer, open a file or import a file. The next part 
has to do with saving your work (either with one of the Saves or one of the 
Exports). This segues into Print and Fax, which in an abstract sense are like 
exporting. In the final stage of your session, you will either Close or Exit.

(3) I moved the Export As out of the Export submenu and I added an Export All 
entry. This makes saving and exporting consistent: Just as there are Save, Save 
As, and Save All, there are now Export, Export As, and Export All.

currently, this patch depends on LFUN_BUFFER_FORALL, which I am suggesting 
here: [1]. It might be nice to allow a directory path to be given to 
LFUN_BUFFER_EXPORT_ALL as an argument. To implement this, there are two options:
(a) stop using LFUN_BUFFER_FORALL and loop through the buffers manually, 
calling LFUN_BUFFER_EXPORT and passing it the path and filename.
(b) modify LFUN_BUFFER_EXPORT to accept a path as an argument. If a path is 
given as the argument, the default should be to use the buffer's filename.

LFUN_BUFFER_EXPORT_ALL as implemented in this patch does not work with the 
custom argument (which LFUN_BUFFER_EXPORT_ALL does support). If custom is 
passed, then the first buffer processed is exporting with the chosen format but 
it stops there. I will add support for custom if everything else looks ok for 
this LFUN.

Any comments?

Thanks,

Scott

[1] http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg174669.html
diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index b7e1f03..8958236 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -44,25 +44,27 @@ Menuset
 	Menu file
 		Item New|N buffer-new
 		Item New from Template...|m buffer-new-template
+		Item New Window|W window-new
 		Item Open...|O file-open
 		Submenu Open Recent|t file_lastfiles
+		Submenu Import|I file_import
 		Separator
-		Item Close|C buffer-close
-		Item Close All buffer-close-all
-		Item Save|S buffer-write
-		Item Save As...|A buffer-write-as
-		Item Save All|l buffer-write-all
 		Item Revert to Saved|R buffer-reload
 		Submenu Version Control|V file_vc
 		Separator
-		Submenu Import|I file_import
+		Item Save|S buffer-write
+		Item Save As...|A buffer-write-as
+		Item Save All|l buffer-write-all
 		Submenu Export|E file_export
+		Item Export As... buffer-export-as
+		Submenu Export All file_export_all
+		Separator
 		Item Print...|P dialog-show print
 		OptItem Fax...|F buffer-export fax
 		Separator
-		Item New Window|W window-new
+		Item Close|C buffer-close
+		Item Close All buffer-close-all
 		Item Close Window|d window-close
-		Separator
 		Item Exit|x lyx-quit
 	End
 
@@ -87,11 +89,15 @@ Menuset
 	End
 
 	Menu file_export
-		Item Export As...|s buffer-export-as
 		ExportFormats
 		Item More Formats  Options...|O buffer-export custom
 	End
 
+	Menu file_export_all
+		ExportAllFormats
+		Item More Formats  Options...|O buffer-export custom
+	End
+
 #
 # EDIT MENU
 #
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index cabfe63..9d3fc00 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2165,6 +2165,7 @@ bool Buffer::getStatus(FuncRequest const  cmd, FuncStatus  flag)
 			// FIXME: Nothing to check here?
 			break;
 
+		case LFUN_BUFFER_EXPORT_ALL:
 		case LFUN_BUFFER_EXPORT: {
 			docstring const arg = cmd.argument();
 			if (arg == custom) {
@@ -2247,6 +2248,12 @@ void Buffer::dispatch(FuncRequest const  func, DispatchResult  dr)
 		break;
 	}
 
+	case LFUN_BUFFER_EXPORT_ALL: {
+		lyx::dispatch(FuncRequest(LFUN_BUFFER_FORALL, buffer-export  + argument));
+		break;
+	}
+		
+
 	case LFUN_BUILD_PROGRAM:
 		doExport(program, true);
 		break;
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..a066234 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -453,6 +453,7 @@ enum FuncCode
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
+	LFUN_BUFFER_EXPORT_ALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..bed84c6 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp

Re: questions and proposal regarding enum FuncAttribs

[Jean-Marc Lasgouttes]

Le 15/07/12 21:05, Scott Kostyshak a écrit :

Ah, I see what you mean. Do you have an idea for the best way to
parse LyXAction.cpp? Would any of the following strategies work
well?


I think the best way would be to change LyXAction.cpp such that the 
documentation is in string variables action, syntax and params 
(added to the struct). They will therefore be available to LyX itself to 
provide online help if we want to. This would mean that the script that 
created LFUNs.lyx will need to be updated (or LyX itself could create 
the file, but this is admitedly more difficult...).



If this is a conversation best left for another time, let me know.


No problem, I have some time now. But doing this is probably a lot of work.

JMarc

Re: doxygen command for LyXAction.cpp -- LFUNs.lyx

[Jean-Marc Lasgouttes]

Le 15/07/12 21:07, Scott Kostyshak a écrit :

How do I turn LyXAction.cpp into LFUNs.lyx?


I think you need development/tools/gen_lfuns.py.

JMarc

Re: checking whether a buffer is hidden

[Jean-Marc Lasgouttes]

Le 15/07/12 22:37, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 9:34 AM

Le 15/07/12 09:14, Scott Kostyshak a écrit :

What is the correct way to check whether a buffer is hidden?

I am currently doing the following
bool const hidden = !(guiApp-currentView() 
guiApp-currentView()-workArea(*b));

which works fine but I'm not sure if it's the right way.



This is the usual way, as ugly as it may seem.


Could I add a buffer member function that does this or is it too uncommon?


The problem is that it needs to be a member function of GuiApplication. 
The buffer itself has no reason to know that it is hidden.


In what part of code do you need to know this information?

I am not sure that the notion of hidden buffer is correctly defined 
(when are they visible?)


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 15/07/12 22:35, Scott Kostyshak a écrit :

Attached is a patch that implements LFUN_BUFFER_FORALL, which applies a
passed LFUN command to all buffers. My motivation was that I sometimes
need to do the same thing in all of the buffers that I have open.
Another advantage of implementing this LFUN is that it allows
buffer-specific settings to be made global. For example, if a user wants
to be able to toggle track changes for all documents, he can do that
(similarly for read only).


This looks like a useful feature.


When a buffer-forall command is issued and the command passed to it is
disabled on one of the buffers, currently buffer-forall continues on to
the other buffers and tries to execute the passed command. I think this
is the correct behavior. Alternatively, buffer-forall could stop
whenever it finds a buffer where the command is disabled.


You current choice looks good.


buffer-forall allows for an optional flag, includehidden. If
includehidden is not specified, hidden buffers are ignored. If
includehidden is specified, the action is applied to the hidden buffers
and then they are hidden again. I might extend this option to allow for
onlyhidden, which would not apply the command to non-hidden buffers.
This would allow, e.g., to close all hidden buffers.



Any comments?


See below in the patch.

JMarc

+   case LFUN_BUFFER_FORALL: {
+   Buffer * const buf = currentBufferView()-buffer();
+   if (!buf)
+   break;


Why is this test needed? The current buffer has nothing to do with 
buffer-forall. Moreover, this code should not be in GuiView, but in 
GuiApplication, since the function is at application level.



+
+   bool processHidden = false;
+   string commandToRun = argument;
+   if (argument.substr(0,13) == includehidden) {
+   processHidden = true;
+   commandToRun = argument.substr(14, 
argument.size());
+   }


Please do not use string methods by hand. FuncRequest object have 
methods getArg and getLongArg that work very well for these uses.



+
+   docstring const hiddenOrNot = processHidden ? _(all hidden and 
non-hidden) : _(all non-hidden);
+   dr.setMessage(bformat(_(Applied the command \%1$s\ to 
%2$s buffers), from_utf8(commandToRun), hiddenOrNot));


Please use two complete sentences (one for hidden and one for not 
hidden). Your sentences may be difficult to translate in some languages.



+
+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.


I know this code is taken from somewhere else, but I am not sure why you 
can't use BufferList::begin()/end(). The only problem is maybe what 
happens if the buffer is deleted by the lfun.



+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); 
//get next now bc LFUN might close current
+
+   bool const hidden = !(guiApp-currentView()  
guiApp-currentView()-workArea(*b));
+   if (hidden) {
+   if (processHidden) {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   GuiWorkArea * const wa = 
currentWorkArea();
+   wa-view().hideWorkArea(wa);
+   }
+   }
+
+   else {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   }


if (!hidden || processHidden) {
setBuffer(b);
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
if (hidden) {
GuiWorkArea * const wa = currentWorkArea();
wa-view().hideWorkArea(wa);
}
}

The lookup of commandToRun should be done at the place where the 
arguments are parsed.

Re: questions and proposal regarding enum FuncAttribs

[Pavel Sanda]

Scott Kostyshak wrote:
 Why not? The attached patch checks whether the LFUN being called in 
 GuiView.cpp

This works with VC_COMMAND. IIRC there are more possible entry points for LFUN 
execution,
I'm not sure where all go through GuiView::getStatus, worth to check.

 Is parsing LFUNs.lyx a bad idea? This would allow

LFUNs.lyx generation is very fragile stuff without error checking when 
something goes wrong.

Jean-Marc Lasgouttes wrote:
 I think the best way would be to change LyXAction.cpp such that the 
 documentation is in string variables action, syntax and params (added 
 to the struct).

I'm not saying we can't go this route, just note that the current format was 
forced in order
to allow doxygen documentation work (it was in the days prior to LFUNs.lyx 
birth).

Pavel

Re: questions and proposal regarding enum FuncAttribs

[Jean-Marc Lasgouttes]

Le 15/07/12 23:24, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I think the best way would be to change LyXAction.cpp such that the
documentation is in string variables action, syntax and params (added
to the struct).


I'm not saying we can't go this route, just note that the current format was 
forced in order
to allow doxygen documentation work (it was in the days prior to LFUNs.lyx 
birth).


What would you propose?

JMarc

Re: Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Pavel Sanda]

Richard Heck wrote:
 I see that. I'm not sure what causes it.

This is old timer and IIRC there was even committed attempt to fix it from 
Stefan long time ago.

Pavel

Re: Closing split views from the right click menu

[Andrew Parsloe]

On 15/07/2012 2:18 p.m., Richard Heck wrote:

On 07/14/2012 07:08 PM, Andrew Parsloe wrote:

I'm constantly working with a split window, generally left and right
views. Closing one of these views to get a single main window again
means going to the View menu and clicking on Close Current View, not a
big deal but, repeated many times, a minor irritation. And there's no
built-in shortcut indicated. It would be convenient if Close Current
View could be added to the right-click menu when the cursor is in one
of the split views. On the current right-click menu, it would fit
naturally at the bottom beside Fullscreen Mode.


Done for trunk. Should be in 2.0.5.

If you want to add this to your current installation, find
stdcontext.inc, and add:
Item Close Current View close-tab-group
at the appropriate place.

Richard



Thank you. I've made the addition to stdcontext.inc and it works perfectly.

Andrew

Re: Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Pavel Sanda]

Pavel Sanda wrote:
 Richard Heck wrote:
  I see that. I'm not sure what causes it.
 
 This is old timer and IIRC there was even committed attempt to fix it from 
 Stefan long time ago.

I think these are relevant: r23644,r23654

 Pavel

Re: doxygen command for LyXAction.cpp -- LFUNs.lyx

[Pavel Sanda]

Scott Kostyshak wrote:
 How do I turn LyXAction.cpp into LFUNs.lyx?

Doxygen generation is not related to LFUNs.lyx.
- doxygen: make doxydoc
- LFUNs.lyx: make lfundoc

Pavel

Re: [PATCH] LFUN_BUFFER_EXPORT_ALL File menu reorganization

[Pavel Sanda]

Scott Kostyshak wrote:

 Any comments?

While I think adding LFUNs you proposed makes sense, I don't think it's good
idea to add this new stuff into the File menu (at most poke them away to
some submenu). I would rather see the menu shrink than expand (e.g. Print).

Regarding the fact how any menu reorganizations tend to trigger long flames
it maybe wise to post such proposal independently to patches with real stuff
so it gets in independently ;)

Pavel

Re: [LyX master] Fix bug #7741: incorrect locale when starting R from LyX?

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 I would appreciate feedback on how this work on linux, mac os and windows.

I tested that setting LC_MESSAGES still works on Linux :)
Pavel

Re: questions and proposal regarding enum FuncAttribs

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Le 15/07/12 23:24, Pavel Sanda a écrit :
 Jean-Marc Lasgouttes wrote:
 I think the best way would be to change LyXAction.cpp such that the
 documentation is in string variables action, syntax and params (added
 to the struct).

 I'm not saying we can't go this route, just note that the current format was
 forced in order to allow doxygen documentation work (it was in the days
 prior to LFUNs.lyx birth).

 What would you propose?

It depends what are the goals. If the point is just to introduce argument flag
the price looks high (but no hard opinion if Scott feels like to fix all the
follow-ups).

If the goal is to allow the online documentation to be available via some
tooltips or whatever, then for consistency reasons we will be asked for
translations via gettext mechanism, no? This is lot of work on the shoulders
of translation teams for quite an esoteric part of the LyX functionality.

Pavel

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM

 + case LFUN_BUFFER_FORALL: {
 + Buffer * const buf = currentBufferView()-buffer();
 + if (!buf)
 + break;

Why is this test needed? The current buffer has nothing to do with
buffer-forall.

I use buf when I switch back to the current buffer after buffer-forall is done, 
assuming the current buffer still exists (that is, that the LFUN did not close 
it). The check is to make sure there is at least a buffer open, but as long as 
there is a check induced because of not having the NoBuffer property, I can 
take this out.

Moreover, this code should not be in GuiView, but in
GuiApplication, since the function is at application level.

ok, I will move it after the other issues are cleared up.

 +
 + bool processHidden = false;
 + string commandToRun = argument;
 + if (argument.substr(0,13) == includehidden) {
 + processHidden = true;
 + commandToRun = argument.substr(14, 
 argument.size());
 + }

 Please do not use string methods by hand. FuncRequest object have
 methods getArg and getLongArg that work very well for these uses.

Done.

 +
 + docstring const hiddenOrNot = processHidden ? _(all 
 hidden and non-hidden) : _(all non-hidden);
 + dr.setMessage(bformat(_(Applied the command \%1$s\ 
 to %2$s buffers), from_utf8(commandToRun), hiddenOrNot));

Please use two complete sentences (one for hidden and one for not
hidden). Your sentences may be difficult to translate in some languages.

Done. It is three sentences now because I am allowing three options: visible 
(default), hidden, and both.

 +
 + Buffer * const last = theBufferList().last();
 + Buffer * b = theBufferList().first();
 + Buffer * nextBuf = 0;
 + // We cannot use a for loop as the buffer list cycles.

I know this code is taken from somewhere else, but I am not sure why you
can't use BufferList::begin()/end(). The only problem is maybe what
happens if the buffer is deleted by the lfun.

Right, with BufferList::begin()/end() I don't think buffer-forall would work 
with LFUNs such as buffer-close. Should I still do it with 
BufferList::begin()/end() and blacklist certain functions? Or just let the user 
be responsible? In the attached patch I did not change it to use 
BufferList::begin()/end().


 + while (true) {
 + if (b != last)
 + nextBuf = theBufferList().next(b); 
 //get next now bc LFUN might close current
 +
 + bool const hidden = !(guiApp-currentView()  
 guiApp-currentView()-workArea(*b));
 + if (hidden) {
 + if (processHidden) {
 + setBuffer(b);
 + 
 lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
 + GuiWorkArea * const wa = 
 currentWorkArea();
 + wa-view().hideWorkArea(wa);
 + }
 + }
 +
 + else {
 + setBuffer(b);
 + 
 lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
 + }

The lookup of commandToRun should be done at the place where the
arguments are parsed.

Done.

Please see the attached patch.

Thank you for your help,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..2c99432 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..ff3f7fe 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,26 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, buffer-write-as, ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all visible, hidden, or both types of buffers.
+ * \li Syntax: buffer-forall [BUFFER-TYPE] LFUN-COMMAND
+ * \li Params: BUFFER-TYPE: visible|hidden|both default: default: visible   
+   LFUN-COMMAND: The command that is to be applied to the buffers.
+ * \li Sample: Close all Notes in all visible documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change

RE: checking whether a buffer is hidden

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 4:54 PM

The problem is that it needs to be a member function of GuiApplication.
The buffer itself has no reason to know that it is hidden.

In what part of code do you need to know this information?

I use this in LFUN_BUFFER_FORALL.

I am not sure that the notion of hidden buffer is correctly defined
(when are they visible?)

ok. Sounds like it's best to leave things how they are.

Thanks,

Scott

RE: doxygen command for LyXAction.cpp -- LFUNs.lyx

[Scott Kostyshak]

From: Pavel Sanda [sa...@lyx.org]
Sent: Sunday, July 15, 2012 6:34 PM

Doxygen generation is not related to LFUNs.lyx.
 - doxygen: make doxydoc
 - LFUNs.lyx: make lfundoc

Thanks,

Scott

RE: [PATCH] LFUN_BUFFER_EXPORT_ALL File menu reorganization

[Scott Kostyshak]

From: Pavel Sanda [sa...@lyx.org]
Sent: Sunday, July 15, 2012 7:19 PM

While I think adding LFUNs you proposed makes sense, I don't think it's good
idea to add this new stuff into the File menu (at most poke them away to
some submenu). I would rather see the menu shrink than expand (e.g. Print).

Regarding the fact how any menu reorganizations tend to trigger long flames
it maybe wise to post such proposal independently to patches with real stuff
so it gets in independently ;)

ok, I'll see if there are other comments. Otherwise I'll take out the 
reorganization changes and just propose LFUN_EXPORT_ALL. I'm not sure where to 
put Export All if not in the File menu. To have that submenu in the submenu of 
Export does not seem right either.

Scott

RE: questions and proposal regarding enum FuncAttribs

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, July 12, 2012 5:20 AM

Le 12/07/2012 09:44, Scott Kostyshak a écrit :
>> It seems that there are many LFUNs that would fall under the description
>> of the "Argument" flag (currently help-open is the only LFUN to specify
>> it). If this flag were accurately used, would it be desired to have a
>> centralized checking of an empty argument?

>I think theargument flag is not flexible enough to be useful.

Why not? The attached patch checks whether the LFUN being called in GuiView.cpp 
has the Argument flag and is trying to use an empty argument. If so, the 
command is disabled (from getStatus). I think it is similar to checking 
NoBuffer. Why should checking for whether there's no argument be treated 
differently from checking whether there's no open buffer? Shouldn't both be 
done in getStatus and not by each individual LFUN?

The patch adds the Argument property to a few LFUNs and removes some now 
unnecessary case-specific checks. These are just for examples though and the 
patch is not meant to be complete.

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..dddf86f 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -2177,7 +2177,7 @@ void LyXAction::init()
  * \li Origin: sanda, 13 Jan 2009
  * \endvar
  */
-		{ LFUN_VC_COMMAND, "vc-command", NoBuffer | ReadOnly, System },
+		{ LFUN_VC_COMMAND, "vc-command", NoBuffer | ReadOnly | Argument, System },
 /*!
  * \var lyx::FuncCode lyx::LFUN_VC_LOCKING_TOGGLE
  * \li Action: Toggles the locking property of the edited file.
@@ -2598,7 +2598,7 @@ void LyXAction::init()
  * \li Origin: Edwin, 21 May 2007
  * \endvar
  */
-		{ LFUN_TOOLBAR_TOGGLE, "toolbar-toggle", NoBuffer, Buffer },
+		{ LFUN_TOOLBAR_TOGGLE, "toolbar-toggle", NoBuffer | Argument, Buffer },
 /*!
  * \var lyx::FuncCode lyx::LFUN_MENU_OPEN
  * \li Action: Opens the menu given by its name.
@@ -2681,7 +2681,7 @@ void LyXAction::init()
  * \li Origin: leeming, 17 Jun 2003
  * \endvar
  */
-		{ LFUN_DIALOG_SHOW, "dialog-show", NoBuffer, Edit },
+		{ LFUN_DIALOG_SHOW, "dialog-show", NoBuffer | Argument, Edit },
 /*!
  * \var lyx::FuncCode lyx::LFUN_DIALOG_SHOW_NEW_INSET
  * \li Action: Shows hidden dialog or create new one for a given inset settings etc.
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index 52a4379..b7eb4b6 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -1601,6 +1601,12 @@ void GuiView::resetAutosaveTimers()
 bool GuiView::getStatus(FuncRequest const & cmd, FuncStatus & flag)
 {
 	bool enable = true;
+	if (lyxaction.funcHasFlag(cmd.action(), LyXAction::Argument) && cmd.argument().empty()) {
+		flag.message(from_utf8(N_("Command not allowed with"
+	"out any argument")));
+		flag.setEnabled(false);
+		return true;
+	}
 	Buffer * buf = currentBufferView()
 		? ()->buffer() : 0;
 	Buffer * doc_buffer = documentBufferView()
@@ -1860,8 +1866,6 @@ bool GuiView::getStatus(FuncRequest const & cmd, FuncStatus & flag)
 		enable = doc_buffer && doc_buffer->lyxvc().repoUpdateEnabled();
 		break;
 	case LFUN_VC_COMMAND: {
-		if (cmd.argument().empty())
-			enable = false;
 		if (!doc_buffer && contains(cmd.getArg(0), 'D'))
 			enable = false;
 		break;

checking whether a buffer is hidden

[Scott Kostyshak]

What is the correct way to check whether a buffer is hidden?

I am currently doing the following
bool const hidden = !(guiApp->currentView() && 
guiApp->currentView()->workArea(*b));

which works fine but I'm not sure if it's the right way.

Thanks,

Scott

Re: checking whether a buffer is hidden

[Jean-Marc Lasgouttes]

Le 15/07/12 09:14, Scott Kostyshak a écrit :

What is the correct way to check whether a buffer is hidden?

I am currently doing the following
bool const hidden = !(guiApp->currentView() &&
guiApp->currentView()->workArea(*b));

which works fine but I'm not sure if it's the right way.


This is the usual way, as ugly as it may seem.

JMarc

Re: questions and proposal regarding enum FuncAttribs

[Jean-Marc Lasgouttes]

Le 15/07/12 09:10, Scott Kostyshak a écrit :

I think theargument flag is not flexible enough to be useful.


Why not? The attached patch checks whether the LFUN being called in
GuiView.cpp has the Argument flag and is trying to use an empty
argument. If so, the command is disabled (from getStatus). I think it
is similar to checking NoBuffer. Why should checking for whether
there's no argument be treated differently from checking whether
there's no open buffer? Shouldn't both be done in getStatus and not
by each individual LFUN?

The patch adds the Argument property to a few LFUNs and removes some
now unnecessary case-specific checks. These are just for examples
though and the patch is not meant to be complete.


What I mean is that checking for "no argument" situation is only a small
part. We need at least to be able to say how many required and optional 
arguments are needed. Moreover, some arguments just use the remainder of 
the line. Also, to be useful, one needs to tell what the syntax is.

We could just be able to parse what we have in LyXAction.cpp, like:
 space-insert  []
telling that there is on required argument and one optional one.

NoBuffer is different, since it only describes the context in which the 
command can be used, which is much easier than its syntax.


JMarc

Line-styles for tables

[Julian Parker]

I think, it would be a great idea, if Lyx supports line-styles for
tables. Not too much. But besides the normal line a thicker line, a
dashed line and a dotted line, would be great.

Editing names for TOC, captions, ...

[Julian Parker]

It would be great, if the document-settings would also have a window,
where you can change the fixed names that Lyx uses for some elements.
E.g. "fig." instead of "figure", and the same for tables, TOC, etc.
Because often users have to use special terms that are given by the
university, the magazine,... I know this is possible with
LaTeX-syntax. But people who use Lyx do that because they don't want
to use LaTeX. A GUI for the naming of that elements would be
excellent.

Re: Line-styles for tables

[Richard Heck]

On 07/15/2012 10:37 AM, Julian Parker wrote:

I think, it would be a great idea, if Lyx supports line-styles for
tables. Not too much. But besides the normal line a thicker line, a
dashed line and a dotted line, would be great.


Please file an enhancement request for this.

rh

GUI for headers and footers with fancy page-style

[Julian Parker]

If you use fancy page-style you can use LaTeX-commands for what is
displayed in header (left, center, right) and footer (left, center,
right). And if a line is displayed or not. Because Lyx is for those
people who are no specialists for LaTeX it would be excellent, if
after activation of fancy page-style in the document-settings there
would be chechboxes for check/uncheck the lines and fields for all 6
positions where you can type your own text or choose "variables" like
page-number, date, section-title,... And when you use 2-page-layout
this shoule be automatically mirrored for the opposite pages. A GUI
for this often needed and by many beginners often wanted feature would
be a great step forward.

Re: Line-styles for tables

[Julian Parker]

2012/7/15 Richard Heck :
> On 07/15/2012 10:37 AM, Julian Parker wrote:
>>
>> I think, it would be a great idea, if Lyx supports line-styles for
>> tables. Not too much. But besides the normal line a thicker line, a
>> dashed line and a dotted line, would be great.
>>
> Please file an enhancement request for this.
>
> rh
>

How do I do that?

Re: Line-styles for tables

[Richard Heck]

On 07/15/2012 11:06 AM, Julian Parker wrote:

2012/7/15 Richard Heck :

On 07/15/2012 10:37 AM, Julian Parker wrote:

I think, it would be a great idea, if Lyx supports line-styles for
tables. Not too much. But besides the normal line a thicker line, a
dashed line and a dotted line, would be great.


Please file an enhancement request for this.

rh


How do I do that?


http://www.lyx.org/trac/newticket

You'll need to create a user profile if you don't have one.

Richard

Re: Editing names for TOC, captions, ...

[Richard Heck]

On 07/15/2012 10:40 AM, Julian Parker wrote:

It would be great, if the document-settings would also have a window,
where you can change the fixed names that Lyx uses for some elements.
E.g. "fig." instead of "figure", and the same for tables, TOC, etc.
Because often users have to use special terms that are given by the
university, the magazine,... I know this is possible with
LaTeX-syntax. But people who use Lyx do that because they don't want
to use LaTeX. A GUI for the naming of that elements would be
excellent.

This is harder than it seems, to do in a general way, since different 
LaTeX classes have quite

different ways of changing these things. But it's worth thinking about.

Richard

Bug: Zoom of editor doesn't zoom mathematical expression

[Julian Parker]

When you zoom in/out the editor (Alt+ / Alt-), everything is zoomed, but
 not the mathematical expressions. E.g. I have an x with a dash about it in
 the text (arithmetic mean) that is not zoomed in/out when I zoom in/out
 the editor.

Lyx 2.0.4 on Windows 7

Re: GUI for headers and footers with fancy page-style

[Richard Heck]

On 07/15/2012 10:55 AM, Julian Parker wrote:

If you use fancy page-style you can use LaTeX-commands for what is
displayed in header (left, center, right) and footer (left, center,
right). And if a line is displayed or not. Because Lyx is for those
people who are no specialists for LaTeX it would be excellent, if
after activation of fancy page-style in the document-settings there
would be chechboxes for check/uncheck the lines and fields for all 6
positions where you can type your own text or choose "variables" like
page-number, date, section-title,... And when you use 2-page-layout
this shoule be automatically mirrored for the opposite pages. A GUI
for this often needed and by many beginners often wanted feature would
be a great step forward.

This has been discussed in the past. The problem is this. Simply 
providing a text field in a
dialog where you can enter some LaTeX isn't terribly helpful. What would 
be more helpful
would be if there were a way you could enter the text like you do in 
LyX. There have been
attempts to do this, using a module, but it's a bit hackish. The other 
issue is that, in many
cases, what you want to enter won't be something LyX can easily provide, 
e.g., the page

number. So you'd end up using a lot of ERT.

Richard

Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Julian Parker]

When you have the pop-up list with paragraph-environments open and
want to jump to certain styles by typing the first letters, the pop-up
window shrinks smaller and there comes a scroll-bar when there are too
many hits. It's annoying to not see the whole list of hits, because
the unfiltered complete list is even longer. The length should be as
long as needed. Not longer and not shorter.

Lyx 2.0.4 on Windows 7

Re: GUI for headers and footers with fancy page-style

[Julian Parker]

2012/7/15 Richard Heck :
> On 07/15/2012 10:55 AM, Julian Parker wrote:
>>
>> If you use fancy page-style you can use LaTeX-commands for what is
>> displayed in header (left, center, right) and footer (left, center,
>> right). And if a line is displayed or not. Because Lyx is for those
>> people who are no specialists for LaTeX it would be excellent, if
>> after activation of fancy page-style in the document-settings there
>> would be chechboxes for check/uncheck the lines and fields for all 6
>> positions where you can type your own text or choose "variables" like
>> page-number, date, section-title,... And when you use 2-page-layout
>> this shoule be automatically mirrored for the opposite pages. A GUI
>> for this often needed and by many beginners often wanted feature would
>> be a great step forward.
>>
> This has been discussed in the past. The problem is this. Simply providing a
> text field in a
> dialog where you can enter some LaTeX isn't terribly helpful. What would be
> more helpful
> would be if there were a way you could enter the text like you do in LyX.
> There have been
> attempts to do this, using a module, but it's a bit hackish. The other issue
> is that, in many
> cases, what you want to enter won't be something LyX can easily provide,
> e.g., the page
> number. So you'd end up using a lot of ERT.
>
> Richard
>
>

Yes, I meant not fields for typing LaTeX again, but for typing text
you want and additonal the option to choose things like page-number,
date, section-title...

Would be great if it works some day.

Re: Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Richard Heck]

On 07/15/2012 02:17 PM, Julian Parker wrote:

When you have the pop-up list with paragraph-environments open and
want to jump to certain styles by typing the first letters, the pop-up
window shrinks smaller and there comes a scroll-bar when there are too
many hits. It's annoying to not see the whole list of hits, because
the unfiltered complete list is even longer. The length should be as
long as needed. Not longer and not shorter.

I see that. I'm not sure what causes it.

Richard

RE: questions and proposal regarding enum FuncAttribs

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 9:41 AM

Le 15/07/12 09:10, Scott Kostyshak a écrit :
>>> I think theargument flag is not flexible enough to be useful.
>>
>> Why not? The attached patch checks whether the LFUN being called in
>> GuiView.cpp has the Argument flag and is trying to use an empty
>> argument. If so, the command is disabled (from getStatus). I think it
>> is similar to checking NoBuffer. Why should checking for whether
>> there's no argument be treated differently from checking whether
>> there's no open buffer? Shouldn't both be done in getStatus and not
>> by each individual LFUN?
>>
>> The patch adds the Argument property to a few LFUNs and removes some
>> now unnecessary case-specific checks. These are just for examples
>> though and the patch is not meant to be complete.

>What I mean is that checking for "no argument" situation is only a small
>part. We need at least to be able to say how many required and optional
>arguments are needed. Moreover, some arguments just use the remainder of
>the line. Also, to be useful, one needs to tell what the syntax is.
>We could just be able to parse what we have in LyXAction.cpp, like:
>  space-insert  []
>telling that there is on required argument and one optional one.

>NoBuffer is different, since it only describes the context in which the
>command can be used, which is much easier than its syntax.

Ah, I see what you mean. Do you have an idea for the best way to parse 
LyXAction.cpp? Would any of the following strategies work well?
(1) Parse LyXAction.cpp when building and store a map in lib and then load that 
map on runtime

Is parsing LFUNs.lyx a bad idea? This would allow

(2) Parse LFUNs.lyx during configure and store a map in lib
(3) Parse LFUNs.lyx on run-time

If this is a conversation best left for another time, let me know.

Thanks,

Scott

doxygen command for LyXAction.cpp --> LFUNs.lyx

[Scott Kostyshak]

How do I turn LyXAction.cpp into LFUNs.lyx?

Thanks,

Scott

[PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

Attached is a patch that implements LFUN_BUFFER_FORALL, which applies a passed 
LFUN command to all buffers. My motivation was that I sometimes need to do the 
same thing in all of the buffers that I have open. Another advantage of 
implementing this LFUN is that it allows buffer-specific settings to be made 
global. For example, if a user wants to be able to toggle track changes for all 
documents, he can do that (similarly for read only).

Here are some sample uses:

Close all Notes in all documents: \n
buffer-forall inset-forall Note inset-toggle close \n
Toggle change tracking on all documents: \n
buffer-forall changes-track \n
Toggle read-only for all documents: \n
buffer-forall buffer-toggle-read-only \n
Show statistics for each document: \n
buffer-forall statistics \n
Activate the branch named "Solutions" in all documents: \n
buffer-forall branch-activate Solutions \n

I tested several potential special uses, such as nested calls, repeated calls, 
uses with other special commands like command-sequence, and uses with LFUNs 
that create and close buffers. The following all work fine:
buffer-forall buffer-forall self-insert testing
repeat 3 buffer-forall repeat 3 self-insert 1
buffer-forall buffer-close
buffer-forall buffer-new
buffer-forall inset-forall Note inset-toggle close

When a buffer-forall command is issued and the command passed to it is disabled 
on one of the buffers, currently buffer-forall continues on to the other 
buffers and tries to execute the passed command. I think this is the correct 
behavior. Alternatively, buffer-forall could stop whenever it finds a buffer 
where the command is disabled.

buffer-forall allows for an optional flag, includehidden. If includehidden is 
not specified, hidden buffers are ignored. If includehidden is specified, the 
action is applied to the hidden buffers and then they are hidden again. I might 
extend this option to allow for onlyhidden, which would not apply the command 
to non-hidden buffers. This would allow, e.g., to close all hidden buffers.

Any comments?

Thanks,

Scott
diff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..a066234 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..bed84c6 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3139,27 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", ReadOnly, Buffer },
 /*!
+ * \var lyx::FuncCode lyx::LFUN_BUFFER_FORALL
+ * \li Action: Applies a command to all non-hidden buffers, optionally including hidden buffers.
+ * \li Syntax: buffer-forall [] 
+ * \li Params: : The command that is to be applied to the buffers.
+   : 'includehidden' to iterate over hidden buffers.
+Otherwise they are skipped
+ * \li Sample: Close all Notes in all non-hidden documents: \n
+	   buffer-forall inset-forall Note inset-toggle close \n
+   Toggle change tracking on all documents: \n
+	   buffer-forall includehidden changes-track \n
+   Toggle read-only for all non-hidden documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall includehidden statistics \n
+   Activate the branch named "Solutions" in all non-hidden documents: \n
+	   buffer-forall branch-activate Solutions \n
+ * \li Origin: scottkostyshak, 15 Jul 2012
+ * \endvar
+ */
+		{ LFUN_BUFFER_FORALL, "buffer-forall", ReadOnly | Argument, Buffer },
+/*!
  * \var lyx::FuncCode lyx::LFUN_BUFFER_WRITE_ALL
  * \li Action: Save all changed documents.
  * \li Syntax: buffer-write-all
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index ca63632..bd06441 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -1679,6 +1683,7 @@ bool GuiView::getStatus(FuncRequest const & cmd, FuncStatus & flag)
 		break;
 	}
 
+	case LFUN_BUFFER_FORALL:
 	case LFUN_BUFFER_WRITE_AS:
 	case LFUN_BUFFER_EXPORT_AS:
 		enable = doc_buffer;
@@ -3332,6 +3337,54 @@ void GuiView::dispatch(FuncRequest const & cmd, DispatchResult & dr)
 			gotoNextOrPreviousBuffer(PREVBUFFER);
 			break;
 
+		case LFUN_BUFFER_FORALL: {
+			Buffer * const buf = ()->buffer();
+			if (!buf)
+break;
+
+			bool processHidden = false;
+			string commandToRun = argument;
+			if (argument.substr(0,13) == "includehidden") {
+processHidden = true;
+commandToRun = argument.substr(14, argument.size());
+			}
+
+			docstring const hiddenOrNot = processHidden ? _("all hidden and non-hidden")

RE: checking whether a buffer is hidden

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 9:34 AM

Le 15/07/12 09:14, Scott Kostyshak a écrit :
>> What is the correct way to check whether a buffer is hidden?
>>
>> I am currently doing the following
>> bool const hidden = !(guiApp->currentView() &&
>> guiApp->currentView()->workArea(*b));
>>
>> which works fine but I'm not sure if it's the right way.

>This is the usual way, as ugly as it may seem.

Could I add a buffer member function that does this or is it too uncommon?

Scott

Re: [LyX master] Fix bug #7741: incorrect locale when starting R from LyX?

[Jean-Marc Lasgouttes]

Le 15/07/12 22:30, Jean-Marc Lasgouttes a écrit :

commit 16fd47ad8f5d78a3b7266520b0868c1e2bd0dcac
Author: Jean-Marc Lasgouttes 
Date:   Sun Jul 15 22:22:10 2012 +0200

 Fix bug #7741: incorrect locale when starting R from LyX?

 The goal here is to get rid of the old code that modified variables
 LANGUAGE and LC_ALL, therefore creating the problems mentionned
 in the ticket.

 In the new system, there is no explicit "GUI" message handler, that
 needs to be reset at each language change. Instead, getGuiMessages
 calls getMessages with the correct parameter. This allows to simplify
 greatly the code and to remove a lot of old cruft.


This is basically a rewrite of the code that sets GUI language via 
lyxrc. The code is now much simpler in my opinion, which mitigates the risk.


I would appreciate feedback on how this work on linux, mac os and windows.

Since bug #7741 is very annoying for all external programs which do not 
like having weird locale settings, I think this should eventually go to 
branch.


JMarc

[PATCH] LFUN_BUFFER_EXPORT_ALL & File menu reorganization

[Scott Kostyshak]

Attached is a patch that does the following:

(1) Creates LFUN_BUFFER_EXPORT_ALL. My motivation was that I'm often working on 
several problem sets or notes at once and would like to export all of them to 
pdf.

(2) Reorganizes the File menu: The current implementation places import next to 
export. Although this is logical in some sense because the two are opposites, I 
think it would make more sense to place export next to save because the two 
operations are similar. Someone going to the menu to save might realize that 
what he really wants to do is export. Similarly, I suggest moving Import next 
to Open.

I suggest that we have the file menu walk the user through a session: The first 
part of the File menu relates to getting started after you open LyX. You're 
either going to start a new buffer, open a file or import a file. The next part 
has to do with saving your work (either with one of the Saves or one of the 
Exports). This segues into Print and Fax, which in an abstract sense are like 
exporting. In the final stage of your session, you will either Close or Exit.

(3) I moved the Export As out of the Export submenu and I added an Export All 
entry. This makes saving and exporting consistent: Just as there are Save, Save 
As, and Save All, there are now Export, Export As, and Export All.

currently, this patch depends on LFUN_BUFFER_FORALL, which I am suggesting 
here: [1]. It might be nice to allow a directory path to be given to 
LFUN_BUFFER_EXPORT_ALL as an argument. To implement this, there are two options:
(a) stop using LFUN_BUFFER_FORALL and loop through the buffers manually, 
calling LFUN_BUFFER_EXPORT and passing it the path and filename.
(b) modify LFUN_BUFFER_EXPORT to accept a path as an argument. If a path is 
given as the argument, the default should be to use the buffer's filename.

LFUN_BUFFER_EXPORT_ALL as implemented in this patch does not work with the 
"custom" argument (which LFUN_BUFFER_EXPORT_ALL does support). If "custom" is 
passed, then the first buffer processed is exporting with the chosen format but 
it stops there. I will add support for custom if everything else looks ok for 
this LFUN.

Any comments?

Thanks,

Scott

[1] http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg174669.html
diff --git a/lib/ui/stdmenus.inc b/lib/ui/stdmenus.inc
index b7e1f03..8958236 100644
--- a/lib/ui/stdmenus.inc
+++ b/lib/ui/stdmenus.inc
@@ -44,25 +44,27 @@ Menuset
 	Menu "file"
 		Item "New|N" "buffer-new"
 		Item "New from Template...|m" "buffer-new-template"
+		Item "New Window|W" "window-new"
 		Item "Open...|O" "file-open"
 		Submenu "Open Recent|t" "file_lastfiles"
+		Submenu "Import|I" "file_import"
 		Separator
-		Item "Close|C" "buffer-close"
-		Item "Close All" "buffer-close-all"
-		Item "Save|S" "buffer-write"
-		Item "Save As...|A" "buffer-write-as"
-		Item "Save All|l" "buffer-write-all"
 		Item "Revert to Saved|R" "buffer-reload"
 		Submenu "Version Control|V" "file_vc"
 		Separator
-		Submenu "Import|I" "file_import"
+		Item "Save|S" "buffer-write"
+		Item "Save As...|A" "buffer-write-as"
+		Item "Save All|l" "buffer-write-all"
 		Submenu "Export|E" "file_export"
+		Item "Export As..." "buffer-export-as"
+		Submenu "Export All" "file_export_all"
+		Separator
 		Item "Print...|P" "dialog-show print"
 		OptItem "Fax...|F" "buffer-export fax"
 		Separator
-		Item "New Window|W" "window-new"
+		Item "Close|C" "buffer-close"
+		Item "Close All" "buffer-close-all"
 		Item "Close Window|d" "window-close"
-		Separator
 		Item "Exit|x" "lyx-quit"
 	End
 
@@ -87,11 +89,15 @@ Menuset
 	End
 
 	Menu "file_export"
-		Item "Export As...|s" "buffer-export-as"
 		ExportFormats
 		Item "More Formats & Options...|O" "buffer-export custom"
 	End
 
+	Menu "file_export_all"
+		ExportAllFormats
+		Item "More Formats & Options...|O" "buffer-export custom"
+	End
+
 #
 # EDIT MENU
 #
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index cabfe63..9d3fc00 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -2165,6 +2165,7 @@ bool Buffer::getStatus(FuncRequest const & cmd, FuncStatus & flag)
 			// FIXME: Nothing to check here?
 			break;
 
+		case LFUN_BUFFER_EXPORT_ALL:
 		case LFUN_BUFFER_EXPORT: {
 			docstring const arg = cmd.argument();
 			if (arg == "custom") {
@@ -2247,6 +2248,12 @@ void Buffer::dispatch(FuncRequ

Re: questions and proposal regarding enum FuncAttribs

[Jean-Marc Lasgouttes]

Le 15/07/12 21:05, Scott Kostyshak a écrit :

Ah, I see what you mean. Do you have an idea for the best way to
parse LyXAction.cpp? Would any of the following strategies work
well?


I think the best way would be to change LyXAction.cpp such that the 
documentation is in string variables "action", "syntax" and "params" 
(added to the struct). They will therefore be available to LyX itself to 
provide online help if we want to. This would mean that the script that 
created LFUNs.lyx will need to be updated (or LyX itself could create 
the file, but this is admitedly more difficult...).



If this is a conversation best left for another time, let me know.


No problem, I have some time now. But doing this is probably a lot of work.

JMarc

Re: doxygen command for LyXAction.cpp --> LFUNs.lyx

[Jean-Marc Lasgouttes]

Le 15/07/12 21:07, Scott Kostyshak a écrit :

How do I turn LyXAction.cpp into LFUNs.lyx?


I think you need development/tools/gen_lfuns.py.

JMarc

Re: checking whether a buffer is hidden

[Jean-Marc Lasgouttes]

Le 15/07/12 22:37, Scott Kostyshak a écrit :

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 9:34 AM

Le 15/07/12 09:14, Scott Kostyshak a écrit :

What is the correct way to check whether a buffer is hidden?

I am currently doing the following
bool const hidden = !(guiApp->currentView() &&
guiApp->currentView()->workArea(*b));

which works fine but I'm not sure if it's the right way.



This is the usual way, as ugly as it may seem.


Could I add a buffer member function that does this or is it too uncommon?


The problem is that it needs to be a member function of GuiApplication. 
The buffer itself has no reason to know that it is hidden.


In what part of code do you need to know this information?

I am not sure that the notion of hidden buffer is correctly defined 
(when are they "visible"?)


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 15/07/12 22:35, Scott Kostyshak a écrit :

Attached is a patch that implements LFUN_BUFFER_FORALL, which applies a
passed LFUN command to all buffers. My motivation was that I sometimes
need to do the same thing in all of the buffers that I have open.
Another advantage of implementing this LFUN is that it allows
buffer-specific settings to be made global. For example, if a user wants
to be able to toggle track changes for all documents, he can do that
(similarly for read only).


This looks like a useful feature.


When a buffer-forall command is issued and the command passed to it is
disabled on one of the buffers, currently buffer-forall continues on to
the other buffers and tries to execute the passed command. I think this
is the correct behavior. Alternatively, buffer-forall could stop
whenever it finds a buffer where the command is disabled.


You current choice looks good.


buffer-forall allows for an optional flag, includehidden. If
includehidden is not specified, hidden buffers are ignored. If
includehidden is specified, the action is applied to the hidden buffers
and then they are hidden again. I might extend this option to allow for
onlyhidden, which would not apply the command to non-hidden buffers.
This would allow, e.g., to close all hidden buffers.



Any comments?


See below in the patch.

JMarc

+   case LFUN_BUFFER_FORALL: {
+   Buffer * const buf = ()->buffer();
+   if (!buf)
+   break;


Why is this test needed? The current buffer has nothing to do with 
buffer-forall. Moreover, this code should not be in GuiView, but in 
GuiApplication, since the function is at application level.



+
+   bool processHidden = false;
+   string commandToRun = argument;
+   if (argument.substr(0,13) == "includehidden") {
+   processHidden = true;
+   commandToRun = argument.substr(14, 
argument.size());
+   }


Please do not use string methods by hand. FuncRequest object have 
methods getArg and getLongArg that work very well for these uses.



+
+   docstring const hiddenOrNot = processHidden ? _("all hidden and 
non-hidden") : _("all non-hidden");
+   dr.setMessage(bformat(_("Applied the command \"%1$s\" to 
%2$s buffers"), from_utf8(commandToRun), hiddenOrNot));


Please use two complete sentences (one for hidden and one for not 
hidden). Your sentences may be difficult to translate in some languages.



+
+   Buffer * const last = theBufferList().last();
+   Buffer * b = theBufferList().first();
+   Buffer * nextBuf = 0;
+   // We cannot use a for loop as the buffer list cycles.


I know this code is taken from somewhere else, but I am not sure why you 
can't use BufferList::begin()/end(). The only problem is maybe what 
happens if the buffer is deleted by the lfun.



+   while (true) {
+   if (b != last)
+   nextBuf = theBufferList().next(b); 
//get next now bc LFUN might close current
+
+   bool const hidden = !(guiApp->currentView() && 
guiApp->currentView()->workArea(*b));
+   if (hidden) {
+   if (processHidden) {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   GuiWorkArea * const wa = 
currentWorkArea();
+   wa->view().hideWorkArea(wa);
+   }
+   }
+
+   else {
+   setBuffer(b);
+   
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
+   }


if (!hidden || processHidden) {
setBuffer(b);
lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
if (hidden) {
GuiWorkArea * const wa = currentWorkArea();
wa->view().hideWorkArea(wa);
}
}

The lookup of commandToRun should be done at the place where the 
arguments are parsed.

Re: questions and proposal regarding enum FuncAttribs

[Pavel Sanda]

Scott Kostyshak wrote:
> Why not? The attached patch checks whether the LFUN being called in 
> GuiView.cpp

This works with VC_COMMAND. IIRC there are more possible entry points for LFUN 
execution,
I'm not sure where all go through GuiView::getStatus, worth to check.

> Is parsing LFUNs.lyx a bad idea? This would allow

LFUNs.lyx generation is very fragile stuff without error checking when 
something goes wrong.

Jean-Marc Lasgouttes wrote:
> I think the best way would be to change LyXAction.cpp such that the 
> documentation is in string variables "action", "syntax" and "params" (added 
> to the struct).

I'm not saying we can't go this route, just note that the current format was 
forced in order
to allow doxygen documentation work (it was in the days prior to LFUNs.lyx 
birth).

Pavel

Re: questions and proposal regarding enum FuncAttribs

[Jean-Marc Lasgouttes]

Le 15/07/12 23:24, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I think the best way would be to change LyXAction.cpp such that the
documentation is in string variables "action", "syntax" and "params" (added
to the struct).


I'm not saying we can't go this route, just note that the current format was 
forced in order
to allow doxygen documentation work (it was in the days prior to LFUNs.lyx 
birth).


What would you propose?

JMarc

Re: Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Pavel Sanda]

Richard Heck wrote:
> I see that. I'm not sure what causes it.

This is old timer and IIRC there was even committed attempt to fix it from 
Stefan long time ago.

Pavel

Re: Closing split views from the right click menu

[Andrew Parsloe]

On 15/07/2012 2:18 p.m., Richard Heck wrote:

On 07/14/2012 07:08 PM, Andrew Parsloe wrote:

I'm constantly working with a split window, generally left and right
views. Closing one of these views to get a single main window again
means going to the View menu and clicking on Close Current View, not a
big deal but, repeated many times, a minor irritation. And there's no
built-in shortcut indicated. It would be convenient if Close Current
View could be added to the right-click menu when the cursor is in one
of the split views. On the current right-click menu, it would fit
naturally at the bottom beside Fullscreen Mode.


Done for trunk. Should be in 2.0.5.

If you want to add this to your current installation, find
stdcontext.inc, and add:
Item "Close Current View" "close-tab-group"
at the appropriate place.

Richard



Thank you. I've made the addition to stdcontext.inc and it works perfectly.

Andrew

Re: Bug: Too small list of paragraphs/environments when you filter with shortcuts

[Pavel Sanda]

Pavel Sanda wrote:
> Richard Heck wrote:
> > I see that. I'm not sure what causes it.
> 
> This is old timer and IIRC there was even committed attempt to fix it from 
> Stefan long time ago.

I think these are relevant: r23644,r23654

> Pavel

Re: doxygen command for LyXAction.cpp --> LFUNs.lyx

[Pavel Sanda]

Scott Kostyshak wrote:
> How do I turn LyXAction.cpp into LFUNs.lyx?

Doxygen generation is not related to LFUNs.lyx.
- doxygen: make doxydoc
- LFUNs.lyx: make lfundoc

Pavel

Re: [PATCH] LFUN_BUFFER_EXPORT_ALL & File menu reorganization

[Pavel Sanda]

Scott Kostyshak wrote:

> Any comments?

While I think adding LFUNs you proposed makes sense, I don't think it's good
idea to add this new stuff into the File menu (at most poke them away to
some submenu). I would rather see the menu shrink than expand (e.g. Print).

Regarding the fact how any menu reorganizations tend to trigger long flames
it maybe wise to post such proposal independently to patches with real stuff
so it gets in independently ;)

Pavel

Re: [LyX master] Fix bug #7741: incorrect locale when starting R from LyX?

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> I would appreciate feedback on how this work on linux, mac os and windows.

I tested that setting LC_MESSAGES still works on Linux :)
Pavel

Re: questions and proposal regarding enum FuncAttribs

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 15/07/12 23:24, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
>>> I think the best way would be to change LyXAction.cpp such that the
>>> documentation is in string variables "action", "syntax" and "params" (added
>>> to the struct).
>>
>> I'm not saying we can't go this route, just note that the current format was
>> forced in order to allow doxygen documentation work (it was in the days
>> prior to LFUNs.lyx birth).
>
> What would you propose?

It depends what are the goals. If the point is just to introduce argument flag
the price looks high (but no hard opinion if Scott feels like to fix all the
follow-ups).

If the goal is to allow the online documentation to be available via some
tooltips or whatever, then for consistency reasons we will be asked for
translations via gettext mechanism, no? This is lot of work on the shoulders
of translation teams for quite an esoteric part of the LyX functionality.

Pavel

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 5:14 PM

>> + case LFUN_BUFFER_FORALL: {
>> + Buffer * const buf = ()->buffer();
>> + if (!buf)
>> + break;

>Why is this test needed? The current buffer has nothing to do with
>buffer-forall.

I use buf when I switch back to the current buffer after buffer-forall is done, 
assuming the current buffer still exists (that is, that the LFUN did not close 
it). The check is to make sure there is at least a buffer open, but as long as 
there is a check induced because of not having the NoBuffer property, I can 
take this out.

>Moreover, this code should not be in GuiView, but in
>GuiApplication, since the function is at application level.

ok, I will move it after the other issues are cleared up.

>> +
>> + bool processHidden = false;
>> + string commandToRun = argument;
>> + if (argument.substr(0,13) == "includehidden") {
>> + processHidden = true;
>> + commandToRun = argument.substr(14, 
>> argument.size());
>> + }

> Please do not use string methods by hand. FuncRequest object have
> methods getArg and getLongArg that work very well for these uses.

Done.

>> +
>> + docstring const hiddenOrNot = processHidden ? _("all 
>> hidden and non-hidden") : _("all non-hidden");
>> + dr.setMessage(bformat(_("Applied the command \"%1$s\" 
>> to %2$s buffers"), from_utf8(commandToRun), hiddenOrNot));

>Please use two complete sentences (one for hidden and one for not
>hidden). Your sentences may be difficult to translate in some languages.

Done. It is three sentences now because I am allowing three options: "visible" 
(default), "hidden", and "both".

>> +
>> + Buffer * const last = theBufferList().last();
>> + Buffer * b = theBufferList().first();
>> + Buffer * nextBuf = 0;
>> + // We cannot use a for loop as the buffer list cycles.

>I know this code is taken from somewhere else, but I am not sure why you
>can't use BufferList::begin()/end(). The only problem is maybe what
>happens if the buffer is deleted by the lfun.

Right, with BufferList::begin()/end() I don't think buffer-forall would work 
with LFUNs such as buffer-close. Should I still do it with 
BufferList::begin()/end() and blacklist certain functions? Or just let the user 
be responsible? In the attached patch I did not change it to use 
BufferList::begin()/end().


>> + while (true) {
>> + if (b != last)
>> + nextBuf = theBufferList().next(b); 
>> //get next now bc LFUN might close current
>> +
>> + bool const hidden = !(guiApp->currentView() && 
>> guiApp->currentView()->workArea(*b));
>> + if (hidden) {
>> + if (processHidden) {
>> + setBuffer(b);
>> + 
>> lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
>> + GuiWorkArea * const wa = 
>> currentWorkArea();
>> + wa->view().hideWorkArea(wa);
>> + }
>> + }
>> +
>> + else {
>> + setBuffer(b);
>> + 
>> lyx::dispatch(FuncRequest(lyxaction.lookupFunc(commandToRun)));
>> + }

>The lookup of commandToRun should be done at the place where the
>arguments are parsed.

Done.

Please see the attached patch.

Thank you for your help,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..2c99432 100644
--- a/src/FuncCode.h
+++ b/src/FuncCode.h
@@ -452,6 +452,7 @@ enum FuncCode
 	// 350
 	LFUN_CLIPBOARD_PASTE_SIMPLE,	// tommaso, 20111028
 	LFUN_IPA_INSERT,// spitz, 20120305
+	LFUN_BUFFER_FORALL, // scottkostyshak, 20120715
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..ff3f7fe 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,26 @@ void LyXAction::init()
  */
 		{ LFUN_BUFFER_WRITE_AS, "buffer-write-as", Read

RE: checking whether a buffer is hidden

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Sunday, July 15, 2012 4:54 PM

>The problem is that it needs to be a member function of GuiApplication.
>The buffer itself has no reason to know that it is hidden.

>In what part of code do you need to know this information?

I use this in LFUN_BUFFER_FORALL.

>I am not sure that the notion of hidden buffer is correctly defined
>(when are they "visible"?)

ok. Sounds like it's best to leave things how they are.

Thanks,

Scott

RE: doxygen command for LyXAction.cpp --> LFUNs.lyx

[Scott Kostyshak]

From: Pavel Sanda [sa...@lyx.org]
Sent: Sunday, July 15, 2012 6:34 PM

>Doxygen generation is not related to LFUNs.lyx.
> - doxygen: make doxydoc
> - LFUNs.lyx: make lfundoc

Thanks,

Scott

RE: [PATCH] LFUN_BUFFER_EXPORT_ALL & File menu reorganization

[Scott Kostyshak]

From: Pavel Sanda [sa...@lyx.org]
Sent: Sunday, July 15, 2012 7:19 PM

>While I think adding LFUNs you proposed makes sense, I don't think it's good
>idea to add this new stuff into the File menu (at most poke them away to
>some submenu). I would rather see the menu shrink than expand (e.g. Print).

>Regarding the fact how any menu reorganizations tend to trigger long flames
>it maybe wise to post such proposal independently to patches with real stuff
>so it gets in independently ;)

ok, I'll see if there are other comments. Otherwise I'll take out the 
reorganization changes and just propose LFUN_EXPORT_ALL. I'm not sure where to 
put Export All if not in the File menu. To have that submenu in the submenu of 
Export does not seem right either.

Scott