Re: [LyX master] An IPA toolbar

[Jürgen Spitzmüller]

2012/8/21 Kornel Benko kor...@lyx.org:
 This is really a big set of translation strings.

Yes, and probably not easy to translate for a non-linguist. I suggest
you look up for an IPA (or phonetics) website in your language to get
the translations.

Jürgen

 Kornel

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, July 20, 2012 4:45 AM

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.

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

* the default should be all buffers visible in a view

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms visible and
hidden, which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


I decided to use the term view in the LFUN documentation. Even though I think
the term window is more familiar to users, I think view will help the new
user realize the connection of a buffer being visible if it is in a view
(similar words). Actually, if this is my argument then maybe viewable is a
better word than visible. Any thoughts?

* 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

The first argument is now required. This is also a good idea because it avoids
the problem if someone misspells the first argument. For example, if the
command were 'buffer-forall hiden self-insert hello', buffer-forall would have
treated hiden as the LFUN. The first argument is now
[lVisible|gVisible|lHidden|gHidden|*]

Note that lVisible does not make sense with no tabs (the user might as well
just run the LFUN directly). lHidden could be useful without tabs if you wanted
to run an LFUN on all buffers *except* the one you're working on.

I could have made the first argument [lVisible|gVisible|lHidden|gHidden|*]
into two arguments: [visible|hidden] [locally|globally]. I'm not sure where
* would fit in best there. Any thoughts?

* 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.

The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

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

'buffer-forall * buffer-close' works fine.
'buffer-forall * lyx-quit' does not (for more than one buffer open). I did not
try to address this. Should I?

I tested buffer-forall a lot with Open documents in tabs checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?

Any comments on variable names, style, or general logic would be great. There
are some things that could still be added. For example, perhaps the user wants
to run the LFUN on all buffers that are visible in all windows. visible in all
windows (i.e. locally visible in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.

I'm sorry to take up so much of your time on this LFUN, JMarc. 

Thanks,

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index bf3db52..9f83b5c 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3139,22 +3139,32 @@ 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
-   

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 09:04, Scott Kostyshak a écrit :

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms visible and
hidden, which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


Do you really think that 'locally visible' and especially 'locally 
hidden' have real use cases, or are they just added for the sake of 
being complete? I would think that all/visible/hidden is good enough.



I decided to use the term view in the LFUN documentation. Even though I think
the term window is more familiar to users, I think view will help the new
user realize the connection of a buffer being visible if it is in a view
(similar words). Actually, if this is my argument then maybe viewable is a
better word than visible. Any thoughts?


Just use view (window) in the description, maybe?


The first argument is now required.


Good.


The first argument is now [lVisible|gVisible|lHidden|gHidden|*]


This is where the extra options have a cost. People have to understand 
the subtleties of local/global visibility to use the lfun (and the names 
are ugly :)



The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

I tested buffer-forall a lot with Open documents in tabs checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?


If you tested correctly these possibilities, I think there is no need to 
worry. Since the feature does not affect people who do not us it, we 
have time to act when a bug is found.



Any comments on variable names, style, or general logic would be great.


A few comments:

* in order to make the code more readable, you could move the part that 
constructs the list of buffers to some new GuiApplication method. It 
could even be possible to create GuiView helpers if that makes the code 
easier to understand.


* concerning the complexity, I am not sure why you cannot first get a 
list ouf buffers to process (the foreach) and than process all of them 
(the while loop) without making lots of different cases.


* I am not sure it is worth having precise counting of what type of 
buffers have been processed. Only one message

  Applied \%1$s\ to %2$d buffer(s)
is almost good enough, and showing the list of files names (without 
paths) instead would be even more informative



There are some things that could still be added. For example, perhaps the user 
wants
to run the LFUN on all buffers that are visible in all windows. visible in all
windows (i.e. locally visible in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.


I think the biggest risk now is overengineering. My advice is to 
implement the features that you *know* you need, and wait until people 
complain that their use case is not covered. From there, you can update 
the function. For example, it might turn out that there is a need to 
filter on master/child (think export to PDF).


Trying to cover all possible uses from the start has a cost.


I'm sorry to take up so much of your time on this LFUN, JMarc.


Don't be sorry. Any patch is a good occasion to climb the learning curve 
of LyX development.


JMarc

PS: I almost forgot. Feel free to disagree with anything I wrote, of course!

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

[Jean-Marc Lasgouttes]

Le 21/08/2012 16:59, Richard Heck a écrit :

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.


When you feel it's ready.


Since getting testers on windows is more difficult, I will apply to 
branch, and if Uwe finds a problem when preparing the installer, just 
revert.


JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 4:12 AM

Le 22/08/2012 09:04, Scott Kostyshak a écrit :
 + * \li Notion: A buffer is `locally visible' with respect to a view if it
 +   is visible within that view. If not, it is `locally hidden'.
 +   A buffer is `globally visible' if there exists an open view 
 in
 +   which it is locally visible. If not, it is `globally hidden'.

Do you really think that 'locally visible' and especially 'locally
hidden' have real use cases, or are they just added for the sake of
being complete? I would think that all/visible/hidden is good enough.

What do you mean by visible here? Are you referring to what I am calling
globally visible?

I do think that 'locally visible' has a real use case. I could see a work-flow
where a user has some documents visible in one view (all problem sets) and some
other type of documents visible in a different view (exams). Perhaps that user
wants to apply an LFUN to all problem sets (e.g. the activate solutions
branch LFUN). This could be done by using lVisible. Of course, this work-flow
could also be achieved by using different instances of LyX instead of different
views and then just using the all or globally visible argument of
buffer-forall. Even after thinking a lot I have trouble coming up with a 
practical
use of 'locally hidden' :)

 I decided to use the term view in the LFUN documentation. Even though I 
 think
 the term window is more familiar to users, I think view will help the new
 user realize the connection of a buffer being visible if it is in a view
 (similar words). Actually, if this is my argument then maybe viewable is a
 better word than visible. Any thoughts?

Just use view (window) in the description, maybe?

I like that.

 The first argument is now [lVisible|gVisible|lHidden|gHidden|*]

This is where the extra options have a cost. People have to understand
the subtleties of local/global visibility to use the lfun (and the names
are ugly :)

Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess a buffer is visible if it is viewable in an 
open view
would be enough. I am a little hesitant to avoid using locally and globally
because otherwise the definition sounds like a buffer is visible if it is
visible in a view which is confusing and incorrect.

To make things really simple, what if only visible were supported or only
all? Do you think a user would want to apply LFUNs to only hidden documents?

 The main loop did change a lot. I am a little disappointed that the code had 
 to
 get a lot more complicated, but I don't see an easier way and I think it is
 worth it. I went through several iterations of different logic and ended up 
 on
 the one in the attached patch. I hope I did not fall into the feature-bloat
 trap but now most sets of buffers are supported and the terms are 
 well-defined.
 I used more comments than usual because of the added complexity. Please let 
 me
 know which comments I should remove.

 I tested buffer-forall a lot with Open documents in tabs checked and 
 unchecked.
 I'm not sure if this is enough to know how things will work on Mac and 
 Windows.
 Should I put out an email asking for testers on lyx-devel?

If you tested correctly these possibilities, I think there is no need to
worry. Since the feature does not affect people who do not us it, we
have time to act when a bug is found.

 Any comments on variable names, style, or general logic would be great.

A few comments:

* in order to make the code more readable, you could move the part that
constructs the list of buffers to some new GuiApplication method. It
could even be possible to create GuiView helpers if that makes the code
easier to understand.

OK, that sounds good. Once we decide on which options to support I'll see about
this.

* concerning the complexity, I am not sure why you cannot first get a
list ouf buffers to process (the foreach) and than process all of them
(the while loop) without making lots of different cases.

* I am not sure it is worth having precise counting of what type of
buffers have been processed. Only one message
   Applied \%1$s\ to %2$d buffer(s)
is almost good enough, and showing the list of files names (without
paths) instead would be even more informative

Sounds good.

I think the biggest risk now is overengineering. My advice is to
implement the features that you *know* you need, and wait until people
complain that their use case is not covered. From there, you can update
the function. For example, it might turn out that there is a need to
filter on master/child (think export to PDF).

Trying to cover all possible uses from the start has a cost.

Good advice. That's the kind of thing that I should know but that I need to be
continually reminded of. The voice of the devil on my shoulder saying more

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 11:06, Scott Kostyshak a écrit :

Do you really think that 'locally visible' and especially 'locally
hidden' have real use cases, or are they just added for the sake of
being complete? I would think that all/visible/hidden is good enough.


What do you mean by visible here? Are you referring to what I am calling
globally visible?


Yes.


Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess a buffer is visible if it is viewable in an open 
view
would be enough. I am a little hesitant to avoid using locally and globally
because otherwise the definition sounds like a buffer is visible if it is
visible in a view which is confusing and incorrect.


I would  revert the definition: a buffer is hidden if it is internally 
opened in LyX, but not visible in any window (rewritten into proper 
English)



To make things really simple, what if only visible were supported or only
all? Do you think a user would want to apply LFUNs to only hidden documents?


Maybe to close them or to make them visible.


Now my first thought is to do one of the following:

(1) only support visible (globally visible)
(2) only support all
(3) support both visible and all.

I will need to think about this more. What do you think?


Maybe you should keep visible/hidden/all, if only for symmetry.

BTW, an idea for a next patch: in the document list of the View menu, 
files opened in another window appear as hidden. This is wrong of 
course. They should probably be in a different submenu other windows.


However, in the 'no tabs' mac scenario, this does not make sense at all, 
since all files should be displayed and selecting one with the view menu 
should just give focus to the proper window.


Supporting both tabs and multiple windows is a UX nightmare in my opinion.

JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 6:27 AM

I would  revert the definition: a buffer is hidden if it is internally
opened in LyX, but not visible in any window (rewritten into proper
English)

Sounds good.

 To make things really simple, what if only visible were supported or only
 all? Do you think a user would want to apply LFUNs to only hidden 
 documents?

Maybe to close them or to make them visible.

Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
Should it not do that?

Maybe you should keep visible/hidden/all, if only for symmetry.

OK.

BTW, an idea for a next patch: in the document list of the View menu,
files opened in another window appear as hidden. This is wrong of
course. They should probably be in a different submenu other windows.

However, in the 'no tabs' mac scenario, this does not make sense at all,
since all files should be displayed and selecting one with the view menu
should just give focus to the proper window.

Supporting both tabs and multiple windows is a UX nightmare in my opinion.

Agreed.

Scott

Re: [LyX master] An IPA toolbar

[Jürgen Spitzmüller]

2012/8/21 Kornel Benko :
> This is really a big set of translation strings.

Yes, and probably not easy to translate for a non-linguist. I suggest
you look up for an IPA (or phonetics) website in your language to get
the translations.

Jürgen

> Kornel

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Friday, July 20, 2012 4:45 AM

>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.

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

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

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms "visible" and
"hidden", which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


I decided to use the term "view" in the LFUN documentation. Even though I think
the term "window" is more familiar to users, I think "view" will help the new
user realize the connection of a buffer being "visible" if it is in a "view"
(similar words). Actually, if this is my argument then maybe "viewable" is a
better word than "visible". Any thoughts?

>* 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

The first argument is now required. This is also a good idea because it avoids
the problem if someone misspells the first argument. For example, if the
command were 'buffer-forall hiden self-insert hello', buffer-forall would have
treated "hiden" as the LFUN. The first argument is now
[lVisible|gVisible|lHidden|gHidden|*]

Note that lVisible does not make sense with no tabs (the user might as well
just run the LFUN directly). lHidden could be useful without tabs if you wanted
to run an LFUN on all buffers *except* the one you're working on.

I could have made the first argument [lVisible|gVisible|lHidden|gHidden|*]
into two arguments: [visible|hidden] [locally|globally]. I'm not sure where
"*" would fit in best there. Any thoughts?

>* 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.

The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

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

'buffer-forall * buffer-close' works fine.
'buffer-forall * lyx-quit' does not (for more than one buffer open). I did not
try to address this. Should I?

I tested buffer-forall a lot with "Open documents in tabs" checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?

Any comments on variable names, style, or general logic would be great. There
are some things that could still be added. For example, perhaps the user wants
to run the LFUN on all buffers that are visible in all windows. "visible in all
windows" (i.e. "locally visible" in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.

I'm sorry to take up so much of your time on this LFUN, JMarc. 

Thanks,

Scottdiff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index bf3db52..9f83b5c 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -3139,22 +3139,32 @@ 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: :  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
-  

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 09:04, Scott Kostyshak a écrit :

I agree with the above points you made. LFUN_BUFFER_FORALL now supports
multiple views and I tried to add some structure on the terms "visible" and
"hidden", which are now defined in the LFUN documentation. The language is kind
of confusing, but I cannot think of a clearer way. I'm pasting the definitions
here for your thoughts and so that the rest of this email makes sense:

+ * \li Notion: A buffer is `locally visible' with respect to a view if it
+   is visible within that view. If not, it is `locally hidden'.
+   A buffer is `globally visible' if there exists an open view in
+   which it is locally visible. If not, it is `globally hidden'.


Do you really think that 'locally visible' and especially 'locally 
hidden' have real use cases, or are they just added for the sake of 
being complete? I would think that all/visible/hidden is good enough.



I decided to use the term "view" in the LFUN documentation. Even though I think
the term "window" is more familiar to users, I think "view" will help the new
user realize the connection of a buffer being "visible" if it is in a "view"
(similar words). Actually, if this is my argument then maybe "viewable" is a
better word than "visible". Any thoughts?


Just use "view (window)" in the description, maybe?


The first argument is now required.


Good.


The first argument is now [lVisible|gVisible|lHidden|gHidden|*]


This is where the extra options have a cost. People have to understand 
the subtleties of local/global visibility to use the lfun (and the names 
are ugly :)



The main loop did change a lot. I am a little disappointed that the code had to
get a lot more complicated, but I don't see an easier way and I think it is
worth it. I went through several iterations of different logic and ended up on
the one in the attached patch. I hope I did not fall into the feature-bloat
trap but now most sets of buffers are supported and the terms are well-defined.
I used more comments than usual because of the added complexity. Please let me
know which comments I should remove.

I tested buffer-forall a lot with "Open documents in tabs" checked and 
unchecked.
I'm not sure if this is enough to know how things will work on Mac and Windows.
Should I put out an email asking for testers on lyx-devel?


If you tested correctly these possibilities, I think there is no need to 
worry. Since the feature does not affect people who do not us it, we 
have time to act when a bug is found.



Any comments on variable names, style, or general logic would be great.


A few comments:

* in order to make the code more readable, you could move the part that 
constructs the list of buffers to some new GuiApplication method. It 
could even be possible to create GuiView helpers if that makes the code 
easier to understand.


* concerning the complexity, I am not sure why you cannot first get a 
list ouf buffers to process (the foreach) and than process all of them 
(the while loop) without making lots of different cases.


* I am not sure it is worth having precise counting of what type of 
buffers have been processed. Only one message

  "Applied \"%1$s\" to %2$d buffer(s)"
is almost good enough, and showing the list of files names (without 
paths) instead would be even more informative



There are some things that could still be added. For example, perhaps the user 
wants
to run the LFUN on all buffers that are visible in all windows. "visible in all
windows" (i.e. "locally visible" in all views) is not a supported set by
buffer-forall. Please let me know if you can think of additional functionality
that is missing and that should be added.


I think the biggest risk now is overengineering. My advice is to 
implement the features that you *know* you need, and wait until people 
complain that their use case is not covered. From there, you can update 
the function. For example, it might turn out that there is a need to 
filter on master/child (think export to PDF).


Trying to cover all possible uses from the start has a cost.


I'm sorry to take up so much of your time on this LFUN, JMarc.


Don't be sorry. Any patch is a good occasion to climb the learning curve 
of LyX development.


JMarc

PS: I almost forgot. Feel free to disagree with anything I wrote, of course!

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

[Jean-Marc Lasgouttes]

Le 21/08/2012 16:59, Richard Heck a écrit :

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.


When you feel it's ready.


Since getting testers on windows is more difficult, I will apply to 
branch, and if Uwe finds a problem when preparing the installer, just 
revert.


JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 4:12 AM

>Le 22/08/2012 09:04, Scott Kostyshak a écrit :
>> + * \li Notion: A buffer is `locally visible' with respect to a view if it
>> +   is visible within that view. If not, it is `locally hidden'.
>> +   A buffer is `globally visible' if there exists an open view 
>> in
>> +   which it is locally visible. If not, it is `globally hidden'.
>
>Do you really think that 'locally visible' and especially 'locally
>hidden' have real use cases, or are they just added for the sake of
>being complete? I would think that all/visible/hidden is good enough.

What do you mean by "visible" here? Are you referring to what I am calling
"globally visible"?

I do think that 'locally visible' has a real use case. I could see a work-flow
where a user has some documents visible in one view (all problem sets) and some
other type of documents visible in a different view (exams). Perhaps that user
wants to apply an LFUN to all problem sets (e.g. the "activate solutions
branch" LFUN). This could be done by using lVisible. Of course, this work-flow
could also be achieved by using different instances of LyX instead of different
views and then just using the "all" or "globally visible" argument of
buffer-forall. Even after thinking a lot I have trouble coming up with a 
practical
use of 'locally hidden' :)

>> I decided to use the term "view" in the LFUN documentation. Even though I 
>> think
>> the term "window" is more familiar to users, I think "view" will help the new
>> user realize the connection of a buffer being "visible" if it is in a "view"
>> (similar words). Actually, if this is my argument then maybe "viewable" is a
>> better word than "visible". Any thoughts?
>
>Just use "view (window)" in the description, maybe?

I like that.

>> The first argument is now [lVisible|gVisible|lHidden|gHidden|*]
>
>This is where the extra options have a cost. People have to understand
>the subtleties of local/global visibility to use the lfun (and the names
>are ugly :)

Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess "a buffer is visible if it is viewable in an 
open view"
would be enough. I am a little hesitant to avoid using "locally" and "globally"
because otherwise the definition sounds like "a buffer is visible if it is
visible in a view" which is confusing and incorrect.

To make things really simple, what if only "visible" were supported or only
"all"? Do you think a user would want to apply LFUNs to only hidden documents?

>> The main loop did change a lot. I am a little disappointed that the code had 
>> to
>> get a lot more complicated, but I don't see an easier way and I think it is
>> worth it. I went through several iterations of different logic and ended up 
>> on
>> the one in the attached patch. I hope I did not fall into the feature-bloat
>> trap but now most sets of buffers are supported and the terms are 
>> well-defined.
>> I used more comments than usual because of the added complexity. Please let 
>> me
>> know which comments I should remove.
>>
>> I tested buffer-forall a lot with "Open documents in tabs" checked and 
>> unchecked.
>> I'm not sure if this is enough to know how things will work on Mac and 
>> Windows.
>> Should I put out an email asking for testers on lyx-devel?
>
>If you tested correctly these possibilities, I think there is no need to
>worry. Since the feature does not affect people who do not us it, we
>have time to act when a bug is found.
>
>> Any comments on variable names, style, or general logic would be great.
>
>A few comments:
>
>* in order to make the code more readable, you could move the part that
>constructs the list of buffers to some new GuiApplication method. It
>could even be possible to create GuiView helpers if that makes the code
>easier to understand.

OK, that sounds good. Once we decide on which options to support I'll see about
this.

>* concerning the complexity, I am not sure why you cannot first get a
>list ouf buffers to process (the foreach) and than process all of them
>(the while loop) without making lots of different cases.

>* I am not sure it is worth having precise counting of what type of
>buffers have been processed. Only one message
>   "Applied \"%1$s\" to %2$d buffer(s)"
>is almost good enough, and showing the list of files names (without
>paths) instead would be even more informative

Sounds good.

>I think the biggest risk now is overengineering. My advice is to
>implement the features that you *know* you need, and wait until people
>complain that their use case is not covered. From there, you can update
>the function. For example, it might turn out that there is a need to
>filter on master/child (think export to PDF).
>
>Trying to cover all possible uses from the start has a cost.

Good advice. 

Re: [PATCH] LFUN_BUFFER_FORALL

[Jean-Marc Lasgouttes]

Le 22/08/2012 11:06, Scott Kostyshak a écrit :

Do you really think that 'locally visible' and especially 'locally
hidden' have real use cases, or are they just added for the sake of
being complete? I would think that all/visible/hidden is good enough.


What do you mean by "visible" here? Are you referring to what I am calling
"globally visible"?


Yes.


Agreed on both points. Do you think that supporting all/gVisible/gHidden (which
is what I interpret your suggestion above as) would need definitions or would
the names be intuitive? I guess "a buffer is visible if it is viewable in an open 
view"
would be enough. I am a little hesitant to avoid using "locally" and "globally"
because otherwise the definition sounds like "a buffer is visible if it is
visible in a view" which is confusing and incorrect.


I would  revert the definition: "a buffer is hidden if it is internally 
opened in LyX, but not visible in any window" (rewritten into proper 
English)



To make things really simple, what if only "visible" were supported or only
"all"? Do you think a user would want to apply LFUNs to only hidden documents?


Maybe to close them or to make them visible.


Now my first thought is to do one of the following:

(1) only support "visible" (globally visible)
(2) only support "all"
(3) support both "visible" and "all".

I will need to think about this more. What do you think?


Maybe you should keep visible/hidden/all, if only for symmetry.

BTW, an idea for a next patch: in the document list of the View menu, 
files opened in another window appear as hidden. This is wrong of 
course. They should probably be in a different submenu "other windows".


However, in the 'no tabs' mac scenario, this does not make sense at all, 
since all files should be displayed and selecting one with the view menu 
should just give focus to the proper window.


Supporting both tabs and multiple windows is a UX nightmare in my opinion.

JMarc

RE: [PATCH] LFUN_BUFFER_FORALL

[Scott Kostyshak]

From: Jean-Marc Lasgouttes [lasgout...@lyx.org]
Sent: Wednesday, August 22, 2012 6:27 AM

>I would  revert the definition: "a buffer is hidden if it is internally
>opened in LyX, but not visible in any window" (rewritten into proper
>English)

Sounds good.

>> To make things really simple, what if only "visible" were supported or only
>> "all"? Do you think a user would want to apply LFUNs to only hidden 
>> documents?

>Maybe to close them or to make them visible.

Currently buffer-forall rehides each hidden buffer after the LFUN is applied.
Should it not do that?

>Maybe you should keep visible/hidden/all, if only for symmetry.

OK.

>BTW, an idea for a next patch: in the document list of the View menu,
>files opened in another window appear as hidden. This is wrong of
>course. They should probably be in a different submenu "other windows".

>However, in the 'no tabs' mac scenario, this does not make sense at all,
>since all files should be displayed and selecting one with the view menu
>should just give focus to the proper window.

>Supporting both tabs and multiple windows is a UX nightmare in my opinion.

Agreed.

Scott