Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
On Sunday 16 March 2008 15:12:39 Jürgen Spitzmüller wrote: José, can I shove it in? Take this instead. It changes some text\InsetSpace type some more text to some text \begin_inset Space type \end_inset some more text which is necessary to parse the length argument properly. I've added the necessary lyx2lyx routines and adapted the code accordingly. OK, please commit. BTW I will clean the code of lyx_1_6.py before release. There are lots of code where lines with \n are added. This breaks a fundamental assumption of lyx2lyx that says that each line is in a separate list entry. The code cleaning is on my todo list before 1.6.0 and it is a blocker bug. I will not release 1.6.0 before this is solved. Jürgen -- José Abílio
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
José Matos wrote: OK, please commit. Done, thanks. BTW I will clean the code of lyx_1_6.py before release. Good. There are lots of code where lines with \n are added. This breaks a fundamental assumption of lyx2lyx that says that each line is in a separate list entry. I wasn't aware of this. Is this documented somewhere? The code cleaning is on my todo list before 1.6.0 and it is a blocker bug. I will not release 1.6.0 before this is solved. Jürgen
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
On Monday 17 March 2008 09:24:38 Jürgen Spitzmüller wrote: There are lots of code where lines with \n are added. This breaks a fundamental assumption of lyx2lyx that says that each line is in a separate list entry. I wasn't aware of this. No. It is implicit since it follows the same structure of the lyx lexer. Sometimes the new lines are ignored, like when a paragraph is broken in several lines in the lyx files, but there are situations where the the new lines are significant. Notice that this is precisely the reason why you had to normalize the code to start an InsetSpace in a new line. This is also the trend that we have been following a more regular syntax since the demise of the 2.15 file format (that I compare to a hydra). http://en.wikipedia.org/wiki/Lernaean_Hydra Is this documented somewhere? I have not documented this behaviour because my hope goes to the xml file format where this paradigm does not apply anymore. Jürgen -- José Abílio
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
On Sunday 16 March 2008 15:12:39 Jürgen Spitzmüller wrote: > > José, can I shove it in? > > Take this instead. > > It changes > some text\InsetSpace type > some more text > to > some text > \begin_inset Space type > \end_inset > some more text > > which is necessary to parse the length argument properly. I've added the > necessary lyx2lyx routines and adapted the code accordingly. OK, please commit. BTW I will clean the code of lyx_1_6.py before release. There are lots of code where lines with \n are added. This breaks a fundamental assumption of lyx2lyx that says that each line is in a separate list entry. The code cleaning is on my todo list before 1.6.0 and it is a blocker bug. I will not release 1.6.0 before this is solved. > Jürgen -- José Abílio
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
José Matos wrote: > OK, please commit. Done, thanks. > BTW I will clean the code of lyx_1_6.py before release. Good. > There are lots of code where lines with \n are added. This breaks a > fundamental assumption of lyx2lyx that says that each line is in a separate > list entry. I wasn't aware of this. Is this documented somewhere? > The code cleaning is on my todo list before 1.6.0 and it is a blocker bug. > I will not release 1.6.0 before this is solved. Jürgen
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
On Monday 17 March 2008 09:24:38 Jürgen Spitzmüller wrote: > > > There are lots of code where lines with \n are added. This breaks a > > fundamental assumption of lyx2lyx that says that each line is in a > > separate list entry. > > I wasn't aware of this. No. It is implicit since it follows the same structure of the lyx lexer. Sometimes the new lines are ignored, like when a paragraph is broken in several lines in the lyx files, but there are situations where the the new lines are significant. Notice that this is precisely the reason why you had to normalize the code to start an InsetSpace in a new line. This is also the trend that we have been following a more regular syntax since the demise of the 2.15 file format (that I compare to a hydra). http://en.wikipedia.org/wiki/Lernaean_Hydra > Is this documented somewhere? I have not documented this behaviour because my hope goes to the xml file format where this paradigm does not apply anymore. > Jürgen -- José Abílio
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Enrico Forestieri wrote:
I think that there should be some visual difference between enspace,
quad, qquad, and custom spaces. ATM they all look the same.
Well, this is exactly the metrics problem I was talking about.
Just as a suggestion, maybe your new inset could support leaders.
Leaders are a special case of glue as far as TeX is concerned.
Ordinary glue fills space with nothing, while leaders fill space
with any desired thing. For example, \leaderssome box\hskipglue
has the same effect as \hskipglue except that the specified box
is used as a fill pattern.
A \lspace macro could be defined as
\def\lspace#1#2{\vrule [EMAIL PROTECTED]@\nobreak
\leaders\hbox{#1}\hskip #2\hskip [EMAIL PROTECTED]
and then used as follows:
\lspace{$\rightarrow$}{\fill}
\lspace{ $\rightarrow$ }{\fill}
\lspace{.-}{5cm}
\lspace{abc}{5cm}
In this way a fill pattern could also be defined by the user for
custom lengths.
I think this is something for later.
Jürgen
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Stefan Schimanski wrote: Yes, I don't think the following is what you want to do. The loop will set basically every inset to width 5. Aha! Logic strikes back again. Thanks. Jürgen
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Enrico Forestieri wrote:
> I think that there should be some visual difference between enspace,
> quad, qquad, and custom spaces. ATM they all look the same.
Well, this is exactly the metrics problem I was talking about.
> Just as a suggestion, maybe your new inset could support leaders.
> Leaders are a special case of glue as far as TeX is concerned.
> Ordinary glue fills space with nothing, while leaders fill space
> with any desired thing. For example, \leaders\hskip
> has the same effect as \hskip except that the specified box
> is used as a fill pattern.
>
> A \lspace macro could be defined as
>
> \def\lspace#1#2{\vrule [EMAIL PROTECTED]@\nobreak
> \leaders\hbox{#1}\hskip #2\hskip [EMAIL PROTECTED]
>
> and then used as follows:
>
> \lspace{$\rightarrow$}{\fill}
>
> \lspace{ $\rightarrow$ }{\fill}
>
> \lspace{.-}{5cm}
>
> \lspace{abc}{5cm}
>
> In this way a fill pattern could also be defined by the user for
> custom lengths.
I think this is something for later.
Jürgen
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Stefan Schimanski wrote: > Yes, I don't think the following is what you want to do. The loop will > set basically every inset to width 5. Aha! Logic strikes back again. Thanks. Jürgen
[patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Juergen Spitzmueller wrote:
It is basically complete and already works. The feature is a dialog for
InsetSpace similar to our VSpace dialog (bug 2078), which also merges HFill
into InsetSpace (thus lets you switch between the diverse spaces and
hfill). The boni are: support for \hspace and \hspace* (bug 2075), \dotfill
and \hrulefill. Furthermore, it fixes bug 4555 (hfill drawing).
The remaining problems are: one specific lyx2lyx reversion problem and some
metrics problems (all non-fill spaces are drawn in the same width). I think
these are trivial, I just need some time. I'll try to finish it at the
weekend.
Here's the patch. Lyx2lyx works now, the metrics problem remains, and I'm
stuck with that. Maybe someone has an idea.
Otherwise, objections?
Jürgen
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (Revision 23764)
+++ lib/lyx2lyx/LyX.py (Arbeitskopie)
@@ -80,7 +80,7 @@
(1_3, [221], minor_versions(1.3 , 7)),
(1_4, range(222,246), minor_versions(1.4 , 5)),
(1_5, range(246,277), minor_versions(1.5 , 2)),
- (1_6, range(277,319), minor_versions(1.6 , 0))]
+ (1_6, range(277,320), minor_versions(1.6 , 0))]
def formats_list():
Index: lib/lyx2lyx/lyx_1_6.py
===
--- lib/lyx2lyx/lyx_1_6.py (Revision 23764)
+++ lib/lyx2lyx/lyx_1_6.py (Arbeitskopie)
@@ -1259,14 +1259,14 @@
continue
l = find_token(document.body, '\tsubcaptionText', i, j)
caption = get_value(document.body, '\tsubcaptionText', i, j).strip('')
-savestr = document.body[i]
+savebegin = document.body[i]
+saveend = document.body[j]
+document.body[j] = '\n\\end_layout\n\n\\end_inset\n' + saveend
+del document.body[k]
+del document.body[l]
document.body[i] = '\\begin_inset Float figure\nwide false\nsideways false\n' \
'status open\n\n\\begin_layout PlainLayout\n\\begin_inset Caption\n\n\\begin_layout PlainLayout\n' \
-+ caption + '\n\\end_layout\n\n\\end_inset\n\n\\end_layout\n\n\\begin_layout PlainLayout\n' + savestr
-savestr = document.body[j]
-document.body[j] = '\n\\end_layout\n\n\\end_inset\n' + savestr
-del document.body[k]
-del document.body[l]
++ caption + '\n\\end_layout\n\n\\end_inset\n\n\\end_layout\n\n\\begin_layout PlainLayout\n' + savebegin
def revert_subfig(document):
@@ -1388,6 +1388,53 @@
return
document.header.pop(i)
+
+def convert_hfill(document):
+Convert hfill to space inset
+i = 0
+while True:
+i = find_token(document.body, \\hfill, i)
+if i == -1:
+return
+document.body[i] = document.body[i].replace('\\hfill', '\\InsetSpace \\hfill{}')
+
+
+def revert_hfills(document):
+'Revert \\hfill commands'
+for i in range(len(document.body)):
+document.body[i] = document.body[i].replace('\\InsetSpace \\hfill{}', '\\hfill')
+document.body[i] = document.body[i].replace('\\InsetSpace \\dotfill{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'dotfill{}\n\\end_layout\n\n\\end_inset\n\n')
+document.body[i] = document.body[i].replace('\\InsetSpace \\hrulefill{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'hrulefill{}\n\\end_layout\n\n\\end_inset\n\n')
+
+
+def revert_hspace(document):
+'Revert \\InsetSpace \\hspace{} to ERT'
+i = 0
+while True:
+i = find_token(document.body, \\InsetSpace \\hspace, i)
+if i == -1:
+return
+length = get_value(document.body, '\\length', i+1)
+if length == '':
+document.warning(Malformed lyx document: Missing '\\length' in Space inset.)
+return
+del document.body[i+1]
+document.body[i] = document.body[i].replace('\\InsetSpace \\hspace*{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'hspace*{' + length + '}\n\\end_layout\n\n\\end_inset\n\n')
+document.body[i] = document.body[i].replace('\\InsetSpace \\hspace{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'hspace{' + length + '}\n\\end_layout\n\n\\end_inset\n\n')
+
+
##
# Conversion hub
#
@@ -1435,9 +1482,11 @@
[316, [convert_subfig]],
[317, []],
[318, []],
+ [319, [convert_hfill]]
]
-revert = [[317, [remove_extra_embedded_files]],
+revert = [[318, [revert_hfills, revert_hspace]],
+ [317, [remove_extra_embedded_files]],
[316, [revert_wrapplacement]],
[315, [revert_subfig]],
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Am 15.03.2008 um 19:28 schrieb Jürgen Spitzmüller:
Juergen Spitzmueller wrote:
It is basically complete and already works. The feature is a dialog
for
InsetSpace similar to our VSpace dialog (bug 2078), which also
merges HFill
into InsetSpace (thus lets you switch between the diverse spaces and
hfill). The boni are: support for \hspace and \hspace* (bug 2075),
\dotfill
and \hrulefill. Furthermore, it fixes bug 4555 (hfill drawing).
The remaining problems are: one specific lyx2lyx reversion problem
and some
metrics problems (all non-fill spaces are drawn in the same width).
I think
these are trivial, I just need some time. I'll try to finish it at
the
weekend.
Here's the patch. Lyx2lyx works now, the metrics problem remains,
and I'm
stuck with that. Maybe someone has an idea.
Otherwise, objections?
Yes, I don't think the following is what you want to do. The loop will
set basically every inset to width 5.
diff --git a/src/TextMetrics.cpp b/src/TextMetrics.cpp
index 73e50a8..d728d77 100644
--- a/src/TextMetrics.cpp
+++ b/src/TextMetrics.cpp
@@ -626,7 +626,8 @@ void TextMetrics::computeRowMetrics(pit_type const
pit,
InsetList::const_iterator iend = par.insetList().end();
for ( ; ii != iend; ++ii) {
if (ii-pos = endpos || ii-pos row.pos()
- || ii-inset-lyxCode() != HFILL_CODE)
+ || (ii-inset-lyxCode() != SPACE_CODE
+ ii-inset-isStretchableSpace()))
continue;
Dimension dim = row.dimension();
if (pm.hfillExpansion(row, ii-pos))
Stefan
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
On Sat, Mar 15, 2008 at 07:28:07PM +0100, Jürgen Spitzmüller wrote:
Here's the patch. Lyx2lyx works now, the metrics problem remains, and I'm
stuck with that. Maybe someone has an idea.
Otherwise, objections?
I think that there should be some visual difference between enspace,
quad, qquad, and custom spaces. ATM they all look the same.
Just as a suggestion, maybe your new inset could support leaders.
Leaders are a special case of glue as far as TeX is concerned.
Ordinary glue fills space with nothing, while leaders fill space
with any desired thing. For example, \leaderssome box\hskipglue
has the same effect as \hskipglue except that the specified box
is used as a fill pattern.
A \lspace macro could be defined as
\def\lspace#1#2{\vrule [EMAIL PROTECTED]@\nobreak
\leaders\hbox{#1}\hskip #2\hskip [EMAIL PROTECTED]
and then used as follows:
\lspace{$\rightarrow$}{\fill}
\lspace{ $\rightarrow$ }{\fill}
\lspace{.-}{5cm}
\lspace{abc}{5cm}
In this way a fill pattern could also be defined by the user for
custom lengths.
--
Enrico
[patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Juergen Spitzmueller wrote:
> It is basically complete and already works. The feature is a dialog for
> InsetSpace similar to our VSpace dialog (bug 2078), which also merges HFill
> into InsetSpace (thus lets you switch between the diverse spaces and
> hfill). The boni are: support for \hspace and \hspace* (bug 2075), \dotfill
> and \hrulefill. Furthermore, it fixes bug 4555 (hfill drawing).
>
> The remaining problems are: one specific lyx2lyx reversion problem and some
> metrics problems (all non-fill spaces are drawn in the same width). I think
> these are trivial, I just need some time. I'll try to finish it at the
> weekend.
Here's the patch. Lyx2lyx works now, the metrics problem remains, and I'm
stuck with that. Maybe someone has an idea.
Otherwise, objections?
Jürgen
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (Revision 23764)
+++ lib/lyx2lyx/LyX.py (Arbeitskopie)
@@ -80,7 +80,7 @@
("1_3", [221], minor_versions("1.3" , 7)),
("1_4", range(222,246), minor_versions("1.4" , 5)),
("1_5", range(246,277), minor_versions("1.5" , 2)),
- ("1_6", range(277,319), minor_versions("1.6" , 0))]
+ ("1_6", range(277,320), minor_versions("1.6" , 0))]
def formats_list():
Index: lib/lyx2lyx/lyx_1_6.py
===
--- lib/lyx2lyx/lyx_1_6.py (Revision 23764)
+++ lib/lyx2lyx/lyx_1_6.py (Arbeitskopie)
@@ -1259,14 +1259,14 @@
continue
l = find_token(document.body, '\tsubcaptionText', i, j)
caption = get_value(document.body, '\tsubcaptionText', i, j).strip('"')
-savestr = document.body[i]
+savebegin = document.body[i]
+saveend = document.body[j]
+document.body[j] = '\n\\end_layout\n\n\\end_inset\n' + saveend
+del document.body[k]
+del document.body[l]
document.body[i] = '\\begin_inset Float figure\nwide false\nsideways false\n' \
'status open\n\n\\begin_layout PlainLayout\n\\begin_inset Caption\n\n\\begin_layout PlainLayout\n' \
-+ caption + '\n\\end_layout\n\n\\end_inset\n\n\\end_layout\n\n\\begin_layout PlainLayout\n' + savestr
-savestr = document.body[j]
-document.body[j] = '\n\\end_layout\n\n\\end_inset\n' + savestr
-del document.body[k]
-del document.body[l]
++ caption + '\n\\end_layout\n\n\\end_inset\n\n\\end_layout\n\n\\begin_layout PlainLayout\n' + savebegin
def revert_subfig(document):
@@ -1388,6 +1388,53 @@
return
document.header.pop(i)
+
+def convert_hfill(document):
+"Convert hfill to space inset"
+i = 0
+while True:
+i = find_token(document.body, "\\hfill", i)
+if i == -1:
+return
+document.body[i] = document.body[i].replace('\\hfill', '\\InsetSpace \\hfill{}')
+
+
+def revert_hfills(document):
+'Revert \\hfill commands'
+for i in range(len(document.body)):
+document.body[i] = document.body[i].replace('\\InsetSpace \\hfill{}', '\\hfill')
+document.body[i] = document.body[i].replace('\\InsetSpace \\dotfill{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'dotfill{}\n\\end_layout\n\n\\end_inset\n\n')
+document.body[i] = document.body[i].replace('\\InsetSpace \\hrulefill{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'hrulefill{}\n\\end_layout\n\n\\end_inset\n\n')
+
+
+def revert_hspace(document):
+'Revert \\InsetSpace \\hspace{} to ERT'
+i = 0
+while True:
+i = find_token(document.body, "\\InsetSpace \\hspace", i)
+if i == -1:
+return
+length = get_value(document.body, '\\length', i+1)
+if length == '':
+document.warning("Malformed lyx document: Missing '\\length' in Space inset.")
+return
+del document.body[i+1]
+document.body[i] = document.body[i].replace('\\InsetSpace \\hspace*{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'hspace*{' + length + '}\n\\end_layout\n\n\\end_inset\n\n')
+document.body[i] = document.body[i].replace('\\InsetSpace \\hspace{}', \
+'\\begin_inset ERT\nstatus collapsed\n\n' \
+'\\begin_layout Standard\n\n\n\\backslash\n' \
+'hspace{' + length + '}\n\\end_layout\n\n\\end_inset\n\n')
+
+
##
# Conversion hub
#
@@ -1435,9 +1482,11 @@
[316, [convert_subfig]],
[317, []],
[318, []],
+ [319, [convert_hfill]]
]
-revert = [[317, [remove_extra_embedded_files]],
+revert = [[318, [revert_hfills, revert_hspace]],
+ [317, [remove_extra_embedded_files]],
[316, [revert_wrapplacement]],
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
Am 15.03.2008 um 19:28 schrieb Jürgen Spitzmüller:
Juergen Spitzmueller wrote:
It is basically complete and already works. The feature is a dialog
for
InsetSpace similar to our VSpace dialog (bug 2078), which also
merges HFill
into InsetSpace (thus lets you switch between the diverse spaces and
hfill). The boni are: support for \hspace and \hspace* (bug 2075),
\dotfill
and \hrulefill. Furthermore, it fixes bug 4555 (hfill drawing).
The remaining problems are: one specific lyx2lyx reversion problem
and some
metrics problems (all non-fill spaces are drawn in the same width).
I think
these are trivial, I just need some time. I'll try to finish it at
the
weekend.
Here's the patch. Lyx2lyx works now, the metrics problem remains,
and I'm
stuck with that. Maybe someone has an idea.
Otherwise, objections?
Yes, I don't think the following is what you want to do. The loop will
set basically every inset to width 5.
diff --git a/src/TextMetrics.cpp b/src/TextMetrics.cpp
index 73e50a8..d728d77 100644
--- a/src/TextMetrics.cpp
+++ b/src/TextMetrics.cpp
@@ -626,7 +626,8 @@ void TextMetrics::computeRowMetrics(pit_type const
pit,
InsetList::const_iterator iend = par.insetList().end();
for ( ; ii != iend; ++ii) {
if (ii->pos >= endpos || ii->pos < row.pos()
- || ii->inset->lyxCode() != HFILL_CODE)
+ || (ii->inset->lyxCode() != SPACE_CODE &&
+ ii->inset->isStretchableSpace()))
continue;
Dimension dim = row.dimension();
if (pm.hfillExpansion(row, ii->pos))
Stefan
Re: [patch] InsetSpace GUI (was: Re: Time for 1.6 alpha?)
On Sat, Mar 15, 2008 at 07:28:07PM +0100, Jürgen Spitzmüller wrote:
> Here's the patch. Lyx2lyx works now, the metrics problem remains, and I'm
> stuck with that. Maybe someone has an idea.
>
> Otherwise, objections?
I think that there should be some visual difference between enspace,
quad, qquad, and custom spaces. ATM they all look the same.
Just as a suggestion, maybe your new inset could support leaders.
Leaders are a special case of glue as far as TeX is concerned.
Ordinary glue fills space with nothing, while leaders fill space
with any desired thing. For example, \leaders\hskip
has the same effect as \hskip except that the specified box
is used as a fill pattern.
A \lspace macro could be defined as
\def\lspace#1#2{\vrule [EMAIL PROTECTED]@\nobreak
\leaders\hbox{#1}\hskip #2\hskip [EMAIL PROTECTED]
and then used as follows:
\lspace{$\rightarrow$}{\fill}
\lspace{ $\rightarrow$ }{\fill}
\lspace{.-}{5cm}
\lspace{abc}{5cm}
In this way a fill pattern could also be defined by the user for
custom lengths.
--
Enrico
Re: Time for 1.6 alpha?
Andre Poenitz [EMAIL PROTECTED] writes: On Thu, Mar 13, 2008 at 09:46:16AM +0100, Jean-Marc Lasgouttes wrote: José Matos [EMAIL PROTECTED] writes: Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? I am currently playing with the qt code in the configure script (use qmake to get to qt flags), but I am not sure it will work out to be usable. What kind of information are you trying to extract from qmake? I would like to use it like pkg-config (but working also with the Qt/Mac binaries provided by trolltech). Here is my current patch, using a set of m4 macros I found somewhere (there is probably room for simplfication in there). The problem now on the mac is that the macros expect qmake to generate a makefile by default. On the mac, it produces a xcode project now (since 4.3?). I guess I could work around this, but the result would be very fragile, I guess. JMarc svndiff Index: src/frontends/qt4/Makefile.am === --- src/frontends/qt4/Makefile.am (revision 23686) +++ src/frontends/qt4/Makefile.am (working copy) @@ -8,15 +8,15 @@ CLEANFILES += $(BUILT_SOURCES) # Qt stuff # # Use _() for localization instead of tr() or trUtf8() -UIC4FLAGS=-tr lyx::qt_ +UICFLAGS=-tr lyx::qt_ ui_%.h: ui/%.ui - $(UIC4) $(UIC4FLAGS) $ -o $@ + $(UIC) $(UICFLAGS) $ -o $@ MOCEDFILES = $(MOCHEADER:%.h=%_moc.cpp) %_moc.cpp: %.h - $(MOC4) -o $@ $ + $(MOC) -o $@ $ Resources.qrc: Makefile echo !DOCTYPE RCCRCC version='1.0'qresource $@ @@ -26,7 +26,7 @@ Resources.qrc: Makefile echo /qresource/RCC $@ Resources.cpp: Resources.qrc - $(RCC4) $ -name Resources -o $@ + $(RCC) $ -name Resources -o $@ # LIBRARIES # @@ -34,15 +34,15 @@ Resources.cpp: Resources.qrc noinst_LTLIBRARIES = liblyxqt4.la liblyxqt4_la_DEPENDENCIES = $(MOCEDFILES) -liblyxqt4_la_LDFLAGS = $(QT4_LDFLAGS) -liblyxqt4_la_LIBADD = $(QT4_LIB) +liblyxqt4_la_LDFLAGS = $(QT_LDFLAGS) +liblyxqt4_la_LIBADD = $(QT_LIB) AM_CPPFLAGS += \ - $(QT4_CPPFLAGS) \ + $(QT_CPPFLAGS) \ -I$(top_srcdir)/src \ -I$(top_srcdir)/src/frontends \ -I$(top_srcdir)/images \ - $(QT4_INCLUDES) $(BOOST_INCLUDES) + $(BOOST_INCLUDES) SOURCEFILES = \ ButtonPolicy.cpp \ Index: src/Makefile.am === --- src/Makefile.am (revision 23686) +++ src/Makefile.am (working copy) @@ -23,6 +23,9 @@ OTHERLIBS = $(BOOST_LIBS) $(INTLLIBS) $( noinst_LTLIBRARIES = liblyxcore.la bin_PROGRAMS = lyx +lyx_CXXFLAGS = $(QT_CXXFLAGS) $(AM_CXXFLAGS) +lyx_CPPFLAGS = $(QT_CPPFLAGS) $(AM_CPPFLAGS) +lyx_LDFLAGS = $(QT_LDFLAGS) $(LDFLAGS) lyx_LDADD = \ liblyxcore.la \ liblyxmathed.la \ @@ -32,7 +35,7 @@ lyx_LDADD = \ liblyxgraphics.la \ support/liblyxsupport.la \ $(OTHERLIBS) \ - $(QT4_LIB) + $(QT_LIBS) if LYX_WIN_RESOURCE .rc.o: Index: src/support/Makefile.am === --- src/support/Makefile.am (revision 23686) +++ src/support/Makefile.am (working copy) @@ -7,8 +7,7 @@ EXTRA_DIST = pch.h \ noinst_LTLIBRARIES = liblyxsupport.la -liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(QT4_CORE_LIB) $(BOOST_SIGNALS) -liblyxsupport_la_LDFLAGS = $(QT4_CORE_LDFLAGS) +liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(BOOST_SIGNALS) BUILT_SOURCES = $(PCH_FILE) @@ -23,7 +22,7 @@ CLEANFILES += $(MOCEDFILES) BUILT_SOURCES += $(MOCEDFILES) %_moc.cpp: %.h - $(MOC4) -o $@ $ + $(MOC) -o $@ $ liblyxsupport_la_DEPENDENCIES = $(MOCEDFILES) @@ -31,7 +30,7 @@ liblyxsupport_la_DEPENDENCIES = $(MOCEDF ## AM_CPPFLAGS += $(PCH_FLAGS) -I$(srcdir)/.. $(BOOST_INCLUDES) -AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES) -I$(srcdir)/minizip +AM_CPPFLAGS += $(QT_CPPFLAGS) -I$(srcdir)/minizip # force the use of C++ compiler for minizip/*.c files, because # gcc can not go through the included boost files. @@ -145,8 +144,8 @@ check_PROGRAMS = \ check_lstrings check_convert_LDADD = ../debug.o convert.o docstring.o lstrings.o unicode.o \ - $(BOOST_LIBS) $(QT4_CORE_LIB) -check_convert_LDFLAGS = $(QT4_CORE_LDFLAGS) + $(BOOST_LIBS) $(QT_CORE_LIBS) +check_convert_LDFLAGS = $(QT_CORE_LDFLAGS) check_convert_SOURCES = \ tests/check_convert.cpp \ tests/boost.cpp @@ -157,8 +156,8 @@ check_filetools_SOURCES = \ tests/boost.cpp check_lstrings_LDADD = ../debug.o lstrings.o convert.o docstring.o unicode.o \ - $(QT4_CORE_LIB) -check_lstrings_LDFLAGS = $(QT4_CORE_LDFLAGS) + $(QT_CORE_LIB) +check_lstrings_LDFLAGS = $(QT_CORE_LDFLAGS) check_lstrings_SOURCES = \ tests/check_lstrings.cpp \ tests/boost.cpp Index: src/client/Makefile.am === --- src/client/Makefile.am (revision 23686) +++
Re: Time for 1.6 alpha?
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Thu, Mar 13, 2008 at 09:46:16AM +0100, Jean-Marc Lasgouttes wrote: >> José Matos <[EMAIL PROTECTED]> writes: >> > Other than Juergen who has another feature waiting in the backburner? >> > How >> > much time do you need to put the feature in? >> >> I am currently playing with the qt code in the configure script (use >> qmake to get to qt flags), but I am not sure it will work out to be >> usable. > > What kind of information are you trying to extract from qmake? I would like to use it like pkg-config (but working also with the Qt/Mac binaries provided by trolltech). Here is my current patch, using a set of m4 macros I found somewhere (there is probably room for simplfication in there). The problem now on the mac is that the macros expect qmake to generate a makefile by default. On the mac, it produces a xcode project now (since 4.3?). I guess I could work around this, but the result would be very fragile, I guess. JMarc svndiff Index: src/frontends/qt4/Makefile.am === --- src/frontends/qt4/Makefile.am (revision 23686) +++ src/frontends/qt4/Makefile.am (working copy) @@ -8,15 +8,15 @@ CLEANFILES += $(BUILT_SOURCES) # Qt stuff # # Use _() for localization instead of tr() or trUtf8() -UIC4FLAGS=-tr lyx::qt_ +UICFLAGS=-tr lyx::qt_ ui_%.h: ui/%.ui - $(UIC4) $(UIC4FLAGS) $< -o $@ + $(UIC) $(UICFLAGS) $< -o $@ MOCEDFILES = $(MOCHEADER:%.h=%_moc.cpp) %_moc.cpp: %.h - $(MOC4) -o $@ $< + $(MOC) -o $@ $< Resources.qrc: Makefile echo "" > $@ @@ -26,7 +26,7 @@ Resources.qrc: Makefile echo "" >> $@ Resources.cpp: Resources.qrc - $(RCC4) $< -name Resources -o $@ + $(RCC) $< -name Resources -o $@ # LIBRARIES # @@ -34,15 +34,15 @@ Resources.cpp: Resources.qrc noinst_LTLIBRARIES = liblyxqt4.la liblyxqt4_la_DEPENDENCIES = $(MOCEDFILES) -liblyxqt4_la_LDFLAGS = $(QT4_LDFLAGS) -liblyxqt4_la_LIBADD = $(QT4_LIB) +liblyxqt4_la_LDFLAGS = $(QT_LDFLAGS) +liblyxqt4_la_LIBADD = $(QT_LIB) AM_CPPFLAGS += \ - $(QT4_CPPFLAGS) \ + $(QT_CPPFLAGS) \ -I$(top_srcdir)/src \ -I$(top_srcdir)/src/frontends \ -I$(top_srcdir)/images \ - $(QT4_INCLUDES) $(BOOST_INCLUDES) + $(BOOST_INCLUDES) SOURCEFILES = \ ButtonPolicy.cpp \ Index: src/Makefile.am === --- src/Makefile.am (revision 23686) +++ src/Makefile.am (working copy) @@ -23,6 +23,9 @@ OTHERLIBS = $(BOOST_LIBS) $(INTLLIBS) $( noinst_LTLIBRARIES = liblyxcore.la bin_PROGRAMS = lyx +lyx_CXXFLAGS = $(QT_CXXFLAGS) $(AM_CXXFLAGS) +lyx_CPPFLAGS = $(QT_CPPFLAGS) $(AM_CPPFLAGS) +lyx_LDFLAGS = $(QT_LDFLAGS) $(LDFLAGS) lyx_LDADD = \ liblyxcore.la \ liblyxmathed.la \ @@ -32,7 +35,7 @@ lyx_LDADD = \ liblyxgraphics.la \ support/liblyxsupport.la \ $(OTHERLIBS) \ - $(QT4_LIB) + $(QT_LIBS) if LYX_WIN_RESOURCE .rc.o: Index: src/support/Makefile.am === --- src/support/Makefile.am (revision 23686) +++ src/support/Makefile.am (working copy) @@ -7,8 +7,7 @@ EXTRA_DIST = pch.h \ noinst_LTLIBRARIES = liblyxsupport.la -liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(QT4_CORE_LIB) $(BOOST_SIGNALS) -liblyxsupport_la_LDFLAGS = $(QT4_CORE_LDFLAGS) +liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(BOOST_SIGNALS) BUILT_SOURCES = $(PCH_FILE) @@ -23,7 +22,7 @@ CLEANFILES += $(MOCEDFILES) BUILT_SOURCES += $(MOCEDFILES) %_moc.cpp: %.h - $(MOC4) -o $@ $< + $(MOC) -o $@ $< liblyxsupport_la_DEPENDENCIES = $(MOCEDFILES) @@ -31,7 +30,7 @@ liblyxsupport_la_DEPENDENCIES = $(MOCEDF ## AM_CPPFLAGS += $(PCH_FLAGS) -I$(srcdir)/.. $(BOOST_INCLUDES) -AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES) -I$(srcdir)/minizip +AM_CPPFLAGS += $(QT_CPPFLAGS) -I$(srcdir)/minizip # force the use of C++ compiler for minizip/*.c files, because # gcc can not go through the included boost files. @@ -145,8 +144,8 @@ check_PROGRAMS = \ check_lstrings check_convert_LDADD = ../debug.o convert.o docstring.o lstrings.o unicode.o \ - $(BOOST_LIBS) $(QT4_CORE_LIB) -check_convert_LDFLAGS = $(QT4_CORE_LDFLAGS) + $(BOOST_LIBS) $(QT_CORE_LIBS) +check_convert_LDFLAGS = $(QT_CORE_LDFLAGS) check_convert_SOURCES = \ tests/check_convert.cpp \ tests/boost.cpp @@ -157,8 +156,8 @@ check_filetools_SOURCES = \ tests/boost.cpp check_lstrings_LDADD = ../debug.o lstrings.o convert.o docstring.o unicode.o \ - $(QT4_CORE_LIB) -check_lstrings_LDFLAGS = $(QT4_CORE_LDFLAGS) + $(QT_CORE_LIB) +check_lstrings_LDFLAGS = $(QT_CORE_LDFLAGS) check_lstrings_SOURCES = \ tests/check_lstrings.cpp \ tests/boost.cpp Index: src/client/Makefile.am === --- src/client/Makefile.am (revision 23686) +++ src/client/Makefile.am
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
Bo Peng wrote: This one is caused by the Embedded stuff by Bo: Will fix it soon. Fixed. Thanks. There is also the bug that any included file is marked as (embedded) in the InsetInclude label, independently of the embedded status. I do not see this here. - New doc - insert - file - child doc - select a lyx doc, does check the embedded option. The include inset label have the tag (embedded). This is because we check the embed parameter for emptiness. But this parameter content is very bizarre IMHO, sometimes a file name, sometimes true or false. This needs fixing... Abdel.
Re: Time for 1.6 alpha?
José Matos [EMAIL PROTECTED] writes: Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? I am currently playing with the qt code in the configure script (use qmake to get to qt flags), but I am not sure it will work out to be usable. JMarc
Re: Time for 1.6 alpha?
On Wednesday 12 March 2008 17:58:03 Richard Heck wrote: No feature here. And I promise to stop refactoring. There's just one fairly minor thing left to do, and I'm talking with Abdel now about how to do it. Notice that at this time I was not complaining but simply stating a fact. I am happy with the latest code factorizations. :-) -- José Abílio
Re: Time for 1.6 alpha?
On Thursday 13 March 2008 08:46:16 Jean-Marc Lasgouttes wrote: I am currently playing with the qt code in the configure script (use qmake to get to qt flags), but I am not sure it will work out to be usable. A more robust building system is always an welcomed output. :-) I have no problem, within reasonable bounds, with this change going in during the beta stage. JMarc -- José Abílio
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
The include inset label have the tag (embedded). This is because we check the embed parameter for emptiness. But this parameter content is very bizarre IMHO, sometimes a file name, sometimes true or false. This needs fixing... I see. This is fixed for InsetInclude. I will have to change InsetExternal etc as well. Bo
Re: Time for 1.6 alpha?
On Thu, Mar 13, 2008 at 09:46:16AM +0100, Jean-Marc Lasgouttes wrote: José Matos [EMAIL PROTECTED] writes: Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? I am currently playing with the qt code in the configure script (use qmake to get to qt flags), but I am not sure it will work out to be usable. What kind of information are you trying to extract from qmake? Andre'
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
Bo Peng wrote: >> This one is caused by the Embedded stuff by Bo: > > Will fix it soon. Fixed. Thanks. There is also the bug that any included file is marked as (embedded) in the InsetInclude label, independently of the embedded status. I do not see this here. - New doc - insert -> file -> child doc - select a lyx doc, does check the embedded option. The include inset label have the tag "(embedded)". This is because we check the "embed" parameter for emptiness. But this parameter content is very bizarre IMHO, sometimes a file name, sometimes "true" or "false". This needs fixing... Abdel.
Re: Time for 1.6 alpha?
José Matos <[EMAIL PROTECTED]> writes: > Other than Juergen who has another feature waiting in the backburner? How > much time do you need to put the feature in? I am currently playing with the qt code in the configure script (use qmake to get to qt flags), but I am not sure it will work out to be usable. JMarc
Re: Time for 1.6 alpha?
On Wednesday 12 March 2008 17:58:03 Richard Heck wrote: > No feature here. And I promise to stop refactoring. There's just one > fairly minor thing left to do, and I'm talking with Abdel now about how > to do it. Notice that at this time I was not complaining but simply stating a fact. I am happy with the latest code factorizations. :-) -- José Abílio
Re: Time for 1.6 alpha?
On Thursday 13 March 2008 08:46:16 Jean-Marc Lasgouttes wrote: > I am currently playing with the qt code in the configure script (use > qmake to get to qt flags), but I am not sure it will work out to be > usable. A more robust building system is always an welcomed output. :-) I have no problem, within reasonable bounds, with this change going in during the beta stage. > JMarc -- José Abílio
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
> The include inset label have the tag "(embedded)". This is because we > check the "embed" parameter for emptiness. But this parameter content is > very bizarre IMHO, sometimes a file name, sometimes "true" or "false". > This needs fixing... I see. This is fixed for InsetInclude. I will have to change InsetExternal etc as well. Bo
Re: Time for 1.6 alpha?
On Thu, Mar 13, 2008 at 09:46:16AM +0100, Jean-Marc Lasgouttes wrote: > José Matos <[EMAIL PROTECTED]> writes: > > Other than Juergen who has another feature waiting in the backburner? How > > much time do you need to put the feature in? > > I am currently playing with the qt code in the configure script (use > qmake to get to qt flags), but I am not sure it will work out to be > usable. What kind of information are you trying to extract from qmake? Andre'
Re: Time for 1.6 alpha?
Citing our webpage: A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience. 24/02/08 Is there any big must-have feature which we should wait for? Otherwise I would propose to make it in the next days, maybe the weekend. I think the current version does feel quite ok for an alpha release. Stefan Am 21.02.2008 um 13:59 schrieb Abdelrazak Younes: José Matos wrote: On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote: Hm, are you sure about that? I agree with Jürgen, and I agree with Abdel (note that _probably_). :-) There is no need to be so specific about the number of expected releases. That will free us to release when deemed necessary without artificial constraints. OK so what about this: We are pleased to announce the release of LyX 1.5.4. This is a maintenance release that further improves the stability and the performance and still manages to bring some new features. This is probably going to another one or two 1.5.x release before LyX 1.6.0, which will be made available as a first alpha version later this week. Before the release of the final 1.6.0, a least one 1.5.x version that is able to read the 1.6 format will be released.
Re: Time for 1.6 alpha?
A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience. 24/02/08 Is there any big must-have feature which we should wait for? As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. Bo
Re: Time for 1.6 alpha?
Bo Peng wrote: As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. I have yet another feature in the pipe, but this could go in after alpha1. Jürgen
Re: Time for 1.6 alpha?
On Mar 12, 2008, at 10:30 AM, Bo Peng wrote: A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience. 24/02/08 Is there any big must-have feature which we should wait for? As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. There are, I think, a couple of recent bugs that should be addressed first (or am I the only one experiencing these?). 1. Loading open files from last session does not work. 2. Every time I open a file, save it, and open it again, it opens as changed, so that if I immediately close it it asks if I want to save. I'd still like to have window behavior changed ... at least on Mac. Now that multiple windows is working so well, I'd like to see the default behavior be to open new documents in their own window. This could be done with changing some keybindings, but for it to work well, we'd need to do two things: (a) close the LyX window when there is no document open -- so that we never have a window with just the LyX banner; and (b) allow LyX to remain running when all windows are closed. Of course I say we'd need to do these when I'm not in a position to do it. But I'd at least like to see if this is relatively simple (even if only on Mac) and whether others might find it worth taking up the cause. Bennett
Re: Time for 1.6 alpha?
There are, I think, a couple of recent bugs that should be addressed first (or am I the only one experiencing these?). My understanding is that alpha one means 1. all 1.6.x features are more or less ready 2. a loss feature freeze, basically no new feature is allowed. 3. let us start fixing bugs like what Bennett mentioned. Of course Jose has the authority to define alpha one, and order the release of it. Cheers, Bo
Re: Time for 1.6 alpha?
My understanding is that alpha one means 1. all 1.6.x features are more or less ready 2. a loss feature freeze, basically no new feature is allowed. 3. let us start fixing bugs like what Bennett mentioned. Of course Jose has the authority to define alpha one, and order the release of it. http://permalink.gmane.org/gmane.editors.lyx.devel/81717 p
Re: Time for 1.6 alpha?
http://permalink.gmane.org/gmane.editors.lyx.devel/81717 So my understanding was more or less correct, and we are ready for alpha one. :-) Bo
Re: Time for 1.6 alpha?
On Mar 12, 2008, at 11:32 AM, Bo Peng wrote: There are, I think, a couple of recent bugs that should be addressed first (or am I the only one experiencing these?). My understanding is that alpha one means 1. all 1.6.x features are more or less ready 2. a loss feature freeze, basically no new feature is allowed. 3. let us start fixing bugs like what Bennett mentioned. But the point of an alpha release isn't simply to impose a feature freeze on developers, as this suggests; it's to get feedback from users. If the bugs are obvious and annoying, it will look like it wasn't really ready to be released even as an alpha and I suspect that we'd get both multiple reports of these bugs and fewer people interested in using the alpha enough to discover more important bugs. But that's just a hunch Bennett
Re: Time for 1.6 alpha?
But the point of an alpha release isn't simply to impose a feature freeze on developers, as this suggests; it's to get feedback from users. I see your point, although I consider alpha as 'peek for new features', and only beta as 'let us test and report bugs'. I mean, we do not need user feedbacks to find bugs at the alpha stage. Bo
Re: Time for 1.6 alpha?
Juergen Spitzmueller wrote: Bo Peng wrote: As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. I have yet another feature in the pipe, but this could go in after alpha1. Tell us about it pretty please :-) Abdel.
Re: Time for 1.6 alpha?
Bo Peng wrote: But the point of an alpha release isn't simply to impose a feature freeze on developers, as this suggests; it's to get feedback from users. I see your point, although I consider alpha as 'peek for new features', and only beta as 'let us test and report bugs'. I mean, we do not need user feedbacks to find bugs at the alpha stage. I agree with Bo. Abdel.
Re: Time for 1.6 alpha?
As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. I have yet another feature in the pipe, but this could go in after alpha1. Tell us about it pretty please :-) he want to make us a bit surprised by merging the working xml stuff into the tree, but little bit shy before polishing last few corners, you know :D pavel
Re: Time for 1.6 alpha?
he want to make us a bit surprised by merging the working xml stuff into the tree, but little bit shy before polishing last few corners, you know :D XML? I have not heard of this word for a while. :-) Bo
Re: Time for 1.6 alpha?
On Wednesday 12 March 2008 14:13:49 Stefan Schimanski wrote: Citing our webpage: A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience. 24/02/08 Is there any big must-have feature which we should wait for? Otherwise I would propose to make it in the next days, maybe the weekend. I think the current version does feel quite ok for an alpha release. Last time I have proposed this all hell got loose. We had several code refactorization in the last couple of weeks. :-) Now that things are beginning to get calmer I think that we are again on track to release an alpha version and to set the time table to a beta release. Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? With this time estimate I would like to have a proposed date set to beta before releasing the alpha. What do you think? Stefan -- José Abílio
Re: Time for 1.6 alpha?
he want to make us a bit surprised by merging the working xml stuff into the tree, but little bit shy before polishing last few corners, you know Now that you found out, I will drop my proposal ;-) i hope this trick will save us from xml hell in 1.7 series too :) pave
Re: Time for 1.6 alpha?
José Matos wrote: Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? It is basically complete and already works. The feature is a dialog for InsetSpace similar to our VSpace dialog (bug 2078), which also merges HFill into InsetSpace (thus lets you switch between the diverse spaces and hfill). The boni are: support for \hspace and \hspace* (bug 2075), \dotfill and \hrulefill. Furthermore, it fixes bug 4555 (hfill drawing). The remaining problems are: one specific lyx2lyx reversion problem and some metrics problems (all non-fill spaces are drawn in the same width). I think these are trivial, I just need some time. I'll try to finish it at the weekend. Jürgen
Re: Time for 1.6 alpha?
Pavel Sanda wrote: he want to make us a bit surprised by merging the working xml stuff into the tree, but little bit shy before polishing last few corners, you know Now that you found out, I will drop my proposal ;-) Jürgen
Re: Time for 1.6 alpha?
On Wednesday 12 March 2008 17:46:13 Juergen Spitzmueller wrote: The remaining problems are: one specific lyx2lyx reversion problem and some metrics problems (all non-fill spaces are drawn in the same width). I think these are trivial, I just need some time. I'll try to finish it at the weekend. Take your time. :-) I would like to have your feature in before beta. OTHO if it is ready for alpha I will not complain. :-) Jürgen -- José Abílio
Re: Time for 1.6 alpha?
José Matos wrote: On Wednesday 12 March 2008 14:13:49 Stefan Schimanski wrote: Citing our webpage: A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience. 24/02/08 Is there any big must-have feature which we should wait for? Otherwise I would propose to make it in the next days, maybe the weekend. I think the current version does feel quite ok for an alpha release. Last time I have proposed this all hell got loose. We had several code refactorization in the last couple of weeks. :-) Now that things are beginning to get calmer I think that we are again on track to release an alpha version and to set the time table to a beta release. Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? No feature here. And I promise to stop refactoring. There's just one fairly minor thing left to do, and I'm talking with Abdel now about how to do it. With this time estimate I would like to have a proposed date set to beta before releasing the alpha. What do you think? All of this sounds good to me. rh
Bo, look here please (was Re: Time for 1.6 alpha?)
Bennett Helm wrote:
On Mar 12, 2008, at 10:30 AM, Bo Peng wrote:
A first alpha version of LyX 1.6.0 will be released later this week
for those who like the bleeding edge experience. 24/02/08
Is there any big must-have feature which we should wait for?
As far as I know, embedding was the only lagging feature, and it is
ready for alpha testing now.
There are, I think, a couple of recent bugs that should be addressed
first (or am I the only one experiencing these?).
1. Loading open files from last session does not work.
2. Every time I open a file, save it, and open it again, it opens as
changed, so that if I immediately close it it asks if I want to save.
This one is caused by the Embedded stuff by Bo:
lyx.exe!lyx::Buffer::markDirty() Line 1626 C++
lyx.exe!lyx::EmbeddedFileList::enable(bool flag=false, lyx::Buffer
buffer={...}, bool updateFile=false) Line 409 C++
lyx.exe!lyx::Buffer::readDocument(lyx::Lexer lex={...}) Line 583 +
0x3b bytes C++
lyx.exe!lyx::Buffer::readFile(lyx::Lexer lex={...}, const
lyx::support::FileName filename={...}, bool fromstring=false) Line
836 + 0xc bytes C++
lyx.exe!lyx::Buffer::readFile(const lyx::support::FileName
filename={...}) Line 711 + 0x12 bytes C++
lyx.exe!lyx::Buffer::readFile(lyx::Lexer lex={...}, const
lyx::support::FileName filename={...}, bool fromstring=false) Line
829 + 0xf bytes C++
lyx.exe!lyx::Buffer::readFile(const lyx::support::FileName
filename={...}) Line 711 + 0x12 bytes C++
lyx.exe!lyx::Buffer::readFileHelper(const lyx::support::FileName
s={...}) Line 2552 + 0xc bytes C++
lyx.exe!lyx::Buffer::loadLyXFile(const lyx::support::FileName
s={...}) Line 2559 + 0xc bytes C++
lyx.exe!lyx::checkAndLoadLyXFile(const lyx::support::FileName
filename={...}) Line 92 + 0xf bytes C++
lyx.exe!lyx::frontend::GuiView::loadDocument(const
lyx::support::FileName filename={...}, bool tolastfiles=false) Line
1104 + 0x9 bytes C++
lyx.exe!lyx::LyXFunc::dispatch(const lyx::FuncRequest cmd={...})
Line 1062 + 0x1c bytes C++
lyx.exe!lyx::dispatch(const lyx::FuncRequest action={...}) Line
1344 C++
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
2. Every time I open a file, save it, and open it again, it opens as changed, so that if I immediately close it it asks if I want to save. This one is caused by the Embedded stuff by Bo: Will fix it soon. Bo
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
Bo Peng wrote: 2. Every time I open a file, save it, and open it again, it opens as changed, so that if I immediately close it it asks if I want to save. This one is caused by the Embedded stuff by Bo: Will fix it soon. Thanks. There is also the bug that any included file is marked as (embedded) in the InsetInclude label, independently of the embedded status. Abdel.
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
This one is caused by the Embedded stuff by Bo: Will fix it soon. Fixed. There is also the bug that any included file is marked as (embedded) in the InsetInclude label, independently of the embedded status. I do not see this here. Bo
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
1. Loading open files from last session does not work. Fixed. Bo
Re: Time for 1.6 alpha?
Citing our webpage: "A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience." 24/02/08 Is there any big must-have feature which we should wait for? Otherwise I would propose to make it in the next days, maybe the weekend. I think the current version does feel quite ok for an alpha release. Stefan Am 21.02.2008 um 13:59 schrieb Abdelrazak Younes: José Matos wrote: On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote: Hm, are you sure about that? I agree with Jürgen, and I agree with Abdel (note that _probably_). :-) There is no need to be so specific about the number of expected releases. That will free us to release when deemed necessary without artificial constraints. OK so what about this: We are pleased to announce the release of LyX 1.5.4. This is a maintenance release that further improves the stability and the performance and still manages to bring some new features. This is probably going to another one or two 1.5.x release before LyX 1.6.0, which will be made available as a first alpha version later this week. Before the release of the final 1.6.0, a least one 1.5.x version that is able to read the 1.6 format will be released.
Re: Time for 1.6 alpha?
>"A first alpha version of LyX 1.6.0 will be released later this week > for those who like the bleeding edge experience." 24/02/08 > > Is there any big must-have feature which we should wait for? As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. Bo
Re: Time for 1.6 alpha?
Bo Peng wrote: > As far as I know, embedding was the only lagging feature, and it is > ready for alpha testing now. I have yet another feature in the pipe, but this could go in after alpha1. Jürgen
Re: Time for 1.6 alpha?
On Mar 12, 2008, at 10:30 AM, Bo Peng wrote: "A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience." 24/02/08 Is there any big must-have feature which we should wait for? As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. There are, I think, a couple of recent bugs that should be addressed first (or am I the only one experiencing these?). 1. Loading open files from last session does not work. 2. Every time I open a file, save it, and open it again, it opens as changed, so that if I immediately close it it asks if I want to save. I'd still like to have window behavior changed ... at least on Mac. Now that multiple windows is working so well, I'd like to see the default behavior be to open new documents in their own window. This could be done with changing some keybindings, but for it to work well, we'd need to do two things: (a) close the LyX window when there is no document open -- so that we never have a window with just the LyX banner; and (b) allow LyX to remain running when all windows are closed. Of course I say "we'd" need to do these when I'm not in a position to do it. But I'd at least like to see if this is relatively simple (even if only on Mac) and whether others might find it worth taking up the cause. Bennett
Re: Time for 1.6 alpha?
> There are, I think, a couple of recent bugs that should be addressed > first (or am I the only one experiencing these?). My understanding is that alpha one means 1. all 1.6.x features are more or less ready 2. a loss feature freeze, basically no new feature is allowed. 3. let us start fixing bugs like what Bennett mentioned. Of course Jose has the authority to define alpha one, and order the release of it. Cheers, Bo
Re: Time for 1.6 alpha?
> My understanding is that alpha one means > > 1. all 1.6.x features are more or less ready > 2. a loss feature freeze, basically no new feature is allowed. > 3. let us start fixing bugs like what Bennett mentioned. > > Of course Jose has the authority to define alpha one, and order the > release of it. http://permalink.gmane.org/gmane.editors.lyx.devel/81717 p
Re: Time for 1.6 alpha?
> http://permalink.gmane.org/gmane.editors.lyx.devel/81717 So my understanding was more or less correct, and we are ready for alpha one. :-) Bo
Re: Time for 1.6 alpha?
On Mar 12, 2008, at 11:32 AM, Bo Peng wrote: There are, I think, a couple of recent bugs that should be addressed first (or am I the only one experiencing these?). My understanding is that alpha one means 1. all 1.6.x features are more or less ready 2. a loss feature freeze, basically no new feature is allowed. 3. let us start fixing bugs like what Bennett mentioned. But the point of an alpha release isn't simply to impose a feature freeze on developers, as this suggests; it's to get feedback from users. If the bugs are obvious and annoying, it will look like it wasn't really ready to be released even as an alpha and I suspect that we'd get both multiple reports of these bugs and fewer people interested in using the alpha enough to discover more important bugs. But that's just a hunch Bennett
Re: Time for 1.6 alpha?
> But the point of an alpha release isn't simply to impose a feature > freeze on developers, as this suggests; it's to get feedback from > users. I see your point, although I consider alpha as 'peek for new features', and only beta as 'let us test and report bugs'. I mean, we do not need user feedbacks to find bugs at the alpha stage. Bo
Re: Time for 1.6 alpha?
Juergen Spitzmueller wrote: Bo Peng wrote: As far as I know, embedding was the only lagging feature, and it is ready for alpha testing now. I have yet another feature in the pipe, but this could go in after alpha1. Tell us about it pretty please :-) Abdel.
Re: Time for 1.6 alpha?
Bo Peng wrote: But the point of an alpha release isn't simply to impose a feature freeze on developers, as this suggests; it's to get feedback from users. I see your point, although I consider alpha as 'peek for new features', and only beta as 'let us test and report bugs'. I mean, we do not need user feedbacks to find bugs at the alpha stage. I agree with Bo. Abdel.
Re: Time for 1.6 alpha?
>>> As far as I know, embedding was the only lagging feature, and it is >>> ready for alpha testing now. >> I have yet another feature in the pipe, but this could go in after alpha1. > > Tell us about it pretty please :-) he want to make us a bit surprised by merging the working xml stuff into the tree, but little bit shy before polishing last few corners, you know :D pavel
Re: Time for 1.6 alpha?
> he want to make us a bit surprised by merging the working xml stuff into the > tree, but little bit shy before polishing last few corners, you know :D XML? I have not heard of this word for a while. :-) Bo
Re: Time for 1.6 alpha?
On Wednesday 12 March 2008 14:13:49 Stefan Schimanski wrote: > Citing our webpage: > >"A first alpha version of LyX 1.6.0 will be released later this week > for those who like the bleeding edge experience." 24/02/08 > > Is there any big must-have feature which we should wait for? Otherwise > I would propose to make it in the next days, maybe the weekend. I > think the current version does feel quite ok for an alpha release. Last time I have proposed this all hell got loose. We had several code refactorization in the last couple of weeks. :-) Now that things are beginning to get calmer I think that we are again on track to release an alpha version and to set the time table to a beta release. Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? With this time estimate I would like to have a proposed date set to beta before releasing the alpha. What do you think? > Stefan -- José Abílio
Re: Time for 1.6 alpha?
> > he want to make us a bit surprised by merging the working xml stuff into > > the tree, but little bit shy before polishing last few corners, you know > > Now that you found out, I will drop my proposal ;-) i hope this trick will save us from xml hell in 1.7 series too :) pave
Re: Time for 1.6 alpha?
José Matos wrote: > Other than Juergen who has another feature waiting in the backburner? How > much time do you need to put the feature in? It is basically complete and already works. The feature is a dialog for InsetSpace similar to our VSpace dialog (bug 2078), which also merges HFill into InsetSpace (thus lets you switch between the diverse spaces and hfill). The boni are: support for \hspace and \hspace* (bug 2075), \dotfill and \hrulefill. Furthermore, it fixes bug 4555 (hfill drawing). The remaining problems are: one specific lyx2lyx reversion problem and some metrics problems (all non-fill spaces are drawn in the same width). I think these are trivial, I just need some time. I'll try to finish it at the weekend. Jürgen
Re: Time for 1.6 alpha?
Pavel Sanda wrote: > he want to make us a bit surprised by merging the working xml stuff into > the tree, but little bit shy before polishing last few corners, you know Now that you found out, I will drop my proposal ;-) Jürgen
Re: Time for 1.6 alpha?
On Wednesday 12 March 2008 17:46:13 Juergen Spitzmueller wrote: > The remaining problems are: one specific lyx2lyx reversion problem and some > metrics problems (all non-fill spaces are drawn in the same width). I think > these are trivial, I just need some time. I'll try to finish it at the > weekend. Take your time. :-) I would like to have your feature in before beta. OTHO if it is ready for alpha I will not complain. :-) > Jürgen -- José Abílio
Re: Time for 1.6 alpha?
José Matos wrote: On Wednesday 12 March 2008 14:13:49 Stefan Schimanski wrote: Citing our webpage: "A first alpha version of LyX 1.6.0 will be released later this week for those who like the bleeding edge experience." 24/02/08 Is there any big must-have feature which we should wait for? Otherwise I would propose to make it in the next days, maybe the weekend. I think the current version does feel quite ok for an alpha release. Last time I have proposed this all hell got loose. We had several code refactorization in the last couple of weeks. :-) Now that things are beginning to get calmer I think that we are again on track to release an alpha version and to set the time table to a beta release. Other than Juergen who has another feature waiting in the backburner? How much time do you need to put the feature in? No feature here. And I promise to stop refactoring. There's just one fairly minor thing left to do, and I'm talking with Abdel now about how to do it. With this time estimate I would like to have a proposed date set to beta before releasing the alpha. What do you think? All of this sounds good to me. rh
Bo, look here please (was Re: Time for 1.6 alpha?)
Bennett Helm wrote:
On Mar 12, 2008, at 10:30 AM, Bo Peng wrote:
"A first alpha version of LyX 1.6.0 will be released later this week
for those who like the bleeding edge experience." 24/02/08
Is there any big must-have feature which we should wait for?
As far as I know, embedding was the only lagging feature, and it is
ready for alpha testing now.
There are, I think, a couple of recent bugs that should be addressed
first (or am I the only one experiencing these?).
1. Loading open files from last session does not work.
2. Every time I open a file, save it, and open it again, it opens as
changed, so that if I immediately close it it asks if I want to save.
This one is caused by the Embedded stuff by Bo:
lyx.exe!lyx::Buffer::markDirty() Line 1626 C++
lyx.exe!lyx::EmbeddedFileList::enable(bool flag=false, lyx::Buffer &
buffer={...}, bool updateFile=false) Line 409 C++
lyx.exe!lyx::Buffer::readDocument(lyx::Lexer & lex={...}) Line 583 +
0x3b bytes C++
lyx.exe!lyx::Buffer::readFile(lyx::Lexer & lex={...}, const
lyx::support::FileName & filename={...}, bool fromstring=false) Line
836 + 0xc bytes C++
lyx.exe!lyx::Buffer::readFile(const lyx::support::FileName &
filename={...}) Line 711 + 0x12 bytes C++
lyx.exe!lyx::Buffer::readFile(lyx::Lexer & lex={...}, const
lyx::support::FileName & filename={...}, bool fromstring=false) Line
829 + 0xf bytes C++
lyx.exe!lyx::Buffer::readFile(const lyx::support::FileName &
filename={...}) Line 711 + 0x12 bytes C++
lyx.exe!lyx::Buffer::readFileHelper(const lyx::support::FileName &
s={...}) Line 2552 + 0xc bytes C++
lyx.exe!lyx::Buffer::loadLyXFile(const lyx::support::FileName &
s={...}) Line 2559 + 0xc bytes C++
lyx.exe!lyx::checkAndLoadLyXFile(const lyx::support::FileName &
filename={...}) Line 92 + 0xf bytes C++
lyx.exe!lyx::frontend::GuiView::loadDocument(const
lyx::support::FileName & filename={...}, bool tolastfiles=false) Line
1104 + 0x9 bytes C++
lyx.exe!lyx::LyXFunc::dispatch(const lyx::FuncRequest & cmd={...})
Line 1062 + 0x1c bytes C++
lyx.exe!lyx::dispatch(const lyx::FuncRequest & action={...}) Line
1344 C++
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
> > 2. Every time I open a file, save it, and open it again, it opens as > > changed, so that if I immediately close it it asks if I want to save. > > This one is caused by the Embedded stuff by Bo: Will fix it soon. Bo
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
Bo Peng wrote: > 2. Every time I open a file, save it, and open it again, it opens as > changed, so that if I immediately close it it asks if I want to save. This one is caused by the Embedded stuff by Bo: Will fix it soon. Thanks. There is also the bug that any included file is marked as (embedded) in the InsetInclude label, independently of the embedded status. Abdel.
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
> >> This one is caused by the Embedded stuff by Bo: > > > > Will fix it soon. Fixed. > There is also the bug that any included file is marked as (embedded) in > the InsetInclude label, independently of the embedded status. I do not see this here. Bo
Re: Bo, look here please (was Re: Time for 1.6 alpha?)
> > 1. Loading open files from last session does not work. Fixed. Bo
Time for 1.6 alpha?
1.6 development introduced 26 bugs (until further bugs are added of course): http://tinyurl.com/2ppsjo I use trunk for a few months already and I reckon that it is more than ready for an alpha release. Jose? Abdel.
Re: Time for 1.6 alpha?
On Thursday 21 February 2008 08:13:25 Abdelrazak Younes wrote: 1.6 development introduced 26 bugs (until further bugs are added of course): http://tinyurl.com/2ppsjo I use trunk for a few months already and I reckon that it is more than ready for an alpha release. Jose? I agree. Not only I agree as I have been working to make sure that it compiles and works with new platforms (gcc 4.3). In order not to disturb the normal flow I propose to set a release date of one week after 1.5.4. The rationale is both technical and PR (public relations) related. Abdel. -- José Abílio
Re: Time for 1.6 alpha?
José Matos wrote: In order not to disturb the normal flow I propose to set a release date of one week after 1.5.4. The rationale is both technical and PR (public relations) related. So maybe we could say something about it in the 1.5.4 announcement? Abdel.
Re: Time for 1.6 alpha?
On Thursday 21 February 2008 10:51:59 Abdelrazak Younes wrote: We have a problem with Qt4.4 snapshot apparently (bug 4568) but do we care? I tend to think not. I suggest that we don't care for alpha. For beta OTHO... Abdel. -- José Abílio
Re: Time for 1.6 alpha?
José Matos wrote: On Thursday 21 February 2008 08:13:25 Abdelrazak Younes wrote: 1.6 development introduced 26 bugs (until further bugs are added of course): http://tinyurl.com/2ppsjo I use trunk for a few months already and I reckon that it is more than ready for an alpha release. Jose? I agree. Not only I agree as I have been working to make sure that it compiles and works with new platforms (gcc 4.3). We have a problem with Qt4.4 snapshot apparently (bug 4568) but do we care? I tend to think not. In order not to disturb the normal flow I propose to set a release date of one week after 1.5.4. The rationale is both technical and PR (public relations) related. That would be excellent. Abdel.
Re: Time for 1.6 alpha?
Juergen Spitzmueller wrote: Abdelrazak Younes wrote: So maybe we could say something about it in the 1.5.4 announcement? write something and I'll include it. We are pleased to announce the release of LyX 1.5.4. This is a maintenance release that further improves the stability and the performance and still manages to bring some new features. This is probably going to be the penultimate 1.5.x release before LyX 1.6.0, which will be made available as a first alpha version later this week. Before the release of the final 1.6.0, a least one 1.5.5 version that is able to read the 1.6 format will be released.
Re: Time for 1.6 alpha?
Abdelrazak Younes wrote: So maybe we could say something about it in the 1.5.4 announcement? write something and I'll include it. Jürgen
Re: Time for 1.6 alpha?
Abdelrazak Younes wrote: This is probably going to be the penultimate 1.5.x release before LyX 1.6.0 Hm, are you sure about that? Jürgen
Re: Time for 1.6 alpha?
Juergen Spitzmueller wrote: Abdelrazak Younes wrote: This is probably going to be the penultimate 1.5.x release before LyX 1.6.0 Hm, are you sure about that? No, hence the 'probably' :-) Abdel.
Re: Time for 1.6 alpha?
On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote: Hm, are you sure about that? I agree with Jürgen, and I agree with Abdel (note that _probably_). :-) There is no need to be so specific about the number of expected releases. That will free us to release when deemed necessary without artificial constraints. Jürgen -- José Abílio
Re: Time for 1.6 alpha?
José Matos wrote: On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote: Hm, are you sure about that? I agree with Jürgen, and I agree with Abdel (note that _probably_). :-) There is no need to be so specific about the number of expected releases. That will free us to release when deemed necessary without artificial constraints. OK so what about this: We are pleased to announce the release of LyX 1.5.4. This is a maintenance release that further improves the stability and the performance and still manages to bring some new features. This is probably going to another one or two 1.5.x release before LyX 1.6.0, which will be made available as a first alpha version later this week. Before the release of the final 1.6.0, a least one 1.5.x version that is able to read the 1.6 format will be released.
Re: Time for 1.6 alpha?
José Matos wrote: Hm, are you sure about that? I agree with Jürgen, and I agree with Abdel (note that _probably_). Yes, but this will raise expectations ;-) Anyway, I'll put in something. Jürgen
Re: Time for 1.6 alpha?
Abdelrazak Younes wrote: José Matos wrote: On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote: Hm, are you sure about that? I agree with Jürgen, and I agree with Abdel (note that _probably_). :-) There is no need to be so specific about the number of expected releases. That will free us to release when deemed necessary without artificial constraints. OK so what about this: We are pleased to announce the release of LyX 1.5.4. This is a maintenance release that further improves the stability and the performance and still manages to bring some new features. This is probably going to another one or two 1.5.x release before LyX 1.6.0, Hum... There is probably going to be another one or two 1.5.x release before LyX 1.6.0, ...
Re: Time for 1.6 alpha?
José Matos wrote: On Thursday 21 February 2008 12:35:24 Juergen Spitzmueller wrote: Hm, are you sure about that? I agree with Jürgen, and I agree with Abdel (note that _probably_). :-) There is no need to be so specific about the number of expected releases. That will free us to release when deemed necessary without artificial constraints. Good for me. To be honest, I just copied and paste the 1.4.4 announcement :-) Abdel.
Re: Time for 1.6 alpha?
On Thu, 21 Feb 2008, Abdelrazak Younes wrote: How about this as the second paragraph, might be to complicated though... In a week or two, the developers plan to release a first alpha version of LyX 1.6.0. This will be the first release in the coming 1.6-series, which as usual include changes to the LyX file format. Initially the alpha version will not be backwards compatible with LyX 1.5.x, but this issue will be handled before the final release of LyX 1.6.0 through one or more additional releases in the 1.5-series, which will be able to read the new file format. /Christian PS. The old paragraph This is probably going to another one or two 1.5.x release before LyX 1.6.0, which will be made available as a first alpha version later this week. Before the release of the final 1.6.0, a least one 1.5.x version that is able to read the 1.6 format will be released. -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Time for 1.6 alpha?
[EMAIL PROTECTED] wrote: On Thu, 21 Feb 2008, Abdelrazak Younes wrote: How about this as the second paragraph, might be to complicated though... In a week or two, the developers plan to release a first alpha version of LyX 1.6.0. This will be the first release in the coming 1.6-series, which as usual include changes to the LyX file format. Initially the alpha version will not be backwards compatible with LyX 1.5.x, This is misleading IMHO, the alpha will of course be backward compatible with 1.5.x. It's 1.5.x who isn't _updward_ compatible yet. Abdel.
Time for 1.6 alpha?
1.6 development introduced 26 bugs (until further bugs are added of course): http://tinyurl.com/2ppsjo I use trunk for a few months already and I reckon that it is more than ready for an alpha release. Jose? Abdel.
Re: Time for 1.6 alpha?
On Thursday 21 February 2008 08:13:25 Abdelrazak Younes wrote: > 1.6 development introduced 26 bugs (until further bugs are added of > course): > > http://tinyurl.com/2ppsjo > > I use trunk for a few months already and I reckon that it is more than > ready for an alpha release. Jose? I agree. Not only I agree as I have been working to make sure that it compiles and works with new platforms (gcc 4.3). In order not to disturb the normal flow I propose to set a release date of one week after 1.5.4. The rationale is both technical and PR (public relations) related. > Abdel. -- José Abílio
Re: Time for 1.6 alpha?
José Matos wrote: In order not to disturb the normal flow I propose to set a release date of one week after 1.5.4. The rationale is both technical and PR (public relations) related. So maybe we could say something about it in the 1.5.4 announcement? Abdel.
Re: Time for 1.6 alpha?
On Thursday 21 February 2008 10:51:59 Abdelrazak Younes wrote: > We have a problem with Qt4.4 snapshot apparently (bug 4568) but do we > care? I tend to think not. I suggest that we don't care for alpha. For beta OTHO... > Abdel. -- José Abílio
Re: Time for 1.6 alpha?
José Matos wrote: On Thursday 21 February 2008 08:13:25 Abdelrazak Younes wrote: 1.6 development introduced 26 bugs (until further bugs are added of course): http://tinyurl.com/2ppsjo I use trunk for a few months already and I reckon that it is more than ready for an alpha release. Jose? I agree. Not only I agree as I have been working to make sure that it compiles and works with new platforms (gcc 4.3). We have a problem with Qt4.4 snapshot apparently (bug 4568) but do we care? I tend to think not. In order not to disturb the normal flow I propose to set a release date of one week after 1.5.4. The rationale is both technical and PR (public relations) related. That would be excellent. Abdel.
Re: Time for 1.6 alpha?
Juergen Spitzmueller wrote: Abdelrazak Younes wrote: So maybe we could say something about it in the 1.5.4 announcement? write something and I'll include it. We are pleased to announce the release of LyX 1.5.4. This is a maintenance release that further improves the stability and the performance and still manages to bring some new features. This is probably going to be the penultimate 1.5.x release before LyX 1.6.0, which will be made available as a first alpha version later this week. Before the release of the final 1.6.0, a least one 1.5.5 version that is able to read the 1.6 format will be released.
