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 features!" is slowly disappearing as I learn more about programming. 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? Thanks, Scott
