Lars Gullik Bjønnes wrote:
Helge Hafting [EMAIL PROTECTED] writes:
| On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars I also tried to do some profiling on this, but failed to get
| Lars anything to
Helge Hafting [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| Helge Hafting [EMAIL PROTECTED] writes:
|
| | On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| | Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| | | Lars I also tried to do some
Lars Gullik Bjønnes wrote:
| To set optimization level you should use --enable-optimization='-O2'
|
|
| Ok, tried this. More exactly:
| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| --with-qt-includes=/usr/include/qt3 --disable-debug
| --disable-concept-checks
Helge Hafting wrote:
| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| --with-qt-includes=/usr/include/qt3 --disable-debug
| --disable-concept-checks --enable-optimization=-O2
You should use '--disable-stdlib-debug' as well. that is a real time
consumer, nice when developing
Helge Hafting [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| | To set optimization level you should use --enable-optimization='-O2'
| |
| |
| | Ok, tried this. More exactly:
| | $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| |
Lars Gullik Bjønnes wrote:
Helge Hafting [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| | To set optimization level you should use --enable-optimization='-O2'
| |
| |
| | Ok, tried this. More exactly:
| | $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| |
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge The test method is to run time lyx while clicking the mouse
Helge fast in the place where the closing button is going to appear.
Helge Repeated clicks are used so my reaction time won't affect the
Helge result. I barely see the main window,
On Thu, 8 Dec 2005, Helge Hafting wrote:
The test method is to run
time lyx
while clicking the mouse fast in the place where the closing button is
going to appear.
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
and you don't have close it manually. A long time
On Thu, 8 Dec 2005, [EMAIL PROTECTED] wrote:
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
Christian,
How kewel! I've not had LyX running today, so I gave the above three tries
in succession:
[EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'
On Thu, Dec 08, 2005 at 03:46:45PM +0100, Jean-Marc Lasgouttes wrote:
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge The test method is to run time lyx while clicking the mouse
Helge fast in the place where the closing button is going to appear.
Helge Repeated clicks are used so my
On Thu, Dec 08, 2005 at 09:46:05AM -0800, Rich Shepard wrote:
On Thu, 8 Dec 2005, [EMAIL PROTECTED] wrote:
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
Christian,
How kewel! I've not had LyX running today, so I gave the above three tries
in succession:
On Thu, 8 Dec 2005, Helge Hafting wrote:
Impressive timings. Your first start is faster than my cached startups. My
lyx-1.3 starts in 0.7s, my lyx-1.4 in 3.5s when in cache. Which version of
lyx is this, and does it use xforms or qt?
Helge,
1.3.6qt. On Slack-10.2. A moderately fast
Lars Gullik Bjønnes wrote:
Helge Hafting [EMAIL PROTECTED] writes:
| On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars I also tried to do some profiling on this, but failed to get
| Lars anything to
Helge Hafting [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| Helge Hafting [EMAIL PROTECTED] writes:
|
| | On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| | Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| | | Lars I also tried to do some
Lars Gullik Bjønnes wrote:
| To set optimization level you should use --enable-optimization='-O2'
|
|
| Ok, tried this. More exactly:
| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| --with-qt-includes=/usr/include/qt3 --disable-debug
| --disable-concept-checks
Helge Hafting wrote:
| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| --with-qt-includes=/usr/include/qt3 --disable-debug
| --disable-concept-checks --enable-optimization=-O2
You should use '--disable-stdlib-debug' as well. that is a real time
consumer, nice when developing
Helge Hafting [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| | To set optimization level you should use --enable-optimization='-O2'
| |
| |
| | Ok, tried this. More exactly:
| | $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| |
Lars Gullik Bjønnes wrote:
Helge Hafting [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
|
| | To set optimization level you should use --enable-optimization='-O2'
| |
| |
| | Ok, tried this. More exactly:
| | $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| |
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge The test method is to run time lyx while clicking the mouse
Helge fast in the place where the closing button is going to appear.
Helge Repeated clicks are used so my reaction time won't affect the
Helge result. I barely see the main window,
On Thu, 8 Dec 2005, Helge Hafting wrote:
The test method is to run
time lyx
while clicking the mouse fast in the place where the closing button is
going to appear.
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
and you don't have close it manually. A long time
On Thu, 8 Dec 2005, [EMAIL PROTECTED] wrote:
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
Christian,
How kewel! I've not had LyX running today, so I gave the above three tries
in succession:
[EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'
On Thu, Dec 08, 2005 at 03:46:45PM +0100, Jean-Marc Lasgouttes wrote:
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge The test method is to run time lyx while clicking the mouse
Helge fast in the place where the closing button is going to appear.
Helge Repeated clicks are used so my
On Thu, Dec 08, 2005 at 09:46:05AM -0800, Rich Shepard wrote:
On Thu, 8 Dec 2005, [EMAIL PROTECTED] wrote:
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
Christian,
How kewel! I've not had LyX running today, so I gave the above three tries
in succession:
On Thu, 8 Dec 2005, Helge Hafting wrote:
Impressive timings. Your first start is faster than my cached startups. My
lyx-1.3 starts in 0.7s, my lyx-1.4 in 3.5s when in cache. Which version of
lyx is this, and does it use xforms or qt?
Helge,
1.3.6qt. On Slack-10.2. A moderately fast
Lars Gullik Bjønnes wrote:
Helge Hafting <[EMAIL PROTECTED]> writes:
| On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> I also tried to do some profiling on this, but failed to get
| >
Helge Hafting <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| >Helge Hafting <[EMAIL PROTECTED]> writes:
| >
| >| On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| >| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| > | > | > Lars> I also
Lars Gullik Bjønnes wrote:
| >To set optimization level you should use --enable-optimization='-O2'
| >
| >
| Ok, tried this. More exactly:
| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| --with-qt-includes=/usr/include/qt3 --disable-debug
| --disable-concept-checks
Helge Hafting wrote:
>>| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
>>| --with-qt-includes=/usr/include/qt3 --disable-debug
>>| --disable-concept-checks --enable-optimization=-O2
>>You should use '--disable-stdlib-debug' as well. that is a real time
>>consumer, nice when
Helge Hafting <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| >| >To set optimization level you should use --enable-optimization='-O2'
| >| >
| >| >
| >| Ok, tried this. More exactly:
| >| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld
| >|
Lars Gullik Bjønnes wrote:
Helge Hafting <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
|
| >| >To set optimization level you should use --enable-optimization='-O2'
| >| >
| >| >
| >| Ok, tried this. More exactly:
| >| $ ./configure --prefix=/usr/local --with-frontend=qt
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
Helge> The test method is to run time lyx while clicking the mouse
Helge> fast in the place where the closing button is going to appear.
Helge> Repeated clicks are used so my reaction time won't affect the
Helge> result. I barely see the
On Thu, 8 Dec 2005, Helge Hafting wrote:
> The test method is to run
> time lyx
> while clicking the mouse fast in the place where the closing button is
> going to appear.
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
and you don't have close it manually. A long
On Thu, 8 Dec 2005, [EMAIL PROTECTED] wrote:
Just a minor tip, try this:
time lyx -x 'command-sequence lyx-quit;'
Christian,
How kewel! I've not had LyX running today, so I gave the above three tries
in succession:
[EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'
On Thu, Dec 08, 2005 at 03:46:45PM +0100, Jean-Marc Lasgouttes wrote:
> > "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
>
> Helge> The test method is to run time lyx while clicking the mouse
> Helge> fast in the place where the closing button is going to appear.
> Helge> Repeated
On Thu, Dec 08, 2005 at 09:46:05AM -0800, Rich Shepard wrote:
> On Thu, 8 Dec 2005, [EMAIL PROTECTED] wrote:
>
> >Just a minor tip, try this:
> >
> > time lyx -x 'command-sequence lyx-quit;'
>
> Christian,
>
> How kewel! I've not had LyX running today, so I gave the above three tries
> in
On Thu, 8 Dec 2005, Helge Hafting wrote:
Impressive timings. Your first start is faster than my cached startups. My
lyx-1.3 starts in 0.7s, my lyx-1.4 in 3.5s when in cache. Which version of
lyx is this, and does it use xforms or qt?
Helge,
1.3.6qt. On Slack-10.2. A moderately fast
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge _Editing_ with lyx 1.4 is fine, except from the occational bug.
Helge The startup time is not - it has definitely regressed, and I
Helge wonder if it has to be that way. What could lyx be up to
Helge _before_ l�oading documents?
Helge,
I
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Helge == Helge Hafting [EMAIL PROTECTED] writes:
|
| Helge _Editing_ with lyx 1.4 is fine, except from the occational bug.
| Helge The startup time is not - it has definitely regressed, and I
| Helge wonder if it has to be that way. What could
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I also tried to do some profiling on this, but failed to get
Lars anything to pinpoint. Also on my box startup times are not bad
Lars at all... (sub-second)
I clearly see a difference between 1.3.x and 1.4.x, but the times are
On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I also tried to do some profiling on this, but failed to get
Lars anything to pinpoint. Also on my box startup times are not bad
Lars at all... (sub-second)
I
On Wed, 7 Dec 2005, Helge Hafting wrote:
Evereybody except me get sub-second startup times?
That is good, lyx is probably ok with me making a mistake then.
It'd sure be interesting if anyone have an idea what I do wrong.
Helge,
If I've not invoked LyX before, then it takes about 1-2
Helge Hafting [EMAIL PROTECTED] writes:
| On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars I also tried to do some profiling on this, but failed to get
| Lars anything to pinpoint. Also on my box startup
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge _Editing_ with lyx 1.4 is fine, except from the occational bug.
Helge The startup time is not - it has definitely regressed, and I
Helge wonder if it has to be that way. What could lyx be up to
Helge _before_ l�oading documents?
Helge,
I
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Helge == Helge Hafting [EMAIL PROTECTED] writes:
|
| Helge _Editing_ with lyx 1.4 is fine, except from the occational bug.
| Helge The startup time is not - it has definitely regressed, and I
| Helge wonder if it has to be that way. What could
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I also tried to do some profiling on this, but failed to get
Lars anything to pinpoint. Also on my box startup times are not bad
Lars at all... (sub-second)
I clearly see a difference between 1.3.x and 1.4.x, but the times are
On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars I also tried to do some profiling on this, but failed to get
Lars anything to pinpoint. Also on my box startup times are not bad
Lars at all... (sub-second)
I
On Wed, 7 Dec 2005, Helge Hafting wrote:
Evereybody except me get sub-second startup times?
That is good, lyx is probably ok with me making a mistake then.
It'd sure be interesting if anyone have an idea what I do wrong.
Helge,
If I've not invoked LyX before, then it takes about 1-2
Helge Hafting [EMAIL PROTECTED] writes:
| On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars I also tried to do some profiling on this, but failed to get
| Lars anything to pinpoint. Also on my box startup
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
Helge> _Editing_ with lyx 1.4 is fine, except from the occational bug.
Helge> The startup time is not - it has definitely regressed, and I
Helge> wonder if it has to be that way. What could lyx be up to
Helge> _before_ l�oading documents?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
|
| Helge> _Editing_ with lyx 1.4 is fine, except from the occational bug.
| Helge> The startup time is not - it has definitely regressed, and I
| Helge> wonder if it has to be that way.
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I also tried to do some profiling on this, but failed to get
Lars> anything to pinpoint. Also on my box startup times are not bad
Lars> at all... (sub-second)
I clearly see a difference between 1.3.x and 1.4.x, but the times
On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> I also tried to do some profiling on this, but failed to get
> Lars> anything to pinpoint. Also on my box startup times are not bad
> Lars> at all...
On Wed, 7 Dec 2005, Helge Hafting wrote:
Evereybody except me get sub-second startup times?
That is good, lyx is probably ok with me making a mistake then.
It'd sure be interesting if anyone have an idea what I do wrong.
Helge,
If I've not invoked LyX before, then it takes about 1-2
Helge Hafting <[EMAIL PROTECTED]> writes:
| On Wed, Dec 07, 2005 at 04:58:51PM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> I also tried to do some profiling on this, but failed to get
| > Lars> anything to pinpoint. Also on
Andre Poenitz wrote:
GUII had its time when it came to separating kernel and GUI, and when
there were enough people actually working on LyX. Nowadays it's more
of a hindrance than a help and I'd really appreciate a move to select
a single prefered toolkit.
Hear hear!
--
Angus
On Wed, Nov 09, 2005 at 11:26:36AM +, Angus Leeming wrote:
Helge Hafting wrote:
Still, I really liked the way lyx 1.3 starts in less than a second.
Lyx 1.4 needs 5 seconds to start, even with no document and
debugging turned off.
You are probably compiling with g++'s debug
Andre Poenitz wrote:
GUII had its time when it came to separating kernel and GUI, and when
there were enough people actually working on LyX. Nowadays it's more
of a hindrance than a help and I'd really appreciate a move to select
a single prefered toolkit.
Hear hear!
--
Angus
On Wed, Nov 09, 2005 at 11:26:36AM +, Angus Leeming wrote:
Helge Hafting wrote:
Still, I really liked the way lyx 1.3 starts in less than a second.
Lyx 1.4 needs 5 seconds to start, even with no document and
debugging turned off.
You are probably compiling with g++'s debug
Andre Poenitz wrote:
> GUII had its time when it came to separating kernel and GUI, and when
> there were enough people actually working on LyX. Nowadays it's more
> of a hindrance than a help and I'd really appreciate a move to select
> a single prefered toolkit.
Hear hear!
--
Angus
On Wed, Nov 09, 2005 at 11:26:36AM +, Angus Leeming wrote:
> Helge Hafting wrote:
> > Still, I really liked the way lyx 1.3 starts in less than a second.
> > Lyx 1.4 needs 5 seconds to start, even with no document and
> > debugging turned off.
>
> You are probably compiling with g++'s debug
On Tue, Nov 08, 2005 at 02:43:00PM -0500, William F. Adams wrote:
On Nov 8, 2005, at 11:52 AM, Angus Leeming wrote:
You have a strange definition of ``for free'', William. There are 295
files in the Qt frontend totalling some 27,000 lines of code. And
that's neglecting the .ui files that
On Wed, Nov 09, 2005 at 08:24:58AM +0200, Martin Vermeer wrote:
The idea is that each frontend author is free to implement the dialogs
as he wants. There is no contraint on their layout and/or text.
But that's a bug, not a feature, right? We _should_ strive for uniformity.
This would mean
On Wed, Nov 09, 2005 at 11:54:30AM +0100, Helge Hafting wrote:
Multi-platform?
I have no idea - but the existing qt port is multiplatform so a port
to another toolkit doesn't have to be.
Indeed. And note that we get much better multi-platform support when
using Qt alone than with any
On Tue, Nov 08, 2005 at 06:37:52PM +0100, Gour wrote:
I could also say: gnome, gnome-vfs, internationalization (I18N),
localization (L10N), OS X is there, cairo back-end, win32, and lgpl
license, i.e. not depending on trolltech...
What's wrong with Qt's GPL?
Andre'
On Tue, Nov 08, 2005 at 07:45:00PM +0100, Ingar Pareliussen wrote:
So it is possible to port to other tookits without to much work
That is wrong and does not get better by repeating it.
Supporting yet another toolkit is a significant amount of work, and the
GUII framework makes using toolkits
On Tue, Nov 08, 2005 at 02:43:00PM -0500, William F. Adams wrote:
On Nov 8, 2005, at 11:52 AM, Angus Leeming wrote:
You have a strange definition of ``for free'', William. There are 295
files in the Qt frontend totalling some 27,000 lines of code. And
that's neglecting the .ui files that
On Wed, Nov 09, 2005 at 08:24:58AM +0200, Martin Vermeer wrote:
The idea is that each frontend author is free to implement the dialogs
as he wants. There is no contraint on their layout and/or text.
But that's a bug, not a feature, right? We _should_ strive for uniformity.
This would mean
On Wed, Nov 09, 2005 at 11:54:30AM +0100, Helge Hafting wrote:
Multi-platform?
I have no idea - but the existing qt port is multiplatform so a port
to another toolkit doesn't have to be.
Indeed. And note that we get much better multi-platform support when
using Qt alone than with any
On Tue, Nov 08, 2005 at 06:37:52PM +0100, Gour wrote:
I could also say: gnome, gnome-vfs, internationalization (I18N),
localization (L10N), OS X is there, cairo back-end, win32, and lgpl
license, i.e. not depending on trolltech...
What's wrong with Qt's GPL?
Andre'
On Tue, Nov 08, 2005 at 07:45:00PM +0100, Ingar Pareliussen wrote:
So it is possible to port to other tookits without to much work
That is wrong and does not get better by repeating it.
Supporting yet another toolkit is a significant amount of work, and the
GUII framework makes using toolkits
On Tue, Nov 08, 2005 at 02:43:00PM -0500, William F. Adams wrote:
> On Nov 8, 2005, at 11:52 AM, Angus Leeming wrote:
>
> >You have a strange definition of ``for free'', William. There are 295
> >files in the Qt frontend totalling some 27,000 lines of code. And
> >that's neglecting the .ui files
On Wed, Nov 09, 2005 at 08:24:58AM +0200, Martin Vermeer wrote:
> > The idea is that each frontend author is free to implement the dialogs
> > as he wants. There is no contraint on their layout and/or text.
>
> But that's a bug, not a feature, right? We _should_ strive for uniformity.
This would
On Wed, Nov 09, 2005 at 11:54:30AM +0100, Helge Hafting wrote:
> >Multi-platform?
>
> I have no idea - but the existing qt port is multiplatform so a port
> to another toolkit doesn't have to be.
Indeed. And note that we get much better multi-platform support when
using Qt alone than with any
On Tue, Nov 08, 2005 at 06:37:52PM +0100, Gour wrote:
> I could also say: gnome, gnome-vfs, internationalization (I18N),
> localization (L10N), OS X is there, cairo back-end, win32, and lgpl
> license, i.e. not depending on trolltech...
What's wrong with Qt's GPL?
Andre'
On Tue, Nov 08, 2005 at 07:45:00PM +0100, Ingar Pareliussen wrote:
> So it is possible to port to other tookits without to much work
That is wrong and does not get better by repeating it.
Supporting yet another toolkit is a significant amount of work, and the
GUII framework makes using toolkits
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
The idea is that each frontend author is free to implement the
dialogs as he wants. There is no contraint on their layout and/or
text.
Martin But that's a bug, not a feature, right? We _should_ strive for
Martin uniformity.
I think we
Gour wrote:
Helge Hafting ([EMAIL PROTECTED]) wrote:
Not really. The win32 version of lyx does not in any way make it a
more serious solution. More accessible of course, but no
more serious.
Who said that?
Me? Marc?
Sorry, seems I messed up the quotation. Look at earlier
John Coppens ([EMAIL PROTECTED]) wrote:
Anyway, I see there is some interest (mine included) for a native GTK+
version, so I'll try and compile one (I suspect it compiles at least?).
Who is the person to take contact with for hints/diffs/ etc? Is that John
Spray?
I pulled from the cvs
Angus Leeming wrote:
[...]
Yes, fltk is a very nice little toolkit. In fact, it's the successor
to the XForms library that we do use in one of our frontends.
However, before any eager soul jumps on this frontend bandwagon, I'd
like to introduce a note of caution and suggest that you really,
Gour wrote:
I pulled from the cvs yesterday and it does not compile.
What is preferred method to report things: dev-list or bugzilla?
Bugzilla, but discuss it first on lyx-devel. It's probably something
trivial on your side.
(I had negative experience with bugzilla reporting a dead-keys bug
Helge Hafting wrote:
Still, I really liked the way lyx 1.3 starts in less than a second.
Lyx 1.4 needs 5 seconds to start, even with no document and
debugging turned off.
You are probably compiling with g++'s debug iterators. Try recompiling
having configured with --disable-stdlib-debug and
Angus Leeming ([EMAIL PROTECTED]) wrote:
Bugzilla, but discuss it first on lyx-devel. It's probably something
trivial on your side.
OK. I sent it to the dev-list.
Use the gmane news interface then. You can read and post from
http://news.gmane.org/gmane.editors.lyx.devel
Don't use news at
(Thanks to whoever did it for re-subscribing me to the dev list)
I'm making this last post to both lists and then will try to find the
time to look into things on the lyx-devel side.
As I alluded to before, NeXT/OPEN/GNUstep/Cocoa allows one to
dynamically add and remove language support
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
The idea is that each frontend author is free to implement the
dialogs as he wants. There is no contraint on their layout and/or
text.
Martin But that's a bug, not a feature, right? We _should_ strive for
Martin uniformity.
I think we
Gour wrote:
Helge Hafting ([EMAIL PROTECTED]) wrote:
Not really. The win32 version of lyx does not in any way make it a
more serious solution. More accessible of course, but no
more serious.
Who said that?
Me? Marc?
Sorry, seems I messed up the quotation. Look at earlier
John Coppens ([EMAIL PROTECTED]) wrote:
Anyway, I see there is some interest (mine included) for a native GTK+
version, so I'll try and compile one (I suspect it compiles at least?).
Who is the person to take contact with for hints/diffs/ etc? Is that John
Spray?
I pulled from the cvs
Angus Leeming wrote:
[...]
Yes, fltk is a very nice little toolkit. In fact, it's the successor
to the XForms library that we do use in one of our frontends.
However, before any eager soul jumps on this frontend bandwagon, I'd
like to introduce a note of caution and suggest that you really,
Gour wrote:
I pulled from the cvs yesterday and it does not compile.
What is preferred method to report things: dev-list or bugzilla?
Bugzilla, but discuss it first on lyx-devel. It's probably something
trivial on your side.
(I had negative experience with bugzilla reporting a dead-keys bug
Helge Hafting wrote:
Still, I really liked the way lyx 1.3 starts in less than a second.
Lyx 1.4 needs 5 seconds to start, even with no document and
debugging turned off.
You are probably compiling with g++'s debug iterators. Try recompiling
having configured with --disable-stdlib-debug and
Angus Leeming ([EMAIL PROTECTED]) wrote:
Bugzilla, but discuss it first on lyx-devel. It's probably something
trivial on your side.
OK. I sent it to the dev-list.
Use the gmane news interface then. You can read and post from
http://news.gmane.org/gmane.editors.lyx.devel
Don't use news at
(Thanks to whoever did it for re-subscribing me to the dev list)
I'm making this last post to both lists and then will try to find the
time to look into things on the lyx-devel side.
As I alluded to before, NeXT/OPEN/GNUstep/Cocoa allows one to
dynamically add and remove language support
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> The idea is that each frontend author is free to implement the
>> dialogs as he wants. There is no contraint on their layout and/or
>> text.
Martin> But that's a bug, not a feature, right? We _should_ strive for
Martin> uniformity.
Gour wrote:
Helge Hafting ([EMAIL PROTECTED]) wrote:
Not really. The win32 version of lyx does not in any way make it a
more "serious" solution. More accessible of course, but no
more serious.
Who said that?
Me? Marc?
Sorry, seems I messed up the quotation. Look at earlier
John Coppens ([EMAIL PROTECTED]) wrote:
> Anyway, I see there is some interest (mine included) for a native GTK+
> version, so I'll try and compile one (I suspect it compiles at least?).
> Who is the person to take contact with for hints/diffs/ etc? Is that John
> Spray?
I pulled from the cvs
Angus Leeming wrote:
[...]
Yes, fltk is a very nice little toolkit. In fact, it's the successor
to the XForms library that we do use in one of our frontends.
However, before any eager soul jumps on this frontend bandwagon, I'd
like to introduce a note of caution and suggest that you really,
Gour wrote:
> I pulled from the cvs yesterday and it does not compile.
> What is preferred method to report things: dev-list or bugzilla?
Bugzilla, but discuss it first on lyx-devel. It's probably something
trivial on your side.
> (I had negative experience with bugzilla reporting a dead-keys
Helge Hafting wrote:
> Still, I really liked the way lyx 1.3 starts in less than a second.
> Lyx 1.4 needs 5 seconds to start, even with no document and
> debugging turned off.
You are probably compiling with g++'s debug iterators. Try recompiling
having configured with --disable-stdlib-debug
Angus Leeming ([EMAIL PROTECTED]) wrote:
> Bugzilla, but discuss it first on lyx-devel. It's probably something
> trivial on your side.
OK. I sent it to the dev-list.
> Use the gmane news interface then. You can read and post from
> http://news.gmane.org/gmane.editors.lyx.devel
Don't use news
(Thanks to whoever did it for re-subscribing me to the dev list)
I'm making this last post to both lists and then will try to find the
time to look into things on the lyx-devel side.
As I alluded to before, NeXT/OPEN/GNUstep/Cocoa allows one to
dynamically add and remove language support
James W Dow schrieb:
LyX is a wonderful word processor. It is best one for writing mathematics
directly from the keyboard. Please don't spend a huge time developing it for
Windows. Windows will gradually fade away. Putting nice programs like LyX on
that operating system just delays people
1 - 100 of 231 matches
Mail list logo
