Am Samstag 02 Mai 2009 schrieb Alex Fernandez:
> Hi again,
>
> On Sat, May 2, 2009 at 9:22 PM, Kornel Benko wrote:
> > I meant something like: I (elyxer) understand lyx-formats up to 329.
> > Our actual format in trunk is 354, while lyx 1.6.3 writes format 345.
> >
> > So it _is_ important to know
I use 1.6.3svn (id UI menu) in Ubuntu 8.10
The preference settings and document setting have been set in Indonesian
language.
I was going to try using Indonesian Spell Checker
but it did not work and a message appeared
"Error: The file "/usr/lib/aspell/bahasa" can not be opened for
reading."
I c
On Sun, May 3, 2009 at 12:32 AM, rgheck wrote:
>> This would become even easier if LyX would install lyx2lyx as a normal
>> Python package.
>
> It might be worth requesting this explicitly as an enhancement. Surely it
> can't be that hard.
Done:
http://www.lyx.org/trac/ticket/5934
Alex
cmira...@kde-france.org wrote:
rgheck wrote:
There are more and less complicated ways to do this. You could have a
new format, like DocBook, but I think what's really wanted is something
that would work more like plaintext, so that you can output any document
as HTML. So we'd have a set of a
Alex Fernandez wrote:
Hi Guenter,
On Sat, May 2, 2009 at 11:10 PM, Guenter Milde wrote:
It should be mentioned that (AFAIK), lyx2lyx works (and can be
installed) independent of LyX. At least I could successfully use a
lyx2lyx from trunk to import "1.6" documents with 1.5.4.
Hmmm, th
Guenter Milde wrote:
This would become even easier if LyX would install lyx2lyx as a normal
Python package.
It might be worth requesting this explicitly as an enhancement. Surely
it can't be that hard.
It should be mentioned that (AFAIK), lyx2lyx works (and can be
installed) independent o
Pavel Sanda wrote:
Richard Heck wrote:
Set up formats for each one.
hehehe i see it will be bit hard to get some agreement here since thats
complentary draft to Juergens... :)
Yes, I know. But I think J"urgen meant more "why do this one special?"
whereas I mean: We should do them
rgheck wrote:
> There are more and less complicated ways to do this. You could have a
> new format, like DocBook, but I think what's really wanted is something
> that would work more like plaintext, so that you can output any document
> as HTML. So we'd have a set of ashtml() routines in the inset
Hi Guenter,
On Sat, May 2, 2009 at 11:10 PM, Guenter Milde wrote:
> It should be mentioned that (AFAIK), lyx2lyx works (and can be
> installed) independent of LyX. At least I could successfully use a
> lyx2lyx from trunk to import "1.6" documents with 1.5.4.
Hmmm, that is interesting. It certain
On 2009-05-02, rgheck wrote:
> Kornel Benko wrote:
>> Am Samstag 02 Mai 2009 schrieb rgheck:
>>> Jürgen Spitzmüller wrote:
> That said, solving this problem is basically trivial. eLyXer need do
> nothing more than call lyx2lyx on the input file with the right
> arguments to get the format it wan
Hi again,
On Sat, May 2, 2009 at 9:22 PM, Kornel Benko wrote:
> I meant something like: I (elyxer) understand lyx-formats up to 329.
> Our actual format in trunk is 354, while lyx 1.6.3 writes format 345.
>
> So it _is_ important to know, what elyxer supports.
Seen this way it is. What I meant w
Abdelrazak Younes wrote:
>> No one raised size as an issue. Maintainability, comprehensiveness, etc,
>> were the issues.
>
> As long as LyX doesn't depend on eLyXer I don't see any problem. We also
> have scons and cmake in that situation don't we?
not that we should aim at maintainig three diff
Richard Heck wrote:
> Set up formats for each one.
hehehe i see it will be bit hard to get some agreement here since thats
complentary draft to Juergens... :)
pavel
Pavel Sanda wrote:
Richard Heck wrote:
I'm not proposing we list each one separately, but find some way to detect
them all and then configure things appropriately.
i dont understand this proposal. we detect them all. then what?
Set up formats for each one. So you'd have html1, whic
On 02/05/2009 01:30, Alex Fernandez wrote:
First, this discussion (and the many threads around it) are causing
unnecessary division among LyX developers.
Don't worry about that. LyX developers have a pretty thick skin :-)
People are suffering
unnecessary pain because of this. And this becau
Pavel Sanda wrote:
Richard Heck wrote:
Kornel Benko wrote:
Am Samstag 02 Mai 2009 schrieb Edwin Leuven:
richard wrote:
Comments, as said, welcome.
why not rather work on XML?
I am also all for it. But I fear, this is not near fu
On 01/05/2009 21:06, rgheck wrote:
Abdelrazak Younes wrote:
I vote for full inclusion for three reasons:
1) the social aspect: Alex looks like a nice and proactive guy. He
_is_ a nice recrue, no doubt about that. We are not being very
inviting with all this fuss about inclusion or not.
How
Richard Heck wrote:
> I'm not proposing we list each one separately, but find some way to detect
> them all and then configure things appropriately.
i dont understand this proposal. we detect them all. then what?
pavel
Uwe Stöhr wrote:
> > nothing like that. in our sources there are many parts for newer
> > versions of qt then the version we promised to support. feel free
> > to remove it from wiki if you are nervous about it.
>
> I'm not nervous but our users will complain, at least Windows users who
> then thi
Alex Fernandez wrote:
As to the relicensing, that is fine with me. Just let me know when you need it.
Just do it at your leisure, though maybe by the end of the month would
be good. It won't become an issue for a little while still.
rh
Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
As said, I do not understand why eLyXer should be separated from that
paradigma.
i tried to explain - difference in technology and target too (mainly based
what can (not) be read from latex output).
Yes, bu
> nothing like that. in our sources there are many parts for newer
> versions of qt then the version we promised to support. feel free
> to remove it from wiki if you are nervous about it.
I'm not nervous but our users will complain, at least Windows users who then think they need to
reinstall L
Am Samstag 02 Mai 2009 schrieb Alex Fernandez:
> Hi Kornel,
>
> On Sat, May 2, 2009 at 4:52 PM, Kornel Benko wrote:
> > Yes, we should. It is yet not possible for autoconfigure to determine
> > which format elyxer supports.
> >
> > Maybe some elyxer-parameter, like --print-format. Alex?
>
> No nee
Waluyo Adi Siswanto schrieb:
Yes .. That's why I am suggesting to replace what is incorrectly written
in the Tutorial, with the correct one, i.e. Edit > Rows&Columns
Stupid me. I have corrected this now.
thanks and regards
Uwe
Uwe Stöhr wrote:
> > That's why it's only christmas for Qt 4.5.
>
>Therefore we are forced to use Qt 4.5 for branch when building the
> Win and Mac installers.
nothing like that. in our sources there are many parts for newer
versions of qt then the version we promised to support. feel free
to rem
> That's why it's only christmas for Qt 4.5.
I know but that's the problem. It is announced as new feature for LyX 1.6.3. Therefore we are forced
to use Qt 4.5 for branch when building the Win and Mac installers. But I'm not sure if this is safe
since Qt 4.5.0 introduced a lot of regressions an
Richard Heck wrote:
> Kornel Benko wrote:
>> Am Samstag 02 Mai 2009 schrieb Edwin Leuven:
>>
>>> richard wrote:
>>>
Comments, as said, welcome.
>>> why not rather work on XML?
>>>
>>
>> I am also all for it. But I fear, this is not near future. Therefore it is
>> bett
Hi Kornel,
On Sat, May 2, 2009 at 4:52 PM, Kornel Benko wrote:
> Yes, we should. It is yet not possible for autoconfigure to determine which
> format elyxer supports.
>
> Maybe some elyxer-parameter, like --print-format. Alex?
No need to. eLyXer, being in the more-or-less-unique position of
cons
Hi Richard,
On Sat, May 2, 2009 at 5:27 PM, rgheck wrote:
> And then, of course, there's the fact that you've already done so much of
> the hard work. My intention, if it's OK with you, is pretty much to borrow
> from what you've already done, at least as far as the format of the HTML
> output is
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > >As said, I do not understand why eLyXer should be separated from that
> > > paradigma.
> >
> > i tried to explain - difference in technology and target too (mainly based
> > what can (not) be read from latex output).
>
> Yes, but I'm not convince
Pavel Sanda wrote:
> >As said, I do not understand why eLyXer should be separated from that
> > paradigma.
>
> i tried to explain - difference in technology and target too (mainly based
> what can (not) be read from latex output).
Yes, but I'm not convinced by this at all. tex4ht is at least as fa
On Sat, May 02, 2009 at 06:35:11PM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > I also prefer that (because no disk access is performed if it is not
> > really necessary) and did not apply it for the previously stated reasons.
> > However, I think that if a problem shows up, it
On Sat, 2009-05-02 at 19:18 +0200, Uwe Stöhr wrote:
> Waluyo Adi Siswanto schrieb:
>
> > In 4.4.5 Matrices, Paragraph 3:
> >
> > I am suggesting:
> > Edit > Rows&Columns
> > to replace
> > Edit > Math > Rows&columns
>
> There is no menu Edit > Math > Rows&columns. Edit > Rows&Columns is correct
Waluyo Adi Siswanto schrieb:
In 4.4.5 Matrices, Paragraph 3:
I am suggesting:
Edit > Rows&Columns
to replace
Edit > Math > Rows&columns
There is no menu Edit > Math > Rows&columns. Edit > Rows&Columns is correct, this menu can be used
for matrices and tables as well.
regards Uwe
Jürgen Spitzmüller wrote:
> Uwe Stöhr wrote:
> > Thanks for changing this. But shouldn't we now give the html format the
> > name "HTML (tex4ht)" to tell the users what program they are using, like we
> > do for PDF?
>
> It's not necessarily tex4ht. It can also be latex2html or hevea.
yes, i use
Uwe Stöhr wrote:
> I just recompiled branch and still see there the old behavior: only one
> close button besides the tabs. I'm using Qt 4.4.2 for branch.
>
> In trunk, where I use Qt 4.5.1 it works as it should.
That's why it's only christmas for Qt 4.5.
Jürgen
Enrico Forestieri wrote:
> I also prefer that (because no disk access is performed if it is not
> really necessary) and did not apply it for the previously stated reasons.
> However, I think that if a problem shows up, it can be worked out.
> So I am going to revert my previous commit and apply Geo
Kornel Benko wrote:
Am Samstag 02 Mai 2009 schrieb Edwin Leuven:
richard wrote:
Comments, as said, welcome.
why not rather work on XML?
I am also all for it. But I fear, this is not near future. Therefore it is
better to create html output, readable by all colleagues not
Am Samstag 02 Mai 2009 schrieb rgheck:
> >
>
> Well, the other thing no-one mentioned, which does matter, is that we'd
> like the tools we distribute to work not just with the formats of the
> major releases but also with intermediate ones.
Well, ok...
> That said, solving this problem is basic
Am Samstag 02 Mai 2009 schrieb Edwin Leuven:
> richard wrote:
> > Comments, as said, welcome.
>
> why not rather work on XML?
I am also all for it. But I fear, this is not near future. Therefore it is
better to create html output, readable by all colleagues not having lyx :)
> edwin
Kor
richard wrote:
> Comments, as said, welcome.
why not rather work on XML?
edwin
> Anyway, you should remove the close button that reside in the far right of
> the tabbar.
>
> i can do that if you feel it better.
I just recompiled branch and still see there the old behavior: only one close button besides the
tabs. I'm using Qt 4.4.2 for branch.
In trunk, where I use Qt 4.5
On Sat, May 02, 2009 at 05:51:58PM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > > If you know/think/believe that the problem is only with Webdav, then it
> > > is not a real problem.
> >
> > So, Jürgen, what we shall do?
>
> As already announced. As long as Georg's patch does n
Enrico Forestieri wrote:
> > If you know/think/believe that the problem is only with Webdav, then it
> > is not a real problem.
>
> So, Jürgen, what we shall do?
As already announced. As long as Georg's patch does not show any problems, I'd
go for that.
Jürgen
On Sat, May 02, 2009 at 04:57:30PM +0200, Vincent van Ravesteijn wrote:
>
> >> It's the only way I could test the performance from here. I open a
> >> master document located at 'http://...' which includes child documents.
> >>
> >
> > Try the test files attached here:
> > http://thread.gman
Uwe Stöhr wrote:
> Thanks for changing this. But shouldn't we now give the html format the
> name "HTML (tex4ht)" to tell the users what program they are using, like we
> do for PDF?
It's not necessarily tex4ht. It can also be latex2html or hevea. As said, I do
not understand why eLyXer should be
Uwe Stöhr wrote:
> i understand the problem. my problem is - are you really sure running
> src/elyxer.py is the same as running ./elyxer?
No, both are different but Alex will re-add the file extension to the
latter and rename the one in src/ now.
> elyxhtml is not to be seen anywhere in the m
> i understand the problem. my problem is - are you really sure running
> src/elyxer.py is the same as running ./elyxer?
No, both are different but Alex will re-add the file extension to the latter and rename the one in
src/ now.
> elyxhtml is not to be seen anywhere in the menu, but as i said
Kornel Benko wrote:
Am Samstag 02 Mai 2009 schrieb rgheck:
Jürgen Spitzmüller wrote:
It's not LyX's task to deliver the correct format to eLyXer. This is
eLyXers duty.
+1.
Now I am outnumbered. But only partly convinced :)
Well, the other thing no-one mentioned, which
So I'm going to try to do this. Here's an outline for discussion before
I start. When I start, I don't know. Maybe bits and pieces soon.
There are more and less complicated ways to do this. You could have a
new format, like DocBook, but I think what's really wanted is something
that would wo
Am Samstag 02 Mai 2009 schrieb rgheck:
> Jürgen Spitzmüller wrote:
> > It's not LyX's task to deliver the correct format to eLyXer. This is
> > eLyXers duty.
>
> +1.
Now I am outnumbered. But only partly convinced :)
> rh
Kornel
signature.asc
Description: This is a digitally signed mes
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller:
> Kornel Benko wrote:
> > > Still, LyX's autoconfigure should work with any version of a program,
> > > if possible.
> >
> > Yes, we should. It is yet not possible for autoconfigure to determine
> > which format elyxer supports.
>
> Only eLyXer kno
rgheck wrote:
> Both are in my dictionaries. I think "indexes" will definitely be less
> confusing to non-native speakers, some of whom probably use LyX in
> English. So I'll agree with Bennett.
Well, if two philosophers agree ...
I'll change it (only the UI strings, though).
Jürgen
Alex Fernandez wrote:
Said in this way it may look a bit harsh. The reality is that, even
though it would be great, I don't think the project of producing
native HTML output is viable. Not in a "haha you will never catch me"
way, but rather in a "it will get _very_ boring before it is useful"
fas
Kornel Benko wrote:
> > Still, LyX's autoconfigure should work with any version of a program, if
> > possible.
>
> Yes, we should. It is yet not possible for autoconfigure to determine which
> format elyxer supports.
Only eLyXer knows. And it should issue lyx2lyx in order to get that specific
for
Pavel Sanda wrote:
Alex Fernandez wrote:
and only after
his exams were finished. Not a very solid promise, if I have to judge
by my own University years :P
i warn you, Richard is some day beyond _his_ exams :)
Yes, true.
For the linguistically inclined, this is actually a nice ex
Vincent van Ravesteijn wrote:
BH schreef:
On Sun, Apr 19, 2009 at 3:07 AM, Jürgen Spitzmüller
wrote:
Vincent van Ravesteijn wrote:
We have a "List of Indexes" in the ToC, but in the Document
Settings we
speak of "Indices".
Which one will it be ?
I'm no native speaker. I always
Pavel Sanda wrote:
Alex Fernandez wrote:
First, this discussion (and the many threads around it) are causing
unnecessary division among LyX developers. People are suffering
unnecessary pain because of this. And this because everyone is trying
..
If the LyX community still wants to i
Vincent van Ravesteijn wrote:
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
And what about the patch from Georg ? That patch sort of solved the
problem too. This patch was less intrusive and I already tested that.
If it was upto me, I would revert this commit and commit Georg's p
Jürgen Spitzmüller wrote:
It's not LyX's task to deliver the correct format to eLyXer. This is eLyXers
duty.
+1.
rh
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller:
> Kornel Benko wrote:
> > > > Well, this is certainly the case for many other alternative programs
> > > > as well.
> > >
> > > my feeling was that this is somewhat on the level of pdf/1/2/3 though.
>
> I'd rather see it on the level of latex2html/
It's the only way I could test the performance from here. I open a
master document located at 'http://...' which includes child documents.
Try the test files attached here:
http://thread.gmane.org/gmane.editors.lyx.devel/116276/focus=116277
I get very slow behavior with those, without inv
On Sat, May 02, 2009 at 04:39:17PM +0200, Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn wrote:
> > > If you think that Georg's patch is better, this is fine with me (I myself
> > > would have applied it, if it had been simple to give an answer to the
> > > problems it may have rised). So, rev
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller:
> Kornel Benko wrote:
> > I learned today, tha elyxer supports lyx1.6. It was not soo difficult to
> > change my preferences to reflect this upgrade.
> >
> > And we do not change the format too often for the public.
>
> Still, LyX's autoconfigure s
On Sat, May 02, 2009 at 09:14:43AM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > OK for branch?
>
> If you're confident it doesn't need more testing: fine with me.
> (this code does not interfere outside of DVI serach, right?)
I extensively tested it (not with webdav, sorry, bu
Kornel Benko wrote:
> > > Well, this is certainly the case for many other alternative programs as
> > > well.
> >
> > my feeling was that this is somewhat on the level of pdf/1/2/3 though.
I'd rather see it on the level of latex2html/tex4ht.
pdf1/2/3 involves specific file conversion handling and
Kornel Benko wrote:
> I learned today, tha elyxer supports lyx1.6. It was not soo difficult to
> change my preferences to reflect this upgrade.
>
> And we do not change the format too often for the public.
Still, LyX's autoconfigure should work with any version of a program, if
possible.
It's no
On Sat, May 02, 2009 at 04:17:37PM +0200, Vincent van Ravesteijn wrote:
>
> > I've never used webdav, but according to wikipedia there are serious
> > bugs with it. Maybe Qt uses some workaround for bypassing the bugs.
> > If I understand correctly, using webdav you can open a file using
> > a url
Vincent van Ravesteijn wrote:
> > If you think that Georg's patch is better, this is fine with me (I myself
> > would have applied it, if it had been simple to give an answer to the
> > problems it may have rised). So, revert this commit and apply that one.
> >
>
> I don't want to be the one maki
Am Samstag 02 Mai 2009 schrieb Jürgen Spitzmüller:
> Kornel Benko wrote:
> > There were no need for elyxer to be aware of lyx2lyx. I for one am using
> > it this way since some weeks.
>
> However, this would mean that the eLyXer format needed to be frozen.
I learned today, tha elyxer supports lyx1
Am Samstag 02 Mai 2009 schrieb Pavel Sanda:
> Jürgen Spitzmüller wrote:
> > Pavel Sanda wrote:
> > > it makes sense to have both export possibilities - the
> > > standard via-latex-tools preserves much better the math, structure with
> > > contents etc, on the other way lyxer has more attractive vi
On Sat, May 02, 2009 at 03:08:46PM +0200, Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn wrote:
> > I believe this was the patch.
>
> Looks less intrusive indeed.
>
> Enrico?
I am all for it, as I explained in the other email.
Have a look at this thread, where the stated concerns were raise
I've never used webdav, but according to wikipedia there are serious
bugs with it. Maybe Qt uses some workaround for bypassing the bugs.
If I understand correctly, using webdav you can open a file using
a url syntax such as http://..., which is not exactly the right
way for dealing with child do
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > it makes sense to have both export possibilities - the
> > standard via-latex-tools preserves much better the math, structure with
> > contents etc, on the other way lyxer has more attractive visual appearance.
> > so for different documents you wo
Enrico Forestieri wrote:
> > I do not understand this sentence.
>
> What I meant to say is that despite the speed I can type in, the
> characters appear immediately on screen.
I see.
Jürgen
Pavel Sanda wrote:
> it makes sense to have both export possibilities - the
> standard via-latex-tools preserves much better the math, structure with
> contents etc, on the other way lyxer has more attractive visual appearance.
> so for different documents you would use different output.
Well, thi
On Sat, May 02, 2009 at 09:38:38AM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
>
> > With this patch I am not able to type ahead, neither on Windows nor on
> > Solaris.
>
> I do not understand this sentence.
What I meant to say is that despite the speed I can type in, the
chara
On Sat, May 02, 2009 at 12:07:49PM +0200, Vincent van Ravesteijn wrote:
> There are serious problems with this commit.
>
> If I open a document (using webdav) that has a child document, I can't
> open the child document. Moreover, opening the child manually will give
> me a warning that it alre
Jürgen Spitzmüller wrote:
> * checkViewer should go to checkFormatsEntries method, not
> checkConvertersEntries().
but i wanted this to be function to be called only if checkProg('eLyXer
converter'... proceed. (it shouldn't be displayed when user have no
interest in lyxer). so the position is co
Pavel Sanda wrote:
> Juergen?
No objections.
Jürgen
Vincent van Ravesteijn wrote:
> I believe this was the patch.
Looks less intrusive indeed.
Enrico?
Jürgen
Pavel Sanda wrote:
> > * recognize eLyXer as a HTML converter (already done, AFAICS)
>
> do you agree to backport this into branch?
principally yes, but the change has some flaws:
* checkViewer should go to checkFormatsEntries method, not
checkConvertersEntries().
* the program call syntax ques
On Sat, May 2, 2009 at 3:59 AM, Jürgen Spitzmüller wrote:
> BH wrote:
>> Could someone please check and apply?
>
> I did that (minus the mac.bind part in the trunk patch).
Oops. That's what I get for checking only the branch patch. Sorry ...
and thanks.
Bennett
Jürgen Spitzmüller schreef:
Vincent van Ravesteijn wrote:
And what about the patch from Georg ? That patch sort of solved the
problem too. This patch was less intrusive and I already tested that.
If it was upto me, I would revert this commit and commit Georg's patch.
Do you have a poi
Vincent van Ravesteijn wrote:
> And what about the patch from Georg ? That patch sort of solved the
> problem too. This patch was less intrusive and I already tested that.
>
> If it was upto me, I would revert this commit and commit Georg's patch.
Do you have a pointer to this patch at hand?
Jürg
sa...@lyx.org wrote:
> Author: sanda
> Date: Sat May 2 14:43:42 2009
> New Revision: 29491
> URL: http://www.lyx.org/trac/changeset/29491
>
> Log:
> Use Qt native close button on tabbar.
> Fixes http://www.lyx.org/trac/ticket/3724
sa...@lyx.org wrote:
> Author: sanda
> Date: Sat May 2 14:43:45
Kornel Benko wrote:
> There were no need for elyxer to be aware of lyx2lyx. I for one am using it
> this way since some weeks.
However, this would mean that the eLyXer format needed to be frozen.
Jürgen
Vincent van Ravesteijn wrote:
> Anyway, you should remove the close button that reside in the far right of
> the tabbar.
i can do that if you feel it better.
pavel
Pavel Sanda schreef:
Vincent van Ravesteijn wrote:
Pavel Sanda schreef:
any comments before commit?
pavel
Do you have some accompanying info ?
screenshot is not enough ? :)
pavel
Well, you could have spend a few words..
Anyway, you should remove the close button t
Vincent van Ravesteijn wrote:
> Pavel Sanda schreef:
>> any comments before commit?
>> pavel
>>
> Do you have some accompanying info ?
screenshot is not enough ? :)
pavel
Am Samstag 02 Mai 2009 schrieb Pavel Sanda:
> Kornel Benko wrote:
> > > The problem is that I have to give it a file extension to make Python
> > > recognize it. When I do this also the problem I had with missing
> > > includes disappears.
> >
> > You mean, calling python is not sufficient?
>
> it
Pavel Sanda schreef:
any comments before commit?
pavel
Do you have some accompanying info ?
Vincent
any comments before commit?
pavel
diff --git a/src/frontends/qt4/GuiWorkArea.cpp
b/src/frontends/qt4/GuiWorkArea.cpp
index b0eb1e3..37c9db7 100644
--- a/src/frontends/qt4/GuiWorkArea.cpp
+++ b/src/frontends/qt4/GuiWorkArea.cpp
@@ -1334,6 +1334,10 @@ TabWorkArea::TabWorkArea(QWidget * parent)
Alex Fernandez wrote:
> and only after
> his exams were finished. Not a very solid promise, if I have to judge
> by my own University years :P
i warn you, Richard is some day beyond _his_ exams :)
pavel
Hi Richard,
On Sat, May 2, 2009 at 1:19 AM, rgheck wrote:
>> Have you considered that Alex might help you with your HTML project since
>> he knows HTML as well as you and might have more LyX-HTML experience due to
>> his eLyXer.
>>
> Yes. I suggested we should work together. He refused.
Said in
BH schreef:
On Sun, Apr 19, 2009 at 3:07 AM, Jürgen Spitzmüller wrote:
Vincent van Ravesteijn wrote:
We have a "List of Indexes" in the ToC, but in the Document Settings we
speak of "Indices".
Which one will it be ?
I'm no native speaker. I always thought the more usual plural
Jürgen Spitzmüller schreef:
Enrico Forestieri wrote:
Jürgen, OK for branch?
Without this patch it is a pain working with child documents.
In some cases, when I have finished quickly typing 5 or 6 characters,
only the first two have been shown on screen.
Is this the slowness issue we h
Alex Fernandez wrote:
> First, this discussion (and the many threads around it) are causing
> unnecessary division among LyX developers. People are suffering
> unnecessary pain because of this. And this because everyone is trying
..
> If the LyX community still wants to integrate eLyXer and it caus
Kornel Benko wrote:
> > The problem is that I have to give it a file extension to make Python
> > recognize it. When I do this also the problem I had with missing includes
> > disappears.
>
> You mean, calling python is not sufficient?
it is, but the question was different - is it possible to ru
Jürgen Spitzmüller wrote:
> What we should do:
>
> * recognize eLyXer as a HTML converter (already done, AFAICS)
do you agree to backport this into branch?
pavel
1 - 100 of 107 matches
Mail list logo
