On 04/25/2011 07:07 PM, Johannes Wilm wrote:
I think this is a non-discussion. Neither one of us can control what
Lyx-developers choose to decide in 3-7 years, when LyX3.0 comes out.
Make it 10 ;-)
Some of us will be retired by then...
Abdel.
Ramin Nakisa wrote:
> Could I please have a password so I can do this?
LyX
pavel
On 26-4-2011 9:32, Abdelrazak Younes wrote:
> On 04/25/2011 07:07 PM, Johannes Wilm wrote:
>> I think this is a non-discussion. Neither one of us can control what
>> Lyx-developers choose to decide in 3-7 years, when LyX3.0 comes out.
>
> Make it 10 ;-)
I like your optimism.
Vincent
On 04/26/2011 10:11 AM, Vincent van Ravesteijn wrote:
On 26-4-2011 9:32, Abdelrazak Younes wrote:
On 04/25/2011 07:07 PM, Johannes Wilm wrote:
I think this is a non-discussion. Neither one of us can control what
Lyx-developers choose to decide in 3-7 years, when LyX3.0 comes out.
Make it 10 ;
Johannes Wilm wrote:
> Ok, some parts of the gui for bibtopic support may be reusable then. But
> the bibtex-commands involved are different and the latex-commands are
> different and the gui will have to give different options. So in the end I
> really don't think it makes sense to try to mix the
On 26-4-2011 10:13, Abdelrazak Younes wrote:
> On 04/26/2011 10:11 AM, Vincent van Ravesteijn wrote:
>> On 26-4-2011 9:32, Abdelrazak Younes wrote:
>>> On 04/25/2011 07:07 PM, Johannes Wilm wrote:
I think this is a non-discussion. Neither one of us can control what
Lyx-developers choose
Liviu Andronic wrote:
> Normally there is a fixed width space between guillemets and the
> wrapped text: « asdf ». However, when using non-TeX fonts (Libertine
> or Palladio) and compile with XeTeX, the first space is missing: «asdf
> ». When, on the other hand, I use TeX fonts (Palatino) and stil
Hi guys,
I cannot remember that, but I am full time administrator on my computer, so I
guess it should answer your question.
Best regards,
Pascal
-Original Message-
From: LyX Ticket Tracker [mailto:t...@lyx.org]
Sent: jeudi 21 avril 2011 22:46
To: pas...@gaggero.ch; lasgout...@lyx.org
Le 26/04/2011 10:13, Jürgen Spitzmüller a écrit :
At any rate, at least 90% of the bibliography gui stuff will have to be
completely redone for biblatex.
That's for sure. I do not deny it's a major task. I just think it will get
better the more we try to abstract from a concrete package (biblat
On 04/26/2011 10:17 AM, Vincent van Ravesteijn wrote:
On 26-4-2011 10:13, Abdelrazak Younes wrote:
On 04/26/2011 10:11 AM, Vincent van Ravesteijn wrote:
On 26-4-2011 9:32, Abdelrazak Younes wrote:
On 04/25/2011 07:07 PM, Johannes Wilm wrote:
I think this is a non-discussion. Neither one of us
Le 26/04/2011 08:54, Liviu Andronic a écrit :
On Tue, Apr 26, 2011 at 8:47 AM, Liviu Andronic wrote:
Dear all
I'm writing a document in French using RC3 and I spot some dubious
behaviour concerning the French guillemets. See attached.
Normally there is a fixed width space between guillemets a
Le 26/04/2011 10:25, Abdelrazak Younes a écrit :
Shouldn't we start with 2.1 first?
I guess there will still be 2.0.x bug fix release an that Jürgen will
keep maintain them.
Yes; no.
I'd like to propose that 2.x release are only about GUI improvements and
code cleanup. IOW 2.x should keep th
On Tue, Apr 26, 2011 at 10:19 AM, Jürgen Spitzmüller wrote:
> Liviu Andronic wrote:
>> Normally there is a fixed width space between guillemets and the
>> wrapped text: « asdf ». However, when using non-TeX fonts (Libertine
>> or Palladio) and compile with XeTeX, the first space is missing: «asdf
On 04/26/2011 10:29 AM, Jean-Marc Lasgouttes wrote:
Le 26/04/2011 10:25, Abdelrazak Younes a écrit :
Shouldn't we start with 2.1 first?
I guess there will still be 2.0.x bug fix release an that Jürgen will
keep maintain them.
Yes; no.
If not Jürgen then who? You?
I'd like to propose that
On Tue, Apr 26, 2011 at 10:25 AM, Jean-Marc Lasgouttes
wrote:
>>> Normally there is a fixed width space between guillemets and the
>>> wrapped text: « asdf ».
>>>
>> We're talking about a thin space missing here ("\,"). See attached.
>> Liviu
>
> What is the TeX output? I am not sure that quotes
Jean-Marc Lasgouttes wrote:
> I am not sure that quotes output has been
> adapted to xetex and friends. Note also that the extra space only
> appears when the document is in french.
Polyglossia seems to support it. Here is the relevant excerpt from my log:
) (/usr/local/texlive/2010/texmf-dist/
Abdelrazak Younes wrote:
> > Yes; no.
>
> If not Jürgen then who? You?
You.
Seriously, this is not decided yet. I have to talk to some people in the next
days (I will not write names now so they cannot hide).
I'll post some more info here soon.
Jürgen
On Tue, Apr 26, 2011 at 10:39 AM, Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:
>> I am not sure that quotes output has been
>> adapted to xetex and friends. Note also that the extra space only
>> appears when the document is in french.
>
> Polyglossia seems to support it. Here is the re
On 04/26/2011 10:43 AM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Yes; no.
If not Jürgen then who? You?
You.
Bouh!
Il 25/04/2011 14:56, rgh...@lyx.org ha scritto:
Author: rgheck
Date: Mon Apr 25 14:56:09 2011
New Revision: 38496
URL: http://www.lyx.org/trac/changeset/38496
Log:
Fix crash when there are text insets in a table cell with decimal alignment.
This is discussed in these threads:
. . . and the te
Abdelrazak Younes wrote:
>>> I'd like to propose that 2.x release are only about GUI improvements and
>>> code cleanup. IOW 2.x should keep the file format unchanged.
>>
>> How are you going to do that? No format change? This is not going to
>> happen.
>
> Why not? Why should be rush in changing t
> Shouldn't we start with 2.1 first?
Yes.
>
> I guess there will still be 2.0.x bug fix release an that Jürgen will keep
> maintain them.
We should ask Jurgen whether he wants to continue doing this job, then we
should query whether there are other candidates and then we would need to
organize
On 04/26/2011 10:48 AM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
I'd like to propose that 2.x release are only about GUI improvements and
code cleanup. IOW 2.x should keep the file format unchanged.
How are you going to do that? No format change? This is not going to
happen.
Why not? Why sh
Vincent van Ravesteijn wrote:
> > I guess there will still be 2.0.x bug fix release an that Jürgen will
> > keep maintain them.
>
> We should ask Jurgen whether he wants to continue doing this job
Actually, I wanted to wait some more days until I have talked with potential
succesors, but since i
On 04/26/2011 10:59 AM, Vincent van Ravesteijn wrote:
I'd like to propose that 2.x release are only about GUI improvements and code
cleanup. IOW 2.x should keep the file format unchanged.
3.0 would in this scheme introduce a new file format, maybe XML, maybe not.
You're just moving up the min
Slightly off-topic..
On Tue, Apr 26, 2011 at 10:59 AM, Vincent van Ravesteijn wrote:
> I'd prefer to continue with the current versioning scheme and introduce
> LyX3.0 when there is a significant change, or when we think LyX has taken
> another step in maturity.
>
In this sense the decision to st
Vincent van Ravesteijn wrote:
> I'd prefer to continue with the current versioning scheme and introduce
> LyX3.0 when there is a significant change, or when we think LyX has taken
> another step in maturity.
+1
> Git uses another level in-between, but I think that is a bit too much
> given the fa
Abdelrazak Younes wrote:
> That's also why time between releases are sooo long... 2 or 3 releases
> every six without file format changes sounds very appealing to the user
> that I am. To the developer, this means that his pet feature will arrive
> sooner to the users.
>
> The file format change
>> Git uses another level in-between, but I think that is a bit too much
>> given the fact that there are not that many developers testing other one's
>> features to the bone. We just don't have manpower to do that.
>
> git branching is nice for development where you have hundreds of people
> ar
Vincent van Ravesteijn wrote:
> What happens is that the topic branches are _really_ regularly merged into
> the "development" branch which stands on top of the "trunk" branch and which
> developers should use in stead of "trunk".
this looks good.
> The more advantageous users that want to use "t
hi all,
trunk is frozen from now on, all commits to code must have my OK.
i'm waiting for a few last localisaztion contributions but apart
from it we are done. either wed or thu evening i'll prepare tarballs.
anything important you still want to have in 2.0.0?
something new about #7490?
pavel
On 26-4-2011 12:32, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
>> What happens is that the topic branches are _really_ regularly merged into
>> the "development" branch which stands on top of the "trunk" branch and which
>> developers should use in stead of "trunk".
>
> this looks good.
>
Vincent van Ravesteijn wrote:
> > i'm not convinced about this, but perhaps only trying it can show us...
> > to me each new layer just divides the number of testing people. if somebody
> > want stable trunk for usage and not development he should stick to alpha/...
>
> According to the current pr
Two notes about the bugs in the bug tracker:
- Please do not blindly retarget all bugs with a 1.6.x milestone
to 2.0.x. Let's only target bugs for 2.0.x which we think should
be fixed in this cycle. Bugs that haven't been touched or looked
upon in the last two years, surely don't deserve thi
Vincent van Ravesteijn wrote:
> Two notes about the bugs in the bug tracker:
>
> - Please do not blindly retarget all bugs with a 1.6.x milestone
> to 2.0.x. Let's only target bugs for 2.0.x which we think should
> be fixed in this cycle. Bugs that haven't been touched or looked
> upon in th
> unless the branch is merged into some kind of trunk that means they will have
> incongruent version of file format. if they are just users, thats showstopper
> with dataloss possibility due to some lyx2lyx chaos later.
I assume a user wants to use/try the new feature not before it is stable
and
Stephan Witt wrote:
> > if you added some feature which is not in our manuals yet (or outdated)
> > please
> > consider to contribute documentation to it as well. (please remember to
> > switch
> > on the change tracking so our translators see whats happening).
>
> I feel some responsibility her
>>>
>>> - We can think of having several branches: e.g., LyX3.0 (or experimental)
>>> /LyX2.1 (or development)/LyX2.0.1(or maintenance)
>>
>> There are certainly benefits.
>
> these were all true. i wouldn't divide development on 3 layers though.
> just keeping experimental branch in a working
Am 26.04.2011 um 13:21 schrieb Pavel Sanda:
> Stephan Witt wrote:
>>> if you added some feature which is not in our manuals yet (or outdated)
>>> please
>>> consider to contribute documentation to it as well. (please remember to
>>> switch
>>> on the change tracking so our translators see whats
On 04/26/2011 04:48 AM, Tommaso Cucinotta wrote:
Il 25/04/2011 14:56, rgh...@lyx.org ha scritto:
Author: rgheck
Date: Mon Apr 25 14:56:09 2011
New Revision: 38496
URL: http://www.lyx.org/trac/changeset/38496
Log:
Fix crash when there are text insets in a table cell with decimal
alignment. This
On 04/26/2011 04:48 AM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
Most "active" developers (I am not) are already using git AFAIK...
i dont think you are right (highly depends on Richard) if we count it on the
number of commits. i use git personally but i'm not so excited about the change
be
> I'm not opposed to moving to git, but I do not use it, and never have, so it
> would mean some learning here.
Well, we'll guide you through. When doing svn-like development,
there is not much to learn. If you want to use all git features,
you might want to learn, but that's just fun.
As said
On 04/26/2011 05:04 AM, Abdelrazak Younes wrote:
On 04/26/2011 10:48 AM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
I'd like to propose that 2.x release are only about GUI
improvements and
code cleanup. IOW 2.x should keep the file format unchanged.
How are you going to do that? No format ch
On 04/26/2011 05:57 AM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
That's also why time between releases are sooo long... 2 or 3 releases
every six without file format changes sounds very appealing to the user
that I am. To the developer, this means that his pet feature will arrive
sooner to th
On 04/26/2011 07:17 AM, Vincent van Ravesteijn wrote:
Two notes about the bugs in the bug tracker:
- Please do not blindly retarget all bugs with a 1.6.x milestone
to 2.0.x. Let's only target bugs for 2.0.x which we think should
be fixed in this cycle. Bugs that haven't been touched or loo
On 04/26/2011 02:40 PM, Richard Heck wrote:
On 04/26/2011 05:04 AM, Abdelrazak Younes wrote:
On 04/26/2011 10:48 AM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
I'd like to propose that 2.x release are only about GUI
improvements and
code cleanup. IOW 2.x should keep the file format unchanged
On 04/26/2011 02:45 PM, Richard Heck wrote:
On 04/26/2011 05:57 AM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
That's also why time between releases are sooo long... 2 or 3 releases
every six without file format changes sounds very appealing to the user
that I am. To the developer, this means
I did some investigation of this, and maybe we can fix it before we
land. It is pretty nasty.
Here's the backtrace:
0 raise raise.c 64 0x3726c330c5
1 abort abort.c 92 0x3726c34a76
2 lyx::lyx_exit LyX.cpp 236 0x510568
3 boost::assertion_failed boost.cpp 47 0x460e5d
4 lyx::doAssert lassert.cpp
On 04/26/2011 08:57 AM, Abdelrazak Younes wrote:
On 04/26/2011 02:40 PM, Richard Heck wrote:
The file format change is _the_ reason why people are kept back with
older version of LyX. 2 or 3 years time is OK for a file format
change but 6 months is obviously not.
The problem here is that so
On Tue, Apr 26, 2011 at 2:57 PM, Abdelrazak Younes wrote:
> I would be glad if we could be more liberal indeed. But then we would also
> need bug fixing only releases. If you allow some new big features at one
> point, say 2.0.2 and then declare that 2.0.3 will only be about bug fixing
> because
I know that I don't really have a vote in this things, but I can't help but
jump in on the conversation.
> So the idea is to have two parallel development trees, basically: One that is
> devoted to changes that do not touch the file format, like GUI improvements,
> and one where we can make for
On Apr 26, 2011, at 8:33 AM, Liviu Andronic wrote:
> One possibility is to use the Xfce numbering scheme: odd for
> development releases and even for stable releases. For example, 2.0.0
> is the major stable release, 2.0.2 is the minor stable release, 2.0.3
> is the minor development release.
Th
Vincent van Ravesteijn wrote:
> I'm not advocating to have 3 layers in general.
ok, Abdel is :)
if i understand correctly there are 3 proposals:
1) 3 trees:
- agile (gui things)
- trunk (fileformat)
- stable
2) 2 trees, 3 trees in freze transitions
3) current scheme with sooner alpha.
1 is mo
On 04/26/2011 10:34 AM, Rob Oakes wrote:
I'm also worried about what effect it might have on the release schedule.
Fragmenting the code might also fragment developers. Would all GUI related
changes be automatically merged with the non-GUI branch (meaning that all GUI
related bugs also end up i
Sure, the user can put it manually under "LaTeX options" but I think it
would be helpful to have a text box. This way, LyX could also display that
page instead of the first page.
Would this be difficult? My guess is that the text box would not be
difficult, but displaying the correct page would be
On 04/26/2011 10:46 AM, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
I'm not advocating to have 3 layers in general.
ok, Abdel is :)
if i understand correctly there are 3 proposals:
1) 3 trees:
- agile (gui things)
- trunk (fileformat)
- stable
2) 2 trees, 3 trees in freze transitions
3
On 26-4-2011 16:46, Pavel Sanda wrote:
> Vincent van Ravesteijn wrote:
>> I'm not advocating to have 3 layers in general.
>
> ok, Abdel is :)
>
> if i understand correctly there are 3 proposals:
>
> 1) 3 trees:
> - agile (gui things)
> - trunk (fileformat)
> - stable
>
> 2) 2 trees, 3 trees in
Though it's completely arbitrary, a six month release schedule might make
sense. Once a year for format changes, once a year for file formats? It seems
to have worked well for Ubuntu, KDE and Gnome ...
Cheers,
Rob
On 26-4-2011 17:00, Richard Heck wrote:
> On 04/26/2011 10:46 AM, Pavel Sanda wrote:
>> Vincent van Ravesteijn wrote:
>>> I'm not advocating to have 3 layers in general.
>> ok, Abdel is :)
>>
>> if i understand correctly there are 3 proposals:
>>
>> 1) 3 trees:
>> - agile (gui things)
>> - trunk (f
Isn't interesting to update the Graphical Tour of LyX?
http://www.lyx.org/Walkthrough
It is mentioned in splash.lyx document but there is a long time it isn't
updated...
I think it should be updated with the final release of LyX 2.0.0.
---
Diego Queiroz
And how about the lyx.org site?
How to proceed to start a translation of it in Portuguese?
And how about a portuguese mailing list?
Regards,
---
Diego Queiroz
2011/4/25 Diego Queiroz
> Thanks Pavel. :-)
>
> ---
> Diego Queiroz
>
>
>
>
> 2011/4/25 Pavel Sanda
>
>> Diego Queiroz wrote:
>> >
Vincent van Ravesteijn wrote:
> file-format changes releases.
i must admit that being lately forced to cooperate with people
not having full control over the version of LyX installed
release cycle of 2 years does not sound so bad to me ;-p
1.5->1.6 took 1,5 years and i dont remember such preasur
Diego Queiroz wrote:
> Isn't interesting to update the Graphical Tour of LyX?
>
> http://www.lyx.org/Walkthrough
>
> It is mentioned in splash.lyx document but there is a long time it isn't
> updated...
>
>
> I think it should be updated with the final release of LyX 2.0.0.
the question is: wi
Le 26/04/2011 17:23, Diego Queiroz a écrit :
Isn't interesting to update the Graphical Tour of LyX?
http://www.lyx.org/Walkthrough
Of course, it would be very interesting (and to add some of the most
important new features).
JMarc
On 04/26/2011 05:29 PM, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
file-format changes releases.
i must admit that being lately forced to cooperate with people
not having full control over the version of LyX installed
release cycle of 2 years does not sound so bad to me ;-p
Which is exa
On 04/26/2011 05:00 PM, Richard Heck wrote:
I am still wondering if there is not some way to proceed here that
would allow more new features that do not touch file format into the
stable branch. It seems to me that the main concern is that some new
features that could have been included in 1.6.
On 04/26/2011 05:30 PM, Pavel Sanda wrote:
Diego Queiroz wrote:
Isn't interesting to update the Graphical Tour of LyX?
http://www.lyx.org/Walkthrough
It is mentioned in splash.lyx document but there is a long time it isn't
updated...
I think it should be updated with the final release of LyX
On 26-4-2011 17:34, Abdelrazak Younes wrote:
> On 04/26/2011 05:29 PM, Pavel Sanda wrote:
>> Vincent van Ravesteijn wrote:
>>> file-format changes releases.
>> i must admit that being lately forced to cooperate with people
>> not having full control over the version of LyX installed
>> release cycl
On 04/26/2011 05:40 PM, Vincent van Ravesteijn wrote:
On 26-4-2011 17:34, Abdelrazak Younes wrote:
On 04/26/2011 05:29 PM, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
file-format changes releases.
i must admit that being lately forced to cooperate with people
not having full control over
Le 26/04/2011 17:40, Vincent van Ravesteijn a écrit :
So we will have
(maintenance releases)
2.0.0.0 end of april 2011
2.0.0.1 end of may 2011
2.0.0.2 end of july 2011
2.0.0.3 end of september 2011
(new feature releases)
2.0.1.0 end of october 2011
2.0.2.0 end of april 2012
2.0.3.0 end of octob
On 04/26/2011 05:52 PM, Jean-Marc Lasgouttes wrote:
Le 26/04/2011 17:40, Vincent van Ravesteijn a écrit :
So we will have
(maintenance releases)
2.0.0.0 end of april 2011
2.0.0.1 end of may 2011
2.0.0.2 end of july 2011
2.0.0.3 end of september 2011
(new feature releases)
2.0.1.0 end of octobe
> 2.1.0.0 could happen sooner of course if we think we have reached
> something worth releasing (like the bib stuff or the epub export).
Yes of course. Given that there are only non-file-format changes,
there is no reason not to do that more often.
>
> Another important argument in favor of freq
> I'd drop the stunning releases and increment the major version
> at each format change, in this case. Too many numbers.
Raising the first number every 2 years leads to 10.0 in 2032.
That doesn't seem like a reason not to do it.
Anyone objects to this ?
>
> JMarc
Vincent
> I'd drop the stunning releases and increment the major version
> at each format change, in this case. Too many numbers.
I mean LyX-10.0 in 2028 of course ;)
>
> JMarc
Vincent
> I'd drop the stunning releases and increment the major version
> at each format change, in this case. Too many numbers.
Wouldn't this be confusing for the user that suddenly 2.0/2.1/2.2
have the same file format. So he can easily upgrade. He is used to
having a stable file format only during the
LOL
That was not exactly what I was thinking of (lazyness), but I can handle
that.
I'll work on it this afternoon. :-)
BTW I think it won't take a long time to just update the images.
It will be ok if I use LyX 2.0.0 RC3, right?
---
Diego Queiroz
2011/4/26 Pavel Sanda
> Diego Queiroz wrote
Will this mean that we will not be allowed to put bib-information into the
header until 2013?
On Tue, Apr 26, 2011 at 9:08 AM, Vincent van Ravesteijn wrote:
> > I'd drop the stunning releases and increment the major version
> > at each format change, in this case. Too many numbers.
>
> Wouldn't
On 26-4-2011 18:12, Johannes Wilm wrote:
> Will this mean that we will not be allowed to put bib-information into the
> header until 2013?
>
At the earliest point in time, this will be released in the end of 2012 indeed.
This seems long, but in practice we need the time. Fixing all little bugs
On 04/26/2011 06:08 PM, Vincent van Ravesteijn wrote:
I'd drop the stunning releases and increment the major version
at each format change, in this case. Too many numbers.
Wouldn't this be confusing for the user that suddenly 2.0/2.1/2.2
have the same file format. So he can easily upgrade. He is
On Tue, Apr 26, 2011 at 9:18 AM, Vincent van Ravesteijn wrote:
> On 26-4-2011 18:12, Johannes Wilm wrote:
> > Will this mean that we will not be allowed to put bib-information into
> the header until 2013?
> >
>
> At the earliest point in time, this will be released in the end of 2012
> indeed.
>
> ok, I can understand that. I just wondered whether there is some
> differentiation
> in file format changes. For example, adding bibliography-info there, like I
> did
> with a little test patch, does not mean that the file no longer can be opened
> from an earlier version of LyX.
I don't know
Vincent van Ravesteijn wrote:
> Wouldn't this be confusing for the user that suddenly 2.0/2.1/2.2
> have the same file format.
that was my concern as well... p
On Tue, Apr 26, 2011 at 9:35 AM, Vincent van Ravesteijn wrote:
...
> I know there are different opinions about what a file format change is.
> Some people say that every change in LaTeX output is basically a file
> format change. That is, the same file gives a different output, and
> thus the for
Abdelrazak Younes wrote:
> we are always seeing new
> developers around new releases; 2.0 is no exception.
this looks as interesting insight, the more that i do not recognize that ;)
isn't it just illusion made by the fact the we are in freeze, rejecting new
stuff
and (hopefully) nicely expalini
On 26-4-2011 18:48, Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>> we are always seeing new
>> developers around new releases; 2.0 is no exception.
>
> this looks as interesting insight, the more that i do not recognize that ;)
> isn't it just illusion made by the fact the we are in freeze, rej
On 04/26/2011 06:48 PM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
we are always seeing new
developers around new releases; 2.0 is no exception.
this looks as interesting insight, the more that i do not recognize that ;)
isn't it just illusion made by the fact the we are in freeze, rejecting n
On 26-4-2011 18:55, Abdelrazak Younes wrote:
> On 04/26/2011 06:48 PM, Pavel Sanda wrote:
>> Abdelrazak Younes wrote:
>>> we are always seeing new
>>> developers around new releases; 2.0 is no exception.
>> this looks as interesting insight, the more that i do not recognize that ;)
>> isn't it just
Diego Queiroz wrote:
> LOL
>
> That was not exactly what I was thinking of (lazyness), but I can handle
> that.
>
> I'll work on it this afternoon. :-)
> BTW I think it won't take a long time to just update the images.
>
> It will be ok if I use LyX 2.0.0 RC3, right?
sure
pavel
Diego Queiroz wrote:
> And how about the lyx.org site?
> How to proceed to start a translation of it in Portuguese?
do you intend to create and maintain portuguese version of lyx site?
pavel
On 04/26/2011 12:18 PM, Vincent van Ravesteijn wrote:
On 26-4-2011 18:12, Johannes Wilm wrote:
Will this mean that we will not be allowed to put bib-information into the
header until 2013?
At the earliest point in time, this will be released in the end of 2012 indeed.
This seems long, but in
On 25.04.2011 14:37, nbubis wrote:
Here's an attempt with a small 'y' :)
Thanks again to all the "real" developers for an awesome piece of software -
somewhere around the world a future Nobel prize winner is writing his thesis
with LyX.
Thanks, also looks good. But I was wrong, it's indeed a
> > Shouldn't we start with 2.1 first?
>
> Yes.
This thread is growing fast and I don't know if this is the right place for
features, but I've been thinking of some features it would be nice to have in
LyX:
- scripting: it would be great to allow community to contribute with plugins,
maybe for so
On 26/04/2011 11:40 AM, Vincent van Ravesteijn wrote:
new feature releases
I would keep the numbering as it is and allow new feature releases once
a year. As long as we are careful about the format conversion (and I
have seen that this is very serious), then it's not a problem for users
to j
On 26.04.2011 14:37, Vincent van Ravesteijn wrote:
I'm not opposed to moving to git, but I do not use it, and never have, so it
would mean some learning here.
Well, we'll guide you through. When doing svn-like development,
there is not much to learn. If you want to use all git features,
you mi
I have produced a new version of the layout files, the test files, and
the templates. It has been posted to the bug tracker.
This new version is now fully backward compatible. However, the style
abstract now behaves differently as the current implementation is broken.
The following price ha
On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months.
However, everyone needs to become used to using git, we need to decide on
a place to host the
Vincent van Ravesteijn wrote:
> I agree. It is stupid to have new and exciting features to be stalled
> for two years before being released.
acting as the devils advocate, one good thing about the current release
model is that we have stable (i mean _STABLE_) 1.6.10 product for people
who look for
On 26.04.2011 19:51, venom00 wrote:
Shouldn't we start with 2.1 first?
Yes.
This thread is growing fast and I don't know if this is the right place for
features, but I've been thinking of some features it would be nice to have in
LyX:
- scripting: it would be great to allow community to contr
On 26.04.2011 20:14, Julien Rioux wrote:
On 26/04/2011 4:59 AM, Vincent van Ravesteijn wrote:
It would be possible to use svn/git together for one release cycle. I've
been maintaining a git repo parallel to the svn repo for the last few months.
However, everyone needs to become used to using git
Peter Kümmel wrote:
> And one additional advantage of working on one branch is the ability to
> "communicate" over this channel, everyone could jump in without switching
> the branch.
yep, if there is something unusable about git branches its online switching
between them.
single change in some h
1 - 100 of 133 matches
Mail list logo
