Re: [patch] final layout patches for branch
2012/12/13 Uwe Stöhr : > Another example is KOMA-script. KOMA Script is an excellent example: It has an option version= exactly to fit the criterium we put forward: backwards compatibility. In contrast to the moderncv author (apparently), Markus Kohm has a very good understanding of how important it is to not break your user's documents by new class versions. Jürgen
Re: [PATCH] InsetTabular code cleanup
On Thu, Dec 13, 2012 at 6:45 PM, Uwe Stöhr wrote:
> Am 08.12.2012 08:09, schrieb Scott Kostyshak:
>
>
>> While studying InsetTabular{.cpp,.h}, I have some suggestions and
>> questions.
>>
>> In the 0001 patch attached, am I missing something or can we remove
>> cur.selection in the conditions?
>
>
> I would leave them in. It makes sense to me that we don#t accept a "down"
> selection if only the current cell is selected.
OK, I'll leave them in. I agree that it makes sense but my suggestion
was based on the fact that selIsMultiCell already checks that there is
a selection (any selection) :
bool selIsMultiCell() const
{ return selection_ && selBegin().idx() != selEnd().idx(); }
so we are doing something like if (selection_ && selection_ && ...)
but in reality it doesn't matter and the names make more sense as they
are.
>
>
>> In 0003, can I rename "copy-column" and "copy-row" to
>> "duplicate-column" and "duplicate-row"? The features do not just copy
>> but they also insert. The both together seem more of a "duplicate"
>> functionality.
>
>
> OK, if you like to. But for me "copy row " implies that the row content will
> appear somewhere else.
Agreed, but does it imply that the same function will also paste it?
To me it doesn't.
> So it is either a cut+paste or copy+paste. In the
> first case it is not a duplication. But I don't have a string opinion about
> the naming of the LFUN. But if you do the change, please also update our
> LFUN list and the LFUN documentation LyX-file.
I think I'll leave it. It's not clear that my suggestion is better
(because of your concerns) and it's not worth the potential mistake if
I change everything else.
>
>> There are also a few things I did not change but that I find confusing:
>> Why isn't "col_type" not named "col_num" and row_type "row_num"?
>> Does the "_type" emphasize that it's a typedef?
>
>
> I don't know. This must have historical reasons.
Yes, JMarc said that it's because it's the convention used in the STL.
>
>
>> - I find it unintuitive that a cell that is at the beginning of a
>> multirow is not "part" of a multirow:
>> See, for example, Tabular::isPartOfMultiRow.
>> I guess my confusion is because of:
>> CELL_BEGIN_OF_MULTICOLUMN,
>> ///
>> CELL_PART_OF_MULTICOLUMN,
>>
>> From a programming point of view, I understand why they are treated
>> differently, but from an interface point of view, I wonder if there
>> could be better names. I can't think of any though.
>
>
> Form the technical point of view there was no other solution and prom the UI
> point of view as a user you are never confronted with this and thus won't
> notice.
I agree, but from a "user of the code" perspective I think it is
confusing. This is not a big issue for me (now that I know the code)
but I was thinking of how to make things clearer for the next person
who wants to dig into InsetTabular.{cpp,h}.
This is the only issue remaining and I attached my proposed patch in
this same email thread (1 day ago I think). I'm attaching the same
patch to this email for convenience. I don't have a strong opinion so
if you don't like it I will not insist. What do you think?
>
>
>> - My same comment as above but for isPartOfMultiColumn.
>
>
> Dito.
>
>
>> I have two questions regarding the following code, which is in
>> function <> const & cmd, FuncStatus & status) const>>,
>>
>> switch (action) {
>> case Tabular::SET_PWIDTH:
>> case Tabular::SET_MPWIDTH:
>> case Tabular::SET_SPECIAL_COLUMN:
>> case Tabular::SET_SPECIAL_MULTICOLUMN:
>> case Tabular::APPEND_ROW:
>> case Tabular::APPEND_COLUMN:
>> case Tabular::DELETE_ROW:
>> case Tabular::DELETE_COLUMN:
>> case Tabular::COPY_ROW:
>> case Tabular::COPY_COLUMN:
>> case Tabular::SET_TOP_SPACE:
>> case Tabular::SET_BOTTOM_SPACE:
>> case Tabular::SET_INTERLINE_SPACE:
>> status.clear();
>> return true;
>>
>>
>> (1) What is the purpose of this status.clear()?
>>
>> (2) Why is "return true" used here instead of "break" (there is a
>> "return true" right after the cases and all the other cases use
>> "break")? Is this just inconsistent style or do they not provide
>> equivalent functionality?
>
>
> I also don't know.
Thanks for the comments, Uwe!
Scott
From 465a224967786ee26578a90f12b36503600e8203 Mon Sep 17 00:00:00 2001
From: Scott Kostyshak
Date: Wed, 12 Dec 2012 03:57:56 -0500
Subject: [PATCH] In InsetTabular change a few names
Make the following name changes:
CELL_PART_OF_MULTIROW -> CELL_HIDDEN_BY_MULTIROW
CELL_PART_OF_MULTICOLUMN -> CELL_HIDDEN_BY_MULTICOLUMN
isPartOfMultiRow -> isHiddenByMultiRow
isPartOfMultiColumn -> isHiddenByMultiColumn
These changes were introduced because it
Re: Retina Support
On Wed, Dec 12, 2012 at 8:40 PM, Karan Girotra wrote: > Hey, > > Are there any plans to provide retina display support for LyX? What exactly > does it entail? See the following links: http://marc.info/?l=lyx-devel&m=134892838821370&w=2 http://marc.info/?l=lyx-devel&m=134895067903019&w=2 http://www.lyx.org/trac/ticket/8250 Best, Scott
Re: [PATCH] InsetTabular code cleanup
Am 08.12.2012 08:09, schrieb Scott Kostyshak:
While studying InsetTabular{.cpp,.h}, I have some suggestions and questions.
In the 0001 patch attached, am I missing something or can we remove
cur.selection in the conditions?
I would leave them in. It makes sense to me that we don#t accept a "down" selection if only the
current cell is selected.
In 0003, can I rename "copy-column" and "copy-row" to
"duplicate-column" and "duplicate-row"? The features do not just copy
but they also insert. The both together seem more of a "duplicate"
functionality.
OK, if you like to. But for me "copy row " implies that the row content will appear somewhere else.
So it is either a cut+paste or copy+paste. In the first case it is not a duplication. But I don't
have a string opinion about the naming of the LFUN. But if you do the change, please also update our
LFUN list and the LFUN documentation LyX-file.
There are also a few things I did not change but that I find confusing:
Why isn't "col_type" not named "col_num" and row_type "row_num"?
Does the "_type" emphasize that it's a typedef?
I don't know. This must have historical reasons.
- I find it unintuitive that a cell that is at the beginning of a
multirow is not "part" of a multirow:
See, for example, Tabular::isPartOfMultiRow.
I guess my confusion is because of:
CELL_BEGIN_OF_MULTICOLUMN,
///
CELL_PART_OF_MULTICOLUMN,
From a programming point of view, I understand why they are treated
differently, but from an interface point of view, I wonder if there
could be better names. I can't think of any though.
Form the technical point of view there was no other solution and prom the UI point of view as a user
you are never confronted with this and thus won't notice.
- My same comment as above but for isPartOfMultiColumn.
Dito.
I have two questions regarding the following code, which is in
function <>,
switch (action) {
case Tabular::SET_PWIDTH:
case Tabular::SET_MPWIDTH:
case Tabular::SET_SPECIAL_COLUMN:
case Tabular::SET_SPECIAL_MULTICOLUMN:
case Tabular::APPEND_ROW:
case Tabular::APPEND_COLUMN:
case Tabular::DELETE_ROW:
case Tabular::DELETE_COLUMN:
case Tabular::COPY_ROW:
case Tabular::COPY_COLUMN:
case Tabular::SET_TOP_SPACE:
case Tabular::SET_BOTTOM_SPACE:
case Tabular::SET_INTERLINE_SPACE:
status.clear();
return true;
(1) What is the purpose of this status.clear()?
(2) Why is "return true" used here instead of "break" (there is a
"return true" right after the cases and all the other cases use
"break")? Is this just inconsistent style or do they not provide
equivalent functionality?
I also don't know.
regards Uwe
Retina Support
Hey, Are there any plans to provide retina display support for LyX? What exactly does it entail? Karan
Re: [DECISION] final layout patches for branch
Am 10.12.2012 18:59, schrieb Richard Heck: Sorry, but why do you decide before I could comment? Please read my comments from today. I judged that further discussion was not going to change people's minds, as indeed it did not. I was very upset because I currently invest a huge portion of my spare time for LyX and I think that everybody should get the time to argue. I currently cannot write posts every day. Moreover, before we change something fundamental like our layout update policy, we should bring this to the users list. At the devel list we only have people who know a lot about the background of LyX/LaTeX and therefore sometimes loose the focus what is important for the average users. Take for example the proposal with different layouts for different document class versions. If we do this, we would force our users to learn what a layout it, why there are version numbers different from LyX's one and much more. my experience from discussions in the past is that it often helped if average users posted their opinions that we developers often did not had in mind. Is it a consensus if one developer is not fine with that? Consensus doesn't necessarily mean unanimous consensus. We almost never have that, and at some point we have to decide what to do. That's not my point. If you decide before all developers have the feeling the discussion is over, it is hard to expect that everybody accepts a decision. What about the users? Have you ever thought about them and/or asked them? (Se my first mail from today.) Yes, of course. We are all thinking about the users. We *are* users, after all. Yes, but we know so much more than an average user. let's say a student writing his master's thesis. Thus my statement above. So what does my change break? Here's my problem: If we do things as you propose, then we have different layout files with the same name under 2.0.5 and 2.0.6. I understand your point. But as said, who really downgrades from a working LyX 2.0.6 to 2.0.5? We in the past always added styles to layouts because our major releases only take place every 2 years while the document class progress is much faster. Please have a look of the layout file changes during the 2.0.x cycle. It was not only me who added a style to layouts, others did that as well and for scientific classes we will have to do it anyway for the reasons I stated. But as this issue is so fundamental, I request that you bring this to the users list and decide then. So people using two different minor versions on two different machines will find that a single document won't even load properly on the older version. And that passing it back and forth between the two causes all kinds of problems. Specifically, files created with the new ACM and europecv layouts will not load properly in 2.0.5. - the changes for europeCV are cosmetic ones: I only added styles for things one currently has to specify in the preamble. I can retract my patch for this document class - for ACM we will have no other choice because your paper won't be accepted for submission without the new styles. So if you reject my patch for ACm, you force users to read the submission guidelines after they notice that their submission was rejected. They will then find out that they will have to add things as ERT. (But only experiences users know how to handle ERT.) Is this our aim? My proposal is to ship the new layout, but with a new, versioned name. I'm opposed to this, see my arguments in the new thread I started. For modernCV I am not able to deliver a layout for every document class release, also not if I try to. For the document class files: I state it the last time: You have to fulfill the submission guidelines. The journals don't care of your OS and versions. If you don't fulfill the guidelines, you won't be accepted, point! Yes, but you are assuming something that does not seem evident, namely: that everyone who is using these class files is doing so because they are planning to submit their paper to a journal that uses that class file. Of course, because that is what these document classes and thus our layouts are designed for. That is not true. People have old files that got rejected, but they keep them in that format anyway. Those files should not stop working because they upgraded LyX. As I stated, except of the case with Springer old files keep compilable. None of may changes break the compilation of existing files. Also pre-prints, editor notes, etc. work fine. Besides this, just today I got this mail: - Am 12.12.2012 22:05, schrieb yoderj: > Uwe, > > Don't know if I'm contacting the right person (found your email through a > quick Google search), but ... > > Thanks for writing the page > > http://wiki.lyx.org/Examples/Springer > > It made it trivial for me to get LyX working with Springer's svjour3 class. > Not only that, the writing was clear & pro
Re: [patch] final layout patches for branch
Am 10.12.2012 10:16, schrieb Jean-Marc Lasgouttes: To try to discuss concrete example, could you give me a quick description of typical changes that have occurred between these moderncv releases? I would like to see how bad it is. Compared to modernCV < 1.0 the commands for the language and computer were replaced by more generic commands. This lead in one case (forgot if for computer or language) to a change in the number of arguments. This was the reason why I could not simply use the ObsoletedBy statement. But besides this, the example file that comes with LyX 2.0.5 is compilable as it is. But as soon as you cahnge e.g. the address and the street name becomes a bit longer, the document is no longer compilable. The same is if you change the style and/or color scheme of your CV. I failed to find out why this happens and with what version of modernCV this was introduced. So the example file we have in LyX 2.0.5 is not useful if you are using the latest modernCV 1.2.x. Note that TeXLive 2012 contains also modernCV 1.2.1 - as MiKTeX does. So many users will sooner or later be confronted with this issue. Concerning the right of the moderncv author to break his user's documents every few months "to fix bugs", I will just point out that LaTeX2e has been basically frozen for the last 10-15 years and that is the reason why it is still a useful tool. Hmm, but look e.g. at the changelog of such an important package like hyperref. I personally found there some bugs that kindly got fixed very quickly. Some changes in hyperref introduced regressions but we all make sometimes mistakes. Another example is KOMA-script. I would compare the situation with C++: this programming language is stable since a long time, but the programs you can write with it are not - as for example LyX. regards Uwe p.s. You asked if I could release a new Win version of LyX 2.0.5 using Qt 4.8.4 because this fixed a bug. So you did something normal - you want to keep the versions up to date to provide the users a bug-free LyX experience. The same is my intention, also with the layouts.
Restart layout update discussion; was: Re: [patch] final layout patches for branch
Dear colleagues, sorry for the delay, but my spare time is currently very limited. Before I will comment on the different posts in the old thread I want to summarize what we are discussing about because the old thread is a mixture of different topics and misunderstandings. The different points are: 1. backward compatibility I'm not opposed to provide backward compatibility in general. That's why I always invested a lot of time in lyx2lyx code, see my commits for the InsetArgument stuff. However, I think that we should be flexible enough to make changes to layouts to keep them compilable with the latest version of a document class. (It is a very rare case that this breaks forward compatibility and modernCV is such a case, but let's discuss this in another thread). The point is to be user friendly. My experience is that people expect an up to date example/template file. Before starting to write e.g. a paper many users update their software and then try to keep it untouched until the paper is accepted. So we can expect that a non-negligible amount of users will be confronted with an updated document class or submission guideline. The strength of LyX in my opinion is that it helps you in the workflow such that you are not forced to step through the submission guidelines in detail but can start writing a paper. So having an up to date example/template file is very useful. This might require to add a style in a layout file but this is no problem as long as you still can compile your existing LyX files with it. 2. scientific document classes As a submitter you will have to follow always the latest submission guidelines. So having an outdated example/template file would be frustrating for the users if they wonder why the submission systems reject the TeX-files created with LyX. OK, we could add required new styles as ERT but this is in my opinion not user-friendly and opposed to the goal of LyX not to confront the user with "evil" things. To fulfill the submission guidelines you will in any case have to use the latest version of the document class for your journal so we don#t do anything wrong to keep the layout files for scientific classes up to date. 3. "my LaTeX system is too old" This topic is something I don't understand that we even discuss about it. I mean where do we cut the line what we require? Everybody of us developers added some styles to layout files and that would break the compilation if you have a very old LaTeX installation. Take for example the case of the latest additions to KOMA-script made by Jürgen. These styles support commands in KOMA-script that are in recent TeX distributions, but for example not in the old teTeX 3. So a user might complain about that. But I think you would agree that we don't rely anymore on teTeX but on e.g. TeXLive. However, there are many TeXLive versions around and users could e.g. use TeXLive 2011 but with recent document classes (installed manually or by TeXLive's update mechanism). MiKTeX users will in most cases use always the latest package versions. Our aim is platform in dependency so the only thing we can do to please all users, no matter what OS and TeX-distribution they use, we have to assure that the latest package version is compliable with the layouts we provide. I agree that we should try to keep old documents compilable and we could do so in the past (except for e.g. Springer). If users encounter problems, they can update the corresponding LaTeX-package and it will work again while users using the latest Package version cannot downgrade and downgrading is for example with MiKTeX and also TeXLive (at least on Windows) not possible. So if the compilability requires a layout file change, we should do that and announce that in the release notes. Otherwise our layouts will become more and more less useful with the time and from a user's point of view it is incomprehensible why LyX would only update layouts every 2 years with a new major LyX version. In general note that if we got bug reports in e.g. LyX 1.6.8 in our bugtracker or the mailing lists we tell the users to update LyX. The same is expected by the TeX package authors. 4. the proposal with layouts for different document class versions Please imagine what you know as an average user. As such a user you don't know the TeX internals and also not how LyX interacts with LaTeX in detail. Assuming you want to make a presentation, you know that you have to select a presentation class. But if there would be 4 different versions for different versions of beamer you would be lost. Because how can you know what version you have? You will then be forced to invest a lot of time searching the docs or Wiki to find this out. For the developer point of view this proposal would force the layout authors to revise the layouts for every package release. For example for modernCV I would be forced to write maybe 3 different layouts for the different modernCV versions
Re: Where to use qt4 (Re: Export-to fails for xhtml)
Op 11-12-2012 13:09, Pavel Sanda schreef: Tommaso Cucinotta wrote: Yes, everything compiles fine. Also ColorCache.h was not giving any trouble, till I included it in graphics/PreviewLoader.cpp, because then gcc complained it cannot find QColor nor QPalette (and I had to add the QtGui/). Yes I understand the issue now. Qt4 creeping out of qt4/ directory. I don't have strong opinion since we already crossed the line in server and compare feature. But other may have some comments as well, it's not just technical issue (shall we get rid of frontend/qt4 structure?) Pavel The reasons we have crossed the line is to make use of the cross-platform implementation of Qt. This doesn't mean that we can pull in frontend or gui stuff into the core. Vincent
Re: An idea on improving the literate programming support
On Thu, Dec 13, 2012 at 10:55 AM, Yihui Xie wrote: > Hi, > > One idea about literate programming in LyX has been in my mind for a > while, and I'm wondering how you think about it. I'll take > Sweave/knitr for example: > > One nice feature of R language is that it can be used interactively, > which is very helpful for us to do some experimental or exploratory > analysis before we come up with a final data analysis report. I was > thinking perhaps we could send R code from LyX to R like Emacs/ESS and > RStudio do, e.g. open a system shell or command window from LyX, and > send R code there to be evaluated. At the moment we can only compile > the whole LyX document in a batch manner. > > I have no idea about the implementation. Any feedback is welcome. Thanks! I wonder if this ticket has something to say about implementation: http://www.lyx.org/trac/ticket/7404 If each inset had an option to "edit externally" then the user could set the "edit command" to whatever he/she wanted. Scott
An idea on improving the literate programming support
Hi, One idea about literate programming in LyX has been in my mind for a while, and I'm wondering how you think about it. I'll take Sweave/knitr for example: One nice feature of R language is that it can be used interactively, which is very helpful for us to do some experimental or exploratory analysis before we come up with a final data analysis report. I was thinking perhaps we could send R code from LyX to R like Emacs/ESS and RStudio do, e.g. open a system shell or command window from LyX, and send R code there to be evaluated. At the moment we can only compile the whole LyX document in a batch manner. I have no idea about the implementation. Any feedback is welcome. Thanks! Regards, Yihui -- Yihui Xie Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA
GPL statement
I hereby grant permission to license my contributions to LyX under the Gnu General Public Licence, version 2 or later. Zahari Dmitrov Kassabov
Re: [LyX 2.0.x] While exporting from the command-line, theApp() doesn't exist. It was only needed for getting hex names of colors. So, get them directly from a ColorCache object with default mapping.
On 13/12/12 01:51, Richard Heck wrote: > > Need status.20x for this. [64f57912/lyxgit] T.
