RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, July 19, 2012 4:15 AM

Le 19/07/2012 04:46, Scott Kostyshak a écrit :
 If there are more windows open, buffer-forall iterates over the
 buffers in the current window, treating a buffer as hidden as
 designated in the current window.

It would be nice to rephrase the status message to reflect the situation
like maybe
Applied the following command to all visible buffers in this window: 
(or something else, I am not the native english speaker here)

That sounds good. I put the active window instead of this window because 
(at least in Linux) if you have messages open on a window, open a new window, 
and execute a command in the mini-buffer of the new window, the message box of 
the old window will show that command and its output. Thus, the this would 
refer to the incorrect window. Attached is the updated patch.

Note however that on the Mac tabs are not used by default and that each
files is in its own window (there is an option for that). buffer-forall
is just useless in this case, isn't it?

Interesting, I didn't know this. The Open Documents in Tabs is not checked by 
default for Macs? I wonder how it is on Windows and what other settings are 
different across platforms. Where does this happen in the source code?

You are right that buffer-forall doesn't do anything useful by default. 
However, when you create a new window the buffers in the previous window are 
available as hidden buffers in the new window. Thus, buffer-forall both 
LFUN-COMMAND would be useful because it iterates over the hidden buffers (as 
defined in the active window) as well. My feeling now is that we should have 
both as the default instead of visible. What do you think?

This could lead to behavior that is a little strange, such as if you run 
`buffer-forall both statistics` with multiple windows open. You will see tabs 
appear. However, I think that's a special case.

Thanks,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..a1cf57f 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, 20120720
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..7a4ec33 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ 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 in the active window.
+ * \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 tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall both statistics \n
+   Activate the branch named Solutions in all visible documents: \n
+	   buffer-forall branch-activate Solutions \n
+   Export all visible documents to PDF (pdflatex): \n
+	   buffer-forall buffer-export pdf2 \n
+ * \li Origin: scottkostyshak, 20 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/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index b855067..94581a3 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -38,6 +38,7 @@
 #include Font.h
 #include FuncRequest.h
 #include FuncStatus.h
+#include GuiWorkArea.h
 #include Intl.h
 #include KeyMap.h
 #include Language.h
@@ -1077,6 +1078,15 @@ bool GuiApplication::getStatus(FuncRequest const  cmd, FuncStatus  flag) const
 		enable = true;
 		break;
 
+	case LFUN_BUFFER_FORALL: {
+		if (!currentView() || !currentView()-currentBufferView() || !currentView()-currentBufferView()-buffer()) {
+			flag.message(from_utf8(N_(Command not allowed without any visible document in the active window)));
+			flag.setEnabled(false);
+		}
+		break;
+	}
+
+
 	default:
 		return false;
 	}
@@ -1592,6 +1602,63 @@ void GuiApplication::dispatch(FuncRequest const  cmd, DispatchResult  dr)
 		break;
 	}
 
+	case LFUN_BUFFER_FORALL: {
+		GuiView * gv = currentView();
+		Buffer * const buf = gv-currentBufferView()-buffer

Re: Re: [LyX master] Read list of translated languages from a file

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 00:49:47, schrieb Pavel Sanda sa...@lyx.org
 Jean-Marc Lasgouttes wrote:
  How exactly is this list assembled? Just presence of .gmo in compiled tree
  is enough? This could break on linux installs where only subset of 
  compiled
  translation is installed.
 
  I use te variable CATALOGS which is built in po.m4 juste before generating 
  the po/Makefile. The variable cannot be subst'd using @CATALOGS@ in 
  Makefile.am, therefore it is easier to generate the file at configure time 
  (after all we already generate other files like lyxrc.dist).
 
 I think this will break at my distro. What is the damage in case LyX is 
 installed
 with only few .gmo files while installed_translations contains much more of 
 them?
 
 Pavel

Try it, no problem. And so long you do not try to change the GUI-language, you 
see no difference.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Re: [LyX master] Read list of translated languages from a file

[Kornel Benko]

Am Donnerstag, 19. Juli 2012 um 23:36:01, schrieb Jean-Marc Lasgouttes 
lasgout...@lyx.org
 Le 19/07/12 14:41, Kornel Benko a écrit :
  In the new scheme, autotools install a file
  lib/installed_translations that contains a list of installed languages
  (the .gmo files that got installed). This file is read
 
  How should automake reflect changes in the po-files? As I understood,
  installed_translations is created only during configure.
 
  1.) Shouldn't this step go to make?
 
 The Makefile variable CATALOGS, which tells which languages to 
 installed, is fixed at configure time, and it is not really meant to be
 changed at make time. The recommended way to handle this problem is to
 set the LINGUAS environment vatiable for, say, fr de before running 
 configure.
 
  2.) Should cmake mimic this behaviour?
 
 Yes, I think it is good to have the same behaviour for both systems.
 
 JMarc
 

OK. Done.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 20/07/2012 00:49, Pavel Sanda a écrit :

I use te variable CATALOGS which is built in po.m4 juste before generating
the po/Makefile. The variable cannot be subst'd using @CATALOGS@ in
Makefile.am, therefore it is easier to generate the file at configure time
(after all we already generate other files like lyxrc.dist).


I think this will break at my distro. What is the damage in case LyX is 
installed
with only few .gmo files while installed_translations contains much more of 
them?


The damage is that you will see english instead of your fancy language 
in the case.


But tell us more about your distro. What does it do that could break 
everything?


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 08:12, Scott Kostyshak a écrit :

That sounds good. I put the active window instead of this window
because (at least in Linux) if you have messages open on a window,
open a new window, and execute a command in the mini-buffer of the
new window, the message box of the old window will show that command
and its output. Thus, the this would refer to the incorrect window.
Attached is the updated patch.


Very good. I'll commit that.


Interesting, I didn't know this. The Open Documents in Tabs is not
checked by default for Macs? I wonder how it is on Windows and what
other settings are different across platforms. Where does this happen
in the source code?


Nowhere :) We use a file lyxrc.dist that can be changed by the packager 
to initialize some setting. On the mac it is created from

development/MacOSX/lyxrc.dist.in


You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible 
nowhere) with the ones that are visible in some other window. I think 
these two things are very different from a user point of view.


Conclusion: you should not ask only the current view for visibleness 
(?), but all views.


JMarc

building lyx on osx

[Edwin Leuven]

hi guys, 

i recently got a mac, and am now trying to build lyx using Xcode  cmake. 

there seems to be some problem with linking iconv though. 

i was wondering whether there are some recent build instructions for osx?

also, did someone manage to make lyx look decent on a retina display?

thanks, edwin

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 10:45, Jean-Marc Lasgouttes a écrit :

You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible
nowhere) with the ones that are visible in some other window. I think
these two things are very different from a user point of view.

Conclusion: you should not ask only the current view for visibleness
(?), but all views.


I have pushed the patch to master now. Thanks for te patch (and for 
going through all the iterations).


I pushed the patch now because I will go in vacation this evening and 
did not want to let it in a limbo, but I think you should think again 
about multiple views.


* the default should be all buffers visible in a view

* It may be better to force the use of the first argument, because as it 
is this argument is not well defined. You could use * for all buffers, 
as in inset-forall


* if the action closes the only open buffer of the lyxview, does it crash?

* if you want to handle multiple view, I suspect that the logic of you 
main loop will have to change. An alternative would be to invoke 
BufferView::dispatch or even Buffer::dispatch, but this is restrictive.


JMarc

Captions for inserted PDFs do not display correctly

[Carlos Fiyero]

When you insert an external PDF-file (e.g. for a table where you have
to keep the original layout) into a floating element for give it a
caption, the inserted PDF looks nice, but the caption isn't displayed
above or under the inserted PDF but anywhere in the PDF (like a second
layer). The use of boxes or anything like that doesn't help. (I'm
using Lyx 2.0.4 on Windows 7.) This bug should be fixed very soon,
because that's not only a bug for better usability but for better
documents.

Re: new function request

[Jean-Marc Lasgouttes]

Le 07/07/2012 12:31, Kornel Benko a écrit :

Hi,

very often I use more than 1 window while editing a file in lyx.

This is handy, but starting with window-new forces me always also

to use File-Open...

I'd like to have a function like window-new-current-buffer, which
behaves like

in emacs File-New Frame, e.g. creates a new window with the current
buffer displayed.


Note thatere is a checkbox in prefs for opening new files in new windows 
rather than tabs.


JMarc

Captions for images and tables not justified correctly

[Carlos Fiyero]

When you make a floating element with an image or a table, you can
justify the image/table right, left or centered. But the caption
always remains centered. It should be automatically change it
depending of the position of the image/table or it should be possible
manually. (I'm using Lyx 2.0.4 on Win 7.)

Re: Re: new function request

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 11:20:25, schrieb Jean-Marc Lasgouttes 
lasgout...@lyx.org
 Le 07/07/2012 12:31, Kornel Benko a écrit :
  Hi,
 
  very often I use more than 1 window while editing a file in lyx.
 
  This is handy, but starting with window-new forces me always also
 
  to use File-Open...
 
  I'd like to have a function like window-new-current-buffer, which
  behaves like
 
  in emacs File-New Frame, e.g. creates a new window with the current
  buffer displayed.
 
 Note thatere is a checkbox in prefs for opening new files in new windows 
 rather than tabs.
 
 JMarc

That is nice. Though not exactly fitting to the desired feature.
I like windows _and_ tabs.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: building lyx on osx

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 11:05:27, schrieb Edwin Leuven e.leu...@gmail.com
 hi guys, 
 
 i recently got a mac, and am now trying to build lyx using Xcode  cmake. 
 
 there seems to be some problem with linking iconv though. 

What problems? Is the iconv lib not found? Or iconv header file?
#egrep -i iconv CMakeCache.txt (on ubuntu, but should be similar)
--ICONV_HEADER:FILEPATH=/usr/include/iconv.h
   ICONV_INCLUDE_DIR:PATH=/usr/include
   ICONV_LIBRARY:STRING=
   //Test HAVE_ICONV_CONST
   HAVE_ICONV_CONST:INTERNAL=
   //Have function iconv
   HAVE_ICONV_IN_LIBC:INTERNAL=1
   //ADVANCED property for variable: ICONV_INCLUDE_DIR
   ICONV_INCLUDE_DIR-ADVANCED:INTERNAL=1
   //ADVANCED property for variable: ICONV_LIBRARY
   ICONV_LIBRARY-ADVANCED:INTERNAL=1


 i was wondering whether there are some recent build instructions for osx?
 
 also, did someone manage to make lyx look decent on a retina display?
 
 thanks, edwin

I have no mac here, so don't know.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: building lyx on osx

[Edwin Leuven]

On Jul 20, 2012, at 12:20 , Kornel Benko wrote:
 Am Freitag, 20. Juli 2012 um 11:05:27, schrieb Edwin Leuven 
 e.leu...@gmail.com
  there seems to be some problem with linking iconv though. 
  
 What problems?

i pasted the error message below. 

looks like iconv is not 64bit

ed.



Ld /Users/edwin/devel/lyx-build/bin/Debug/lyxclient2.1 normal x86_64
cd /Users/edwin/devel/lyx
setenv MACOSX_DEPLOYMENT_TARGET 10.7

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
 -arch x86_64 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
 -L/Users/edwin/devel/lyx-build/bin/Debug 
-L/Users/edwin/devel/lyx-build/lib/Debug/Debug 
-L/Users/edwin/devel/lyx-build/lib/Debug -L/opt/local/lib/Debug 
-L/opt/local/lib -F/Users/edwin/devel/lyx-build/bin/Debug -F/Library/Frameworks 
-filelist 
/Users/edwin/devel/lyx-build/src/client/lyx.build/Debug/lyxclient2.1.build/Objects-normal/x86_64/lyxclient2.1.LinkFileList
 -mmacosx-version-min=10.7 -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names 
/Users/edwin/devel/lyx-build/lib/Debug/libsupport.a 
/Users/edwin/devel/lyx-build/lib/Debug/libboost_signals.a 
/Users/edwin/devel/lyx-build/lib/Debug/libboost_regex.a 
/opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -framework QtCore 
-framework QtGui -framework AppKit /opt/local/lib/libz.dylib -lobjc -framework 
CoreFoundation -framework AppKit -o 
/Users/edwin/devel/lyx-build/bin/Debug/lyxclient2.1

ld: warning: directory not found for option 
'-L/Users/edwin/devel/lyx-build/lib/Debug/Debug'
ld: warning: directory not found for option '-L/opt/local/lib/Debug'
Undefined symbols for architecture x86_64:
  _iconv_open, referenced from:
  lyx::IconvProcessor::init() in libsupport.a(unicode.o)
  _iconv, referenced from:
  lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned 
long) in libsupport.a(unicode.o)
 (maybe you meant: __ZN3lyx19from_iconv_encodingERKSsS1_, 
__ZN3lyx17to_iconv_encodingERKSbIwSt11char_traitsIwESaIwEERKSs )
  _iconv_close, referenced from:
  lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned 
long) in libsupport.a(unicode.o)
  lyx::IconvProcessor::Impl::~Impl() in libsupport.a(unicode.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Re: Re: building lyx on osx

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 12:48:06, schrieb Edwin Leuven e.leu...@gmail.com
 On Jul 20, 2012, at 12:20 , Kornel Benko wrote:
  Am Freitag, 20. Juli 2012 um 11:05:27, schrieb Edwin Leuven 
  e.leu...@gmail.com
   there seems to be some problem with linking iconv though. 
   
  What problems?
 
 i pasted the error message below. 
 
 looks like iconv is not 64bit

This should not be a problem. We search for this lib in 
development/cmake/modules/FindICONV.cmake.
You may want to try to adapt this file.

And maybe it would help cmake ... -DLYX_NLS=ON -DLYX_EXTERNAL_LIBINTL=ON ...

 ed.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX master] Read list of translated languages from a file

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 But tell us more about your distro. What does it do that could break
 everything?

I didn't say it would break everything :)
Under gentoo you can set system-wide or per package the language you want
to be installed. For example if I set that I'm interested only in french
translations only fr.gmo is going to be installed.

I have never looked what's going on behind the scenes - whether its just some
gentoo related hack or more general mechanism of autotools.

From what I understood this patch will list all translations allowed 
(I guess originally taken from LINGUAS file, right?) and install it in
specific file.

So here, we would have e.g. only fr.gmo installed and that new file
with all translations listed. The current situation is that if you set
your LC_MESSAGES=de_DE at this config, you'll get normal english
interface. With this patch, can something worse happen? (I mean is the
code dependent on installed_translations being correct?)

Pavel

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 20/07/2012 13:22, Pavel Sanda a écrit :

I didn't say it would break everything :) Under gentoo you can set
system-wide or per package the language you want to be installed. For
example if I set that I'm interested only in french translations only
fr.gmo is going to be installed.


This is done typically with gettext by setting the LINGUAS environment
variable.


I have never looked what's going on behind the scenes - whether its
just some gentoo related hack or more general mechanism of
autotools.

From what I understood this patch will list all translations allowed
(I guess originally taken from LINGUAS file, right?) and install it
in specific file.


This is actually the variable CATALOGS which contains what make 
install plans to install. Therefore, installed_translations should 
match what is actually installed. The only problem would be if people 
set CATALOGS at make install time (it would be weird because it is a 
list of file names like fr.gmo de.gmo... not a list opf languages).


In practice, the contents of CATALOGS by taking the intersections of the 
files mentionned in the po/LINGUAS _file_ and the ones in the LINGUAS 
_environment_variable_.


Does this look better?

The best would be to try it :)

JMarc

Re: [LyX master] Read list of translated languages from a file

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
 Does this look better?

 The best would be to try it :)

Ok, I will try once its in branch (I have set the building chain for packaging
2.0.x version).

Pavel

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 20/07/2012 15:52, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Does this look better?

The best would be to try it :)


Ok, I will try once its in branch (I have set the building chain for packaging
2.0.x version).


I thought it would be better to test it before going to branch...

Anyway, I will be off list starting this evening and until Aug, 20.

JMarc

Theorem numbering by type and IEEETran class

[Virgil]

Hi, everyone!
I sent this text to the users list with no response...It is about a possible 
bug or feature of the LyX layout for the IEEETran class.

It appears that after a recent LyX update, none of the modules for numbering 
theorems by type (e.g., theorem 1, theorem 2, lemma 1, proposition 1, theorem 
3, 
lemma 2, ..., as opposed to theorem 1, theorem 2, lemma 3, proposition 4, ...). 
can be chosen if the IEEEtran document class has been selected.

It seems that this restriction is hard-coded and cannot be changed from within 
LyX (one can obviously export to LaTeX, and manually change certain lines, and 
compile from LaTeX).

Is this a bug or a feature?

Is there a work-around other than the LaTeX export route?

If this is intentional, it would be nice if the user was allowed to overrule 
it, 
and add some of the Theorem by Type modules. Perhaps a maintainer has assumed 
that each and every IEEE publication today forbids Theorem by Type numbering. 
However, such prohibition does not appear to exist. For example, what the 
IEEETran manual says is:
Sometimes it is desirable that a structure share its counter with another 
structure. This can be accomplished by using the alternate form of \newtheorem
\newtheorem{struct_type}[num_like]{struct_title}
where num_like is the name of an existing structure.
(see pag 14 of IEEEtran_HOWTO.pdf ). 

That paragraph suggests clearly that a theorem common counter is by no means 
mandatory...

...and even if  all IEEE publications in existence today made the common 
counter 
mandatory (which does not seem to be the case), the policy could be changed in 
the future, or new IEEE publications could deviate from it.

Please, remove that restriction, whether intentional or not (perhaps LyX could 
simply generate some sort of warning when a user chooses numbered by type 
and IEEEtran together). And if you can suggest a workaround other than that 
mentioned above, please do.

Many thanks.

Virgil

Re: Theorem numbering by type and IEEETran class

[Richard Heck]

On 07/20/2012 10:20 AM, Virgil wrote:

Hi, everyone!
I sent this text to the users list with no response...It is about a possible
bug or feature of the LyX layout for the IEEETran class.

It appears that after a recent LyX update,

The commit that affected this was on 6 August 2010, which fixed a bug in 
the update to IEEETran 1.7, which Uwe did on 7 May 2010.



none of the modules for numbering
theorems by type (e.g., theorem 1, theorem 2, lemma 1, proposition 1, theorem 3,
lemma 2, ..., as opposed to theorem 1, theorem 2, lemma 3, proposition 4, ...).
can be chosen if the IEEEtran document class has been selected.

It seems that this restriction is hard-coded and cannot be changed from within
LyX (one can obviously export to LaTeX, and manually change certain lines, and
compile from LaTeX).

Is this a bug or a feature?

Is there a work-around other than the LaTeX export route?


It's not hard-coded, but in the layout file:
ProvidesModule theorems-std
Input theorems.inc
So we're loading theorems.inc ourselves, which means you can't use the 
bytype modules because it makes no sense to select them both. If you 
were able previously to select theorems-bytype, then that was a bug, and 
it's sheer luck that it worked, since a ton of stuff was getting defined 
twice.


But if you want to use theorems-bytype, then here's how to do it:
(i) Copy the IEEEtran.layout file to your local LyX layouts directory, 
which is a sub-directory of your LyX user directory (and you can find 
out where that is by looking at HelpAbout LyX).

(ii) Rename that file something like IEEEtran-bytype.layout.
(iii) Open the file and change the declaration at the beginning so it 
reads something like:

#  \DeclareLaTeXClass{article (IEEEtran, by type)}
(iv) Find the lines mentioned above, and change them to:
ProvidesModule theorems-bytype
Input theorems-bytype.inc
(v) Reconfigure LyX, and now this new layout should be available.

Richard

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Thursday, July 19, 2012 4:15 AM

>Le 19/07/2012 04:46, Scott Kostyshak a écrit :
>> If there are more windows open, buffer-forall iterates over the
>> buffers in the current window, treating a buffer as hidden as
>> designated in the current window.

>It would be nice to rephrase the status message to reflect the situation
>like maybe
>"Applied the following command to all visible buffers in this window: "
>(or something else, I am not the native english speaker here)

That sounds good. I put "the active window" instead of "this window" because 
(at least in Linux) if you have messages open on a window, open a new window, 
and execute a command in the mini-buffer of the new window, the message box of 
the old window will show that command and its output. Thus, the "this" would 
refer to the incorrect window. Attached is the updated patch.

>Note however that on the Mac tabs are not used by default and that each
>files is in its own window (there is an option for that). buffer-forall
>is just useless in this case, isn't it?

Interesting, I didn't know this. The "Open Documents in Tabs" is not checked by 
default for Macs? I wonder how it is on Windows and what other settings are 
different across platforms. Where does this happen in the source code?

You are right that buffer-forall doesn't do anything useful by default. 
However, when you create a new window the buffers in the previous window are 
available as hidden buffers in the new window. Thus, buffer-forall both 
 would be useful because it iterates over the hidden buffers (as 
defined in the active window) as well. My feeling now is that we should have 
"both" as the default instead of "visible". What do you think?

This could lead to behavior that is a little strange, such as if you run 
`buffer-forall both statistics` with multiple windows open. You will see tabs 
appear. However, I think that's a special case.

Thanks,

Scottdiff --git a/src/FuncCode.h b/src/FuncCode.h
index 9a7b06e..a1cf57f 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, 20120720
 
 	LFUN_LASTACTION // end of the table
 };
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index 39018ce..7a4ec33 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3127,6 +3127,28 @@ 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 in the active window.
+ * \li Syntax: buffer-forall [] 
+ * \li Params: : <visible|hidden|both default:> default: visible   
+   : 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 tracking on all documents: \n
+	   buffer-forall both changes-track \n
+   Toggle read-only for all visible documents: \n
+	   buffer-forall buffer-toggle-read-only \n
+   Show statistics for each document: \n
+	   buffer-forall both statistics \n
+   Activate the branch named "Solutions" in all visible documents: \n
+	   buffer-forall branch-activate Solutions \n
+   Export all visible documents to PDF (pdflatex): \n
+	   buffer-forall buffer-export pdf2 \n
+ * \li Origin: scottkostyshak, 20 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/GuiApplication.cpp b/src/frontends/qt4/GuiApplication.cpp
index b855067..94581a3 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -38,6 +38,7 @@
 #include "Font.h"
 #include "FuncRequest.h"
 #include "FuncStatus.h"
+#include "GuiWorkArea.h"
 #include "Intl.h"
 #include "KeyMap.h"
 #include "Language.h"
@@ -1077,6 +1078,15 @@ bool GuiApplication::getStatus(FuncRequest const & cmd, FuncStatus & flag) const
 		enable = true;
 		break;
 
+	case LFUN_BUFFER_FORALL: {
+		if (!currentView() || !currentView()->currentBufferView() || !()->currentBufferView()->buffer()) {
+			flag.message(from_utf8(N_("Command not allowed without any visible document in the active window")));
+			flag.setEnabled(false);
+		}
+		break;
+	}
+
+
 	default:
 		return false;
 

Re: Re: [LyX master] Read list of translated languages from a file

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 00:49:47, schrieb Pavel Sanda 
> Jean-Marc Lasgouttes wrote:
> >> How exactly is this list assembled? Just presence of .gmo in compiled tree
> >> is enough? This could break on linux installs where only subset of 
> >> compiled
> >> translation is installed.
> >
> > I use te variable CATALOGS which is built in po.m4 juste before generating 
> > the po/Makefile. The variable cannot be subst'd using @CATALOGS@ in 
> > Makefile.am, therefore it is easier to generate the file at configure time 
> > (after all we already generate other files like lyxrc.dist).
> 
> I think this will break at my distro. What is the damage in case LyX is 
> installed
> with only few .gmo files while installed_translations contains much more of 
> them?
> 
> Pavel

Try it, no problem. And so long you do not try to change the GUI-language, you 
see no difference.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: Re: [LyX master] Read list of translated languages from a file

[Kornel Benko]

Am Donnerstag, 19. Juli 2012 um 23:36:01, schrieb Jean-Marc Lasgouttes 

> Le 19/07/12 14:41, Kornel Benko a écrit :
> >  > >  In the new scheme, autotools install a file
> > lib/installed_translations that contains a list of installed languages
> > (the .gmo files that got installed). This file is read
> >
> > How should automake reflect changes in the po-files? As I understood,
> > installed_translations is created only during configure.
> >
> > 1.) Shouldn't this step go to "make"?
> 
> The Makefile variable CATALOGS, which tells which languages to 
> installed, is fixed at configure time, and it is not really meant to be
> changed at make time. The recommended way to handle this problem is to
> set the LINGUAS environment vatiable for, say, "fr de" before running 
> configure.
> 
> > 2.) Should cmake mimic this behaviour?
> 
> Yes, I think it is good to have the same behaviour for both systems.
> 
> JMarc
> 

OK. Done.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 20/07/2012 00:49, Pavel Sanda a écrit :

I use te variable CATALOGS which is built in po.m4 juste before generating
the po/Makefile. The variable cannot be subst'd using @CATALOGS@ in
Makefile.am, therefore it is easier to generate the file at configure time
(after all we already generate other files like lyxrc.dist).


I think this will break at my distro. What is the damage in case LyX is 
installed
with only few .gmo files while installed_translations contains much more of 
them?


The damage is that you will see english instead of your fancy language 
in the case.


But tell us more about your distro. What does it do that could break 
everything?


JMarc

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 08:12, Scott Kostyshak a écrit :

That sounds good. I put "the active window" instead of "this window"
because (at least in Linux) if you have messages open on a window,
open a new window, and execute a command in the mini-buffer of the
new window, the message box of the old window will show that command
and its output. Thus, the "this" would refer to the incorrect window.
Attached is the updated patch.


Very good. I'll commit that.


Interesting, I didn't know this. The "Open Documents in Tabs" is not
checked by default for Macs? I wonder how it is on Windows and what
other settings are different across platforms. Where does this happen
in the source code?


Nowhere :) We use a file lyxrc.dist that can be changed by the packager 
to initialize some setting. On the mac it is created from

development/MacOSX/lyxrc.dist.in


You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible 
nowhere) with the ones that are visible in some other window. I think 
these two things are very different from a user point of view.


Conclusion: you should not ask only the current view for visibleness 
(?), but all views.


JMarc

building lyx on osx

[Edwin Leuven]

hi guys, 

i recently got a mac, and am now trying to build lyx using Xcode & cmake. 

there seems to be some problem with linking iconv though. 

i was wondering whether there are some recent build instructions for osx?

also, did someone manage to make lyx look decent on a retina display?

thanks, edwin

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 20/07/2012 10:45, Jean-Marc Lasgouttes a écrit :

You are right that buffer-forall doesn't do anything useful by
default. However, when you create a new window the buffers in the
previous window are available as hidden buffers in the new window.


The problem is that the LFUN is mixing real hidden buffers (visible
nowhere) with the ones that are visible in some other window. I think
these two things are very different from a user point of view.

Conclusion: you should not ask only the current view for visibleness
(?), but all views.


I have pushed the patch to master now. Thanks for te patch (and for 
going through all the iterations).


I pushed the patch now because I will go in vacation this evening and 
did not want to let it in a limbo, but I think you should think again 
about multiple views.


* the default should be "all buffers visible in a view"

* It may be better to force the use of the first argument, because as it 
is this argument is not well defined. You could use * for all buffers, 
as in inset-forall


* if the action closes the only open buffer of the lyxview, does it crash?

* if you want to handle multiple view, I suspect that the logic of you 
main loop will have to change. An alternative would be to invoke 
BufferView::dispatch or even Buffer::dispatch, but this is restrictive.


JMarc

Captions for inserted PDFs do not display correctly

[Carlos Fiyero]

When you insert an external PDF-file (e.g. for a table where you have
to keep the original layout) into a floating element for give it a
caption, the inserted PDF looks nice, but the caption isn't displayed
above or under the inserted PDF but anywhere in the PDF (like a second
layer). The use of boxes or anything like that doesn't help. (I'm
using Lyx 2.0.4 on Windows 7.) This bug should be fixed very soon,
because that's not only a bug for better usability but for better
documents.

Re: new function request

[Jean-Marc Lasgouttes]

Le 07/07/2012 12:31, Kornel Benko a écrit :

Hi,

very often I use more than 1 window while editing a file in lyx.

This is handy, but starting with "window-new" forces me always also

to use File->Open...

I'd like to have a function like "window-new-current-buffer", which
behaves like

in emacs "File->New Frame", e.g. creates a new window with the current
buffer displayed.


Note thatere is a checkbox in prefs for opening new files in new windows 
rather than tabs.


JMarc

Captions for images and tables not justified correctly

[Carlos Fiyero]

When you make a floating element with an image or a table, you can
justify the image/table right, left or centered. But the caption
always remains centered. It should be automatically change it
depending of the position of the image/table or it should be possible
manually. (I'm using Lyx 2.0.4 on Win 7.)

Re: Re: new function request

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 11:20:25, schrieb Jean-Marc Lasgouttes 

> Le 07/07/2012 12:31, Kornel Benko a écrit :
> > Hi,
> >
> > very often I use more than 1 window while editing a file in lyx.
> >
> > This is handy, but starting with "window-new" forces me always also
> >
> > to use File->Open...
> >
> > I'd like to have a function like "window-new-current-buffer", which
> > behaves like
> >
> > in emacs "File->New Frame", e.g. creates a new window with the current
> > buffer displayed.
> 
> Note thatere is a checkbox in prefs for opening new files in new windows 
> rather than tabs.
> 
> JMarc

That is nice. Though not exactly fitting to the desired feature.
I like windows _and_ tabs.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: building lyx on osx

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 11:05:27, schrieb Edwin Leuven 
> hi guys, 
> 
> i recently got a mac, and am now trying to build lyx using Xcode & cmake. 
> 
> there seems to be some problem with linking iconv though. 

What problems? Is the iconv lib not found? Or iconv header file?
#egrep -i iconv CMakeCache.txt (on ubuntu, but should be similar)
-->ICONV_HEADER:FILEPATH=/usr/include/iconv.h
   ICONV_INCLUDE_DIR:PATH=/usr/include
   ICONV_LIBRARY:STRING=
   //Test HAVE_ICONV_CONST
   HAVE_ICONV_CONST:INTERNAL=
   //Have function iconv
   HAVE_ICONV_IN_LIBC:INTERNAL=1
   //ADVANCED property for variable: ICONV_INCLUDE_DIR
   ICONV_INCLUDE_DIR-ADVANCED:INTERNAL=1
   //ADVANCED property for variable: ICONV_LIBRARY
   ICONV_LIBRARY-ADVANCED:INTERNAL=1


> i was wondering whether there are some recent build instructions for osx?
> 
> also, did someone manage to make lyx look decent on a retina display?
> 
> thanks, edwin

I have no mac here, so don't know.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: building lyx on osx

[Edwin Leuven]

On Jul 20, 2012, at 12:20 , Kornel Benko wrote:
> Am Freitag, 20. Juli 2012 um 11:05:27, schrieb Edwin Leuven 
> 
> > there seems to be some problem with linking iconv though. 
>  
> What problems?

i pasted the error message below. 

looks like iconv is not 64bit

ed.



Ld /Users/edwin/devel/lyx-build/bin/Debug/lyxclient2.1 normal x86_64
cd /Users/edwin/devel/lyx
setenv MACOSX_DEPLOYMENT_TARGET 10.7

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
 -arch x86_64 -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
 -L/Users/edwin/devel/lyx-build/bin/Debug 
-L/Users/edwin/devel/lyx-build/lib/Debug/Debug 
-L/Users/edwin/devel/lyx-build/lib/Debug -L/opt/local/lib/Debug 
-L/opt/local/lib -F/Users/edwin/devel/lyx-build/bin/Debug -F/Library/Frameworks 
-filelist 
/Users/edwin/devel/lyx-build/src/client/lyx.build/Debug/lyxclient2.1.build/Objects-normal/x86_64/lyxclient2.1.LinkFileList
 -mmacosx-version-min=10.7 -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names 
/Users/edwin/devel/lyx-build/lib/Debug/libsupport.a 
/Users/edwin/devel/lyx-build/lib/Debug/libboost_signals.a 
/Users/edwin/devel/lyx-build/lib/Debug/libboost_regex.a 
/opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -framework QtCore 
-framework QtGui -framework AppKit /opt/local/lib/libz.dylib -lobjc -framework 
CoreFoundation -framework AppKit -o 
/Users/edwin/devel/lyx-build/bin/Debug/lyxclient2.1

ld: warning: directory not found for option 
'-L/Users/edwin/devel/lyx-build/lib/Debug/Debug'
ld: warning: directory not found for option '-L/opt/local/lib/Debug'
Undefined symbols for architecture x86_64:
  "_iconv_open", referenced from:
  lyx::IconvProcessor::init() in libsupport.a(unicode.o)
  "_iconv", referenced from:
  lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned 
long) in libsupport.a(unicode.o)
 (maybe you meant: __ZN3lyx19from_iconv_encodingERKSsS1_, 
__ZN3lyx17to_iconv_encodingERKSbIwSt11char_traitsIwESaIwEERKSs )
  "_iconv_close", referenced from:
  lyx::IconvProcessor::convert(char const*, unsigned long, char*, unsigned 
long) in libsupport.a(unicode.o)
  lyx::IconvProcessor::Impl::~Impl() in libsupport.a(unicode.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Re: Re: building lyx on osx

[Kornel Benko]

Am Freitag, 20. Juli 2012 um 12:48:06, schrieb Edwin Leuven 
> On Jul 20, 2012, at 12:20 , Kornel Benko wrote:
> > Am Freitag, 20. Juli 2012 um 11:05:27, schrieb Edwin Leuven 
> > 
> > > there seems to be some problem with linking iconv though. 
> >  
> > What problems?
> 
> i pasted the error message below. 
> 
> looks like iconv is not 64bit

This should not be a problem. We search for this lib in 
development/cmake/modules/FindICONV.cmake.
You may want to try to adapt this file.

And maybe it would help "cmake ... -DLYX_NLS=ON -DLYX_EXTERNAL_LIBINTL=ON ..."

> ed.

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: [LyX master] Read list of translated languages from a file

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> But tell us more about your distro. What does it do that could break
> everything?

I didn't say it would break everything :)
Under gentoo you can set system-wide or per package the language you want
to be installed. For example if I set that I'm interested only in french
translations only fr.gmo is going to be installed.

I have never looked what's going on behind the scenes - whether its just some
gentoo related hack or more general mechanism of autotools.

>From what I understood this patch will list all translations allowed 
(I guess originally taken from LINGUAS file, right?) and install it in
specific file.

So here, we would have e.g. only fr.gmo installed and that new file
with all translations listed. The current situation is that if you set
your LC_MESSAGES=de_DE at this config, you'll get normal english
interface. With this patch, can something worse happen? (I mean is the
code dependent on installed_translations being correct?)

Pavel

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 20/07/2012 13:22, Pavel Sanda a écrit :

I didn't say it would break everything :) Under gentoo you can set
system-wide or per package the language you want to be installed. For
example if I set that I'm interested only in french translations only
fr.gmo is going to be installed.


This is done typically with gettext by setting the LINGUAS environment
variable.


I have never looked what's going on behind the scenes - whether its
just some gentoo related hack or more general mechanism of
autotools.

From what I understood this patch will list all translations allowed
(I guess originally taken from LINGUAS file, right?) and install it
in specific file.


This is actually the variable CATALOGS which contains what "make 
install" plans to install. Therefore, installed_translations should 
match what is actually installed. The only problem would be if people 
set CATALOGS at make install time (it would be weird because it is a 
list of file names like "fr.gmo de.gmo..." not a list opf languages).


In practice, the contents of CATALOGS by taking the intersections of the 
files mentionned in the po/LINGUAS _file_ and the ones in the LINGUAS 
_environment_variable_.


Does this look better?

The best would be to try it :)

JMarc

Re: [LyX master] Read list of translated languages from a file

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Does this look better?
>
> The best would be to try it :)

Ok, I will try once its in branch (I have set the building chain for packaging
2.0.x version).

Pavel

Re: [LyX master] Read list of translated languages from a file

[Jean-Marc Lasgouttes]

Le 20/07/2012 15:52, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

Does this look better?

The best would be to try it :)


Ok, I will try once its in branch (I have set the building chain for packaging
2.0.x version).


I thought it would be better to test it before going to branch...

Anyway, I will be off list starting this evening and until Aug, 20.

JMarc

Theorem numbering by type and IEEETran class

[Virgil]

Hi, everyone!
I sent this text to the users list with no response...It is about a possible 
"bug" or "feature" of the LyX layout for the IEEETran class.

It appears that after a recent LyX update, none of the modules for numbering 
theorems by type (e.g., theorem 1, theorem 2, lemma 1, proposition 1, theorem 
3, 
lemma 2, ..., as opposed to theorem 1, theorem 2, lemma 3, proposition 4, ...). 
can be chosen if the IEEEtran document class has been selected.

It seems that this restriction is hard-coded and cannot be changed from within 
LyX (one can obviously export to LaTeX, and manually change certain lines, and 
compile from LaTeX).

Is this a "bug" or a "feature"?

Is there a work-around other than the LaTeX export route?

If this is intentional, it would be nice if the user was allowed to overrule 
it, 
and add some of the Theorem by Type modules. Perhaps a maintainer has assumed 
that each and every IEEE publication today forbids "Theorem by Type" numbering. 
However, such prohibition does not appear to exist. For example, what the 
IEEETran manual says is:
"Sometimes it is desirable that a structure share its counter with another 
structure. This can be accomplished by using the alternate form of \newtheorem
\newtheorem{struct_type}[num_like]{struct_title}
where num_like is the name of an existing structure."
(see pag 14 of IEEEtran_HOWTO.pdf ). 

That paragraph suggests clearly that a theorem "common counter" is by no means 
mandatory...

...and even if  all IEEE publications in existence today made the common 
counter 
mandatory (which does not seem to be the case), the policy could be changed in 
the future, or new IEEE publications could deviate from it.

Please, remove that restriction, whether intentional or not (perhaps LyX could 
simply generate some sort of "warning" when a user chooses "numbered by type" 
and IEEEtran together). And if you can suggest a workaround other than that 
mentioned above, please do.

Many thanks.

Virgil

Re: Theorem numbering by type and IEEETran class

[Richard Heck]

On 07/20/2012 10:20 AM, Virgil wrote:

Hi, everyone!
I sent this text to the users list with no response...It is about a possible
"bug" or "feature" of the LyX layout for the IEEETran class.

It appears that after a recent LyX update,

The commit that affected this was on 6 August 2010, which fixed a bug in 
the update to IEEETran 1.7, which Uwe did on 7 May 2010.



none of the modules for numbering
theorems by type (e.g., theorem 1, theorem 2, lemma 1, proposition 1, theorem 3,
lemma 2, ..., as opposed to theorem 1, theorem 2, lemma 3, proposition 4, ...).
can be chosen if the IEEEtran document class has been selected.

It seems that this restriction is hard-coded and cannot be changed from within
LyX (one can obviously export to LaTeX, and manually change certain lines, and
compile from LaTeX).

Is this a "bug" or a "feature"?

Is there a work-around other than the LaTeX export route?


It's not hard-coded, but in the layout file:
ProvidesModule theorems-std
Input theorems.inc
So we're loading theorems.inc ourselves, which means you can't use the 
"bytype" modules because it makes no sense to select them both. If you 
were able previously to select theorems-bytype, then that was a bug, and 
it's sheer luck that it worked, since a ton of stuff was getting defined 
twice.


But if you want to use theorems-bytype, then here's how to do it:
(i) Copy the IEEEtran.layout file to your local LyX layouts directory, 
which is a sub-directory of your LyX user directory (and you can find 
out where that is by looking at Help>About LyX).

(ii) Rename that file something like IEEEtran-bytype.layout.
(iii) Open the file and change the declaration at the beginning so it 
reads something like:

#  \DeclareLaTeXClass{article (IEEEtran, by type)}
(iv) Find the lines mentioned above, and change them to:
ProvidesModule theorems-bytype
Input theorems-bytype.inc
(v) Reconfigure LyX, and now this new layout should be available.

Richard