Re: Forget Windows

[Rich Shepard]

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 machine, but a standard (slow)
hard drive.

Rich

--
Richard B. Shepard, Ph.D.   |   Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM)   |  Impact Assessments Using Fuzzy Logic"
 Voice: 503-667-4517 Fax: 503-667-8863

Re: Forget Windows

[Helge Hafting]

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:
> 
> [EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'
> 
> real0m2.014s
> user0m0.280s
> sys 0m0.050s
> [EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'
> 
> real0m0.345s
> user0m0.230s
> sys 0m0.030s
> [EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'
> 
> real0m0.342s
> user0m0.260s
> sys 0m0.010s
> 
>   Both the startup times and the use of the automatic command-sequence with
> the time command are impressive.
> 
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 Hafting 

Re: Forget Windows

[Helge Hafting]

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 reaction time won't affect the
> Helge> result. I barely see the main window, it is removed as soon as
> Helge> it appears.
> 
> You can try also "lyx -x lyx-quit"
> 
Thanks.  Much easier, and I get the same timings.

> Helge> Is there some sort of profiling I could try?
> 
> Try to run lyx with option "-dbg init" and see whether there is a long
> time between two particular messages.
> 

I got two noticeable pauses:

Setting debug level to init
Debugging `init' (Program initialisation)
Checking whether LyX is run in place... no

binary_dir /usr/local/bin/
system_support /usr/local/share/lyx/
build_support 
user_support /home/helge/.lyx/
locale_dir /usr/local/share/locale/
document_dir /home/helge
temp_dir /tmp
home_dir /home/helge


Initializing LyX::init...

NOTICEABLE DELAY HERE

About to read lyxrc.defaults...
Found lyxrc.defaults in /home/helge/.lyx/lyxrc.defaults
About to read preferences...
Found preferences in /home/helge/.lyx/preferences
About to read encodings...
Reading encoding iso8859-2
Reading encoding iso8859-3
Reading encoding iso8859-4
Reading encoding iso8859-5
Reading encoding iso8859-6
Reading encoding iso8859-7
Reading encoding iso8859-9
Reading encoding iso8859-13
Reading encoding iso8859-15
Reading encoding cp1255
Reading encoding cp1251
Reading encoding koi8
Reading encoding koi8-u
Reading encoding tis620-0
Reading encoding pt154
About to read languages...
Reading language afrikaans
Reading language american
Reading language arabic
Reading language austrian
Reading language bahasa
Reading language belarusian
Reading language basque
Reading language brazil
Reading language breton
Reading language british
Reading language bulgarian
Reading language canadian
Reading language canadien
Reading language catalan
Reading language croatian
Reading language czech
Reading language danish
Reading language dutch
Reading language english
Reading language esperanto
Reading language estonian
Reading language finnish
Reading language french
Reading language galician
Reading language german
Reading language ngerman
Reading language greek
Reading language hebrew
Reading language irish
Reading language italian
Reading language kazakh
Reading language lithuanian
Reading language latvian
Reading language icelandic
Reading language magyar
Reading language norsk
Reading language nynorsk
Reading language polish
Reading language portuges
Reading language romanian
Reading language russian
Reading language scottish
Reading language serbian
Reading language serbocroatian
Reading language spanish
Reading language slovak
Reading language slovene
Reading language swedish
Reading language thai
Reading language turkish
Reading language ukrainian
Reading language welsh
Reading layouts...
About to read default...
Found default in /usr/local/share/lyx/ui/default.ui
About to read stdmenus.ui...
Found stdmenus.ui in /usr/local/share/lyx/ui/stdmenus.ui
About to read stdtoolbars.ui...
Found stdtoolbars.ui in /usr/local/share/lyx/ui/stdtoolbars.ui
LyX tmp dir: `/tmp/lyx_tmpdir256720kz6fB'
Reading lastfiles `/home/helge/.lyx/lastfiles'...
Initializing LyX::init...done

EVEN LONGER DELAY HERE

About to handle -x 'lyx-quit'
Warning: this system's locale uses Unicode.
Language code:nb_NO
Setting new locale for Qt:nb_NO
Initializing LyXFunc
Initializing key mappings...


These two delays account for practically all the startup time - 
the other messages scrolls by too fast to read.

Helge Hafting

Re: Forget Windows

[Rich Shepard]

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;'

real0m2.014s
user0m0.280s
sys 0m0.050s
[EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'

real0m0.345s
user0m0.230s
sys 0m0.030s
[EMAIL PROTECTED] ~]$ time lyx -x 'command-sequence lyx-quit;'

real0m0.342s
user0m0.260s
sys 0m0.010s

  Both the startup times and the use of the automatic command-sequence with
the time command are impressive.

Thanks,

Rich

--
Richard B. Shepard, Ph.D.   |   Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM)   |  Impact Assessments Using Fuzzy Logic"
 Voice: 503-667-4517 Fax: 503-667-8863

Re: Forget Windows

[chr]

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 ago I (for practice) 
wrote a script that times lyx doing something, see here:

http://wiki.lyx.org/devel/pmwiki.php/DevelTools/TimeLyx

/Christian

-- 
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "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, it is removed as soon as
Helge> it appears.

You can try also "lyx -x lyx-quit"

Helge> Is there some sort of profiling I could try?

Try to run lyx with option "-dbg init" and see whether there is a long
time between two particular messages.

JMarc

Re: Forget Windows

[Helge Hafting]

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
| >| --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 but not else.
| >
| So --disable-stdlib-debug is not implied by --disable-debug?

No, I do not think so... (hmm ... I cannot remember how I implementet
this bug stdlib debug and debug are realy ortogonal)
 


Well, this helped -- a little.
With
$ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld 
--with-qt-includes=/usr/include/qt3 --disable-debug 
--disable-concept-checks --disable-stdlib-debug --enable-optimization=-O2

I got 4.7s starting lyx instead of 5.2s

Starting with LANG=C brings this further down to 4.6s, so 
internationalization

is not the big culprit.

The test method is to run
time lyx
while clicking the mouse fast in the place where the closing button is 
going to
appear.  Repeated clicks are used so my reaction time won't affect the 
result.

I barely see the main window, it is removed as soon as it appears.

The same kind of timing for lyx-qt 1.3.6 from debian is 0.7s, with or 
without

translations. So it doesn't seem like a debian problem.

Is there some sort of profiling I could try?

Helge Hafting

Re: Forget Windows

[Lars Gullik Bjønnes]

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
| >| --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 but not else.
| >
| So --disable-stdlib-debug is not implied by --disable-debug?

No, I do not think so... (hmm ... I cannot remember how I implementet
this bug stdlib debug and debug are realy ortogonal)


-- 
Lgb

Re: Forget Windows

[Angus Leeming]

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 but not else.

> So --disable-stdlib-debug is not implied by --disable-debug?

You'd imagine so, but no.

All --enable-debug does is add '-g ' to CFLAGS and to CXXFLAGS whilst
--enable-stdlib-debug adds the preprocessor commands

#define _GLIBCXX_DEBUG 1
#define _GLIBCXX_DEBUG_PEDANTIC 1

to config.h. Boy, do these two have a big effect on performance! Without
them, LyX is literally an order of magnitude faster. At least, it is for
me ;-)

-- 
Angus

Re: Forget Windows

[Helge Hafting]

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 --enable-optimization=-O2

You should use '--disable-stdlib-debug' as well. that is a real time
consumer, nice when developing but not else.
 


So --disable-stdlib-debug is not implied by --disable-debug?

Using  --enable-optimization=-O2 did not help.
Using -Os instead of -O2 gave me a much smaller binary, but
it did not help. Using just
$ ./configure --prefix=/usr/local --with-frontend=qt 
--with-qt-includes=/usr/include/qt3 --disable-debug


was just as bad.

the best I get is 5.2s for starting lyx, the worst I get is 5.4s depending
on the optimizations.  This on the 2.4GHz pentium.  I'll try throwing in
--disable-stdlib-debug next.

Helga Hafting

Re: Forget Windows

[Lars Gullik Bjønnes]

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 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
| >| > reasonably short.
| > | | 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.
| > | | My configure command, using optimizations and disabling
| >| some costly debugging.  Are there perhaps other things that impact speed?
| > | | | $ ./configure --prefix=/usr/local --with-frontend=qt
| > --with-gnu-ld | --with-qt-includes=/usr/include/qt3
| > --disable-stdlib-debug | --disable-concept-checks
| > --enable-assertions CFLAGS=-O2 CPPFLAGS=-O2
| >
| >Even on a build with this:
| >
| >./configure --with-frontend=qt --disable-debug
| >
| >And when starting I get sub-2-second startup. (cached, no disk read needed)
| >This in on a AMD XP 2400
| >
| >The only thing I see with your configure line that could be changed in
| >the last two variables that you set... (btw. does it work to set them
| >last on the command line?)
| >
| >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 --enable-optimization=-O2

You should use '--disable-stdlib-debug' as well. that is a real time
consumer, nice when developing but not else.

-- 
Lgb

Re: Forget Windows

[Helge Hafting]

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 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

| > reasonably short.
| 
| 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.
| 
| My configure command, using optimizations and disabling

| some costly debugging.  Are there perhaps other things that impact speed?
| 
| 
| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld 
| --with-qt-includes=/usr/include/qt3 --disable-stdlib-debug 
| --disable-concept-checks --enable-assertions CFLAGS=-O2 CPPFLAGS=-O2


Even on a build with this:

./configure --with-frontend=qt --disable-debug

And when starting I get sub-2-second startup. (cached, no disk read needed)
This in on a AMD XP 2400

The only thing I see with your configure line that could be changed in
the last two variables that you set... (btw. does it work to set them
last on the command line?)

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 --enable-optimization=-O2


Lyx takes 5 seconds to start on a pentium M, 2.4 GHz.  The 3 seconds
previously mentioned was on the 1.8GHz opteron.  I have
compiled with these options there too, and will time it again
when I get to the machine. (No use timing lyx over the ADSL line, we'll be
waiting for tunneled X in that case.)

I am now trying -Os instead of -O2.  If that doesn't help, I'll try your
config to check if there is something weird going on, like
--with-gnu-ld or one of the others unexpectedly triggering something.



Hmm are these 64bit binaries or 32bit? (does that matter?)
 


I hope not!  This was from the opteron, so all libraries was 64-bit.
It is the fastest of my two test machines anyway.


On my FC4 running on an AMD64 XP3500 all the above libraries point
into some lib64 dir. (might very well be one of the differenced
between debian and fedora)
 

Yes.  Debians amd64 is a 64-bit port, so the 64-bit libraries is in 
/lib.  There
are no 32-bit stuff at all, unless you install it in order to support 
the odd

32-bit binary-only program, like adobe acrobat or wine. (Well, wine is
open source but it runs 32-bit proprietary sw...)
Debian has a /lib64, but it is merely a link to /lib.

Helge Hafting

Re: Forget Windows

[Lars Gullik Bjønnes]

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 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
| > reasonably short.
| 
| 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.
| 
| My configure command, using optimizations and disabling
| some costly debugging.  Are there perhaps other things that impact speed?
| 
| 
| $ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld 
| --with-qt-includes=/usr/include/qt3 --disable-stdlib-debug 
| --disable-concept-checks --enable-assertions CFLAGS=-O2 CPPFLAGS=-O2

Even on a build with this:

./configure --with-frontend=qt --disable-debug

And when starting I get sub-2-second startup. (cached, no disk read needed)
This in on a AMD XP 2400

The only thing I see with your configure line that could be changed in
the last two variables that you set... (btw. does it work to set them
last on the command line?)

To set optimization level you should use --enable-optimization='-O2'


| gcc and g++ are version 4.0.2 from debian testing
| 
| 
| Libraries I use, all from debian testing:
| $ ldd `which lyx`
| libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x2abc3000)
| libaudio.so.2 => /usr/lib/libaudio.so.2 (0x2b6aa000)
| libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x2b7d4000)
| libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x2b935000)
| libpng12.so.0 => /usr/lib/libpng12.so.0 (0x2ba56000)
| libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x2bb7b000)
| libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x2bc83000)
| libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x2bd86000)
| libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 
(0x2be91000)
| libXft.so.2 => /usr/lib/libXft.so.2 (0x2bf93000)
| libXrender.so.1 => /usr/lib/libXrender.so.1 (0x2c0a7000)
| libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x2c1b1000)
| libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x2c33f000)
| libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x2c47e000)
| libpthread.so.0 => /lib/libpthread.so.0 (0x2c59)
| libaspell.so.15 => /usr/lib/libaspell.so.15 (0x2c6a5000)
| libdl.so.2 => /lib/libdl.so.2 (0x2c89a000)
| libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x2c99e000)
| libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x2caa8000)
| libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x2cbc3000)
| libz.so.1 => /usr/lib/libz.so.1 (0x2cda3000)
| libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2ceb9000)
| libm.so.6 => /lib/libm.so.6 (0x2d0b4000)
| libc.so.6 => /lib/libc.so.6 (0x2d23a000)
| libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2d477000)
| libexpat.so.1 => /usr/lib/libexpat.so.1 (0x2d585000)
| /lib64/ld-linux-x86-64.so.2 (0x2aaab000)

Hmm are these 64bit binaries or 32bit? (does that matter?)

On my FC4 running on an AMD64 XP3500 all the above libraries point
into some lib64 dir. (might very well be one of the differenced
between debian and fedora)

-- 
Lgb

Re: Forget Windows

[Rich Shepard]

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 seconds to come up
on my Slackware-10.2 box (AMD Athlon XP/2200+. 1G RAM, 5400 rpm hard drive).
Once it's been opened, re-invoking it brings it up in less than a second.
Something must be cached somewhere.

Rich

--
Richard B. Shepard, Ph.D.   |   Author of "Quantifying Environmental
Applied Ecosystem Services, Inc. (TM)   |  Impact Assessments Using Fuzzy Logic"
 Voice: 503-667-4517 Fax: 503-667-8863

Re: Forget Windows

[Helge Hafting]

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 clearly see a difference between 1.3.x and 1.4.x, but the times are
> reasonably short.

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.

My configure command, using optimizations and disabling
some costly debugging.  Are there perhaps other things that impact speed?


$ ./configure --prefix=/usr/local --with-frontend=qt --with-gnu-ld 
--with-qt-includes=/usr/include/qt3 --disable-stdlib-debug 
--disable-concept-checks --enable-assertions CFLAGS=-O2 CPPFLAGS=-O2

gcc and g++ are version 4.0.2 from debian testing


Libraries I use, all from debian testing:
$ ldd `which lyx`
libqt-mt.so.3 => /usr/lib/libqt-mt.so.3 (0x2abc3000)
libaudio.so.2 => /usr/lib/libaudio.so.2 (0x2b6aa000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x2b7d4000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x2b935000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x2ba56000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x2bb7b000)
libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x2bc83000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x2bd86000)
libXinerama.so.1 => /usr/X11R6/lib/libXinerama.so.1 (0x2be91000)
libXft.so.2 => /usr/lib/libXft.so.2 (0x2bf93000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x2c0a7000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x2c1b1000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x2c33f000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x2c47e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x2c59)
libaspell.so.15 => /usr/lib/libaspell.so.15 (0x2c6a5000)
libdl.so.2 => /lib/libdl.so.2 (0x2c89a000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x2c99e000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x2caa8000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x2cbc3000)
libz.so.1 => /usr/lib/libz.so.1 (0x2cda3000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2ceb9000)
libm.so.6 => /lib/libm.so.6 (0x2d0b4000)
libc.so.6 => /lib/libc.so.6 (0x2d23a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2d477000)
libexpat.so.1 => /usr/lib/libexpat.so.1 (0x2d585000)
/lib64/ld-linux-x86-64.so.2 (0x2aaab000)

Helge Hafting

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "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
reasonably short.

JMarc

Re: Forget Windows

[Lars Gullik Bjønnes]

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 lyx be up to
| Helge> _before_ l�oading documents?
| 
| Helge,
| 
| I tried to profile the startup time and guess where the time goes, but
| did not see anything notable. It is weird.

I also tried to do some profiling on this, but failed to get anything
to pinpoint. Also on my box startup times are not bad at all...
(sub-second)

-- 
Lgb

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "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 tried to profile the startup time and guess where the time goes, but
did not see anything notable. It is weird.

JMarc

Re: Forget Windows

[Helge Hafting]

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 iterators. Try recompiling
> having configured with --disable-stdlib-debug and things should be an
> order of magnitude faster.
> 
With --disable-stdlib-debug and -O2 optimization, it still takes
3.6 seconds to start lyx-1.4 - without any document.  Just to get
the empty main window.  This on a 1.8 GHz opteron, which compiles
lyx way faster than an 2.4GHz pentium M does.  Of course lyx started
from cache, I started it several times in a row to rule out disk
slowness.  

No kind of document/paragraph problems - this is the startup time
without a document.  And probably not a qt problem either, as
lyx 1.3 uses qt and starts in less than a second.

_Editing_ with lyx 1.4 is fine, except from the occational bug.
The startup time is not - it has definitely regressed, and
I wonder if it has to be that way. What could lyx be up to _before_
l�oading documents?

Helge Hafting 

Re: Forget Windows

[Angus Leeming]

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

Re: Forget Windows

[Andre Poenitz]

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'

Re: Forget Windows

[Andre Poenitz]

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 harder than using the toolkits
natively.

Furthermore, there is no real need to have several toolkits as long as
we use one that's fairly platform neutral.

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.

Andre' 

Re: Forget Windows

[Andre Poenitz]

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 'least common denominator of all toolkits'.  And this
means even more restrictions with every new toolkit.

And why the f*** are we discussing new toolkits at all?  We can barely
cope with two of them, don't find time to solve real problems and yet
spend time discussing benefits of yet another obscure toolkit...

Andre'

Re: Forget Windows

[Andre Poenitz]

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 homegrown framework that supports several
toolkits simultaneously.

Want handling of external processes? Use QProcess and be done.

Want handling of user defined settings and save application state?
Use QSettings and be done.

Andre'

Re: Forget Windows

[Andre Poenitz]

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 define the dialog structure.
> 
> Yes, but all those lines and the QT front-end don't get one the same 
> sort of user-experience and integration which ``just happens'' for 
> NeXT/OPEN/GNUstep and Mac OS X.

And it doesn't give the same user experience that 'just happens' for
Qt, simply because it uses only a fraction of the possibilities.

> >For those interested in such stats, the whole LyX source tree
> >(neglecting non-Qt frontend code) comprises 970 files and 170,000
> >lines of code. The thing is *big* and doesn't need to get any bigger.
> 
> I thought that the whole point to GUI-Independence was that it would be 
> possible to plug-in other front-ends w/o negatively impacting the 
> back-end code?

This was one goal. Another was to have a GUI/kernel separation as such.
We have the latter now. We don't have the formaer and I doubt it will
be achievable far above the 'least common denominator' level.

Andre'

internationalization issues (was Re: Forget Windows)

[William F. Adams]

(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 from a compiled program, 
and it'd be nice for LyX to have a similar facility (perhaps it already 
does, I haven't looked into it yet).


For the matter of different dialogs in different front-end versions, it 
seems to me that the solution would be to have a single place to store 
_all_ such, and then the xforms version grabs a version specific to it, 
while the QT version gets one which it wants, and in the event of a 
single version being available, they all fall back to that.


That way a translator only has one file/set to work on.

As an example, TeXshop has the following directories in itself:

Dutch.lproj
English.lproj
French.lproj
German.lproj
Italian.lproj
Japanese.lproj
Portuguese.lproj
Romanian.lproj
Spanish.lproj

each of which provides support for the appropriate language.

English.lproj then has:

Credits.rtf
CustomInfo.plist
FindPanel.nib
FindPanel.strings
InfoPlist.strings
Localizable.strings
MacroEditor.nib
MainMenu.nib
MyDocument.nib
Preferences.nib
TeXShop.scriptTerminology
TeXShopHelp
ToolbarItems.strings
completionpanel1.2.nib
matrixpanel.nib

One really cool thing here is that a user can edit a program's .nib 
files to introduce new capabilities w/o recompiling the app.


Anyway, I hope that this is seen as helpful or constructive. I really 
feel LyX is one of the most innovative, and forward-looking 
applications available (open or closed-source) and am very glad to have 
a new version running again, and am very much looking forward to 1.4 
and beyond.


William


--
William Adams, publishing specialist
voice - 717-731-6707 | Fax - 717-731-6708
www.atlis.com

Re: Forget Windows

[Gour]

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 all :-)

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Angus Leeming]

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 things should be an
order of magnitude faster.

Angus

Re: Forget Windows

[Angus Leeming]

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
> which was not confirmed almost one year, and dev-list has too much
> traffic for occasional reporting.)

Use the gmane news interface then. You can read and post from
http://news.gmane.org/gmane.editors.lyx.devel

Angus

Re: Forget Windows

[Helge Hafting]

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,
really shouldn't create yet another frontend to LyX. Time is limited,
there are only so many of us and another frontend would just be more
to maintain for no real benefit.

I think we'd all like to see improved core functionality in future
releases. The last three or four years have seen increased prettiness
and stability and *much* nicer code but little real increase in what
LyX can actually do. Now that we have something that's at least
reasonably modern looking, let's turn the thing into the world beater
we always hoped it would be.
 


I agree.  Currently, I report bugs and test patches.  When 1.4
gets out, I'll see if I can add support for some of the stuff I like, 
such as

\dotfill and multicols. :-)

Helge Hafting

Re: Forget Windows

[Gour]

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 yesterday and it does not compile.

What is preferred method to report things: dev-list or bugzilla?

(I had negative experience with bugzilla reporting a dead-keys bug which
was not confirmed almost one year, and dev-list has too much traffic for
occasional reporting.)

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Helge Hafting]

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 messages. . .

 


Now, if we're making wishes - scratch the bloated gtk and
go for fltk.  Lightweight they way it should be, and it has
nice stuff like unicode and antialiasing anyway.  
   



I just moved kde --> gnome and do not understand what would be the
advantage of fltk over gtk and/or Qt?
 


The advantage is that it is smaller.  Bot qt and gtk are big and
bloated.  It makes a difference for those of us who runs neither
kde nor gnome on the desktop.  (Logging in to icewm takes 3 seconds,
looking at someone logging in to kde is apalling. Half a minute?) And
that is on a fast 2GHz machine, there are people using much older
stuff than that.  I remember running lyx on a pentium-90.  It took
some time to start, but would scroll through the userguide with
lightning speed.  No other wordprocessor came close, editing was
_fast_.

It probably make little differnce to someone who has he toolkit loaded
already (because the window manager or other app uses it)

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. 


Multi-platform?
 


I have no idea - but the existing qt port is multiplatform so a port
to another toolkit doesn't have to be. 


I was thinking about that in the time when I proposed wxWidgets as a one
multi-platform kit, but today I'm more for GTK+.

However, I also understand that we won't see GTK and/or GNOME port soon,
but nobody can prevent me dreaming :-)
 


The same goes for fltk of course.  Just a dream, there are more
important goals.

Helge Hafting

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "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 should, but at that time the Qt frontend authors did not
want to have their hands bound by how the xforms frontend works.

JMarc

Re: Forget Windows

[Martin Vermeer]

On Tue, 08 Nov 2005 23:53:39 +0100 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> 
wrote:

> > "Alex" == Alex  <[EMAIL PROTECTED]> writes:
> 
> Alex> Why? The GUI indepence means same content, different look. Isn't
> Alex> it?
> 
> 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.

- Martin
 

Re: Forget Windows

[Angus Leeming]

William F. Adams wrote:
>> For those interested in such stats, the whole LyX source tree
>> (neglecting non-Qt frontend code) comprises 970 files and 170,000
>> lines of code. The thing is *big* and doesn't need to get any bigger.
> 
> I thought that the whole point to GUI-Independence was that it would be
> possible to plug-in other front-ends w/o negatively impacting the
> back-end code?

Right. It is. But who's going to write and maintain the 27000 lines of
frontend code for the frontend of your choice?

>> 
>> Most modern toolkits have unicode support. So what? The Qt frontend
>> has native unicode support and works today.
>> 
> 
> Not on Mac OS X in any way I can fathom.

Sorry, I meant that the Qt *toolkit* has unicode support. LyX itself uses
plain ol' char to store single-byte characters. That's slated to change in
the 1.5 development series.

> I'll try to resubscribe and see if I can help out. Short version is
> it'd be ideal if there were a cross-platform version of XeTeX
> (http://scripts.sil.org/xetex) available now to make use of

The first thing to do will of course be to see if a unicode LyX can get a
unicode-aware latex to run happily with unicode data. In the real world of
course, we'll have to interact with latex-es that know as much about
unicode as my granny.

-- 
Angus

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "Alex" == Alex  <[EMAIL PROTECTED]> writes:

Alex> Why? The GUI indepence means same content, different look. Isn't
Alex> it?

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.

JMarc

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> It doesn't actually make anybody's life easier because the
Angus> different frontends do actually have subtly different dialogs
Angus> and messages.

I suspect 50% of the strings would turn out to be common.

JMarc

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "William" == William F Adams <[EMAIL PROTECTED]> writes:

>> I have (almost) finshed the translation of Qt strings. It would be
>> useful, If I could reuse all of them, without doublecating thoose
>> strings.

William> This is one of the things one could get ``for free'' w/ a
William> move to NeXT/OPEN/GNUstep/Cocoa, since it has a facility for
William> dealing with this.

Dealing with what?

JMarc

Re[4]: Forget Windows

[Alex]

Dear Angus & List,

>> Ingar>> As a translator I have to say that the number of toolkits
>> Ingar>> increase the amount of work for the translators as well.

>> JML> Note we could make an effort to change this: use the &shortcut

>> Is it possible to create a translation code internally, to handle the
>> differences in GUIs?

>> We could make it simplier, by making a string convertion for every GUI.

AL> It doesn't actually make anybody's life easier because the different
AL> frontends do actually have subtly different dialogs and messages.

Why? The GUI indepence means same content, different look. Isn't it?

I thougth that the main reason for creating different frontends is achieve
independence from OS native graphics support. You can compile it under
different GUIs for example: GTK, Qt and XForms, whenever they are already
exits for different OSes, they can solve most of the porting effort.
So the developer can focus on important issues.

Maybe, I am totally wrong, am I???


AL> If you want to support only Qt, then do so. I'm firmly of the opinion that
AL> we should ditch XForms and force the Gtk frontend to be "self sufficient".

I have to add support for all of the frontends, of course! This is not a
question. I am friend of LyX, not its enemy! In case I would like to help to
distribute LyX, I have to do it with whole LyX, not with half.

-- 
 Alexmailto:[EMAIL PROTECTED]

Re: Forget Windows

[Georg Baum]

Am Dienstag, 8. November 2005 22:18 schrieb John Coppens:

> 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?).

Yes, it does, and it is also somewhat useful, since it borrows xforms 
dialogs.

> Who is the person to take contact with for hints/diffs/ etc? Is that 
John
> Spray?

Probably the devel mailing list.


Georg

Re: Forget Windows

[John Coppens]

On Tue, 08 Nov 2005 14:53:06 +
Angus Leeming <[EMAIL PROTECTED]> wrote:

> Frankly, I don't think that's true. Looking back over the mail list
> archive as far as 22 Oct, I see the list of messages below. (Sorted
> alphabetically.) Most all of 'em are probelms that aren't specific to
> Windows, even if there's a Windows in the title.

Hi Angus.

Must be that I'm over-sensitive to the discussions of those issues ;-)
I suspect I instinctively made a weighted average - personally I can't see
the sense of it, but that's what makes the world a colorful place.

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?

John

Re: Re[2]: Forget Windows

[Angus Leeming]

[EMAIL PROTECTED] wrote:

> Dear All,
> 
> Ingar>> As a translator I have to say that the number of toolkits
> Ingar>> increase the amount of work for the translators as well.
> Ingar>> Different toolsets have different ways to specify shortcuts and
> Ingar>> each have to be translated manually.
> 
> JML> Note we could make an effort to change this: use the &shortcut
> JML> notation everywhere and avoid gratuitous differences between
> JML> frontends.
> 
> Is it possible to create a translation code internally, to handle the
> differences in GUIs?
> 
> I have (almost) finshed the translation of Qt strings. It would be
> useful, If I could reuse all of them, without doublecating thoose
> strings.
> 
> Now, I have to copy/paste, change shortcut, verify, etc.
> 
> We could make it simplier, by making a string convertion for every GUI.

It doesn't actually make anybody's life easier because the different
frontends do actually have subtly different dialogs and messages.

If you want to support only Qt, then do so. I'm firmly of the opinion that
we should ditch XForms and force the Gtk frontend to be "self sufficient".
If it survives, great, but let's not invest too much of our own time on
it.
 
Angus (slightly millitant, largely retired and probably irrelevant :-))

Re: Forget Windows

[William F. Adams]

On Nov 8, 2005, at 1:18 PM, [EMAIL PROTECTED] wrote:


Is it possible to create a translation code internally, to handle the
differences in GUIs?

I have (almost) finshed the translation of Qt strings. It would be
useful, If I could reuse all of them, without doublecating thoose 
strings.


This is one of the things one could get ``for free'' w/ a move to 
NeXT/OPEN/GNUstep/Cocoa, since it has a facility for dealing with this.


William

--
William Adams, publishing specialist
voice - 717-731-6707 | Fax - 717-731-6708
www.atlis.com

Re: Forget Windows

[William F. Adams]

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 define the dialog structure.


Yes, but all those lines and the QT front-end don't get one the same 
sort of user-experience and integration which ``just happens'' for 
NeXT/OPEN/GNUstep and Mac OS X.



For those interested in such stats, the whole LyX source tree
(neglecting non-Qt frontend code) comprises 970 files and 170,000
lines of code. The thing is *big* and doesn't need to get any bigger.


I thought that the whole point to GUI-Independence was that it would be 
possible to plug-in other front-ends w/o negatively impacting the 
back-end code?



In particular, it'd jump-start native UTF-8 support.



Most modern toolkits have unicode support. So what? The Qt frontend
has native unicode support and works today.



Not on Mac OS X in any way I can fathom.

The Edit menu in 1.40 pre2 doesn't have a ``Special characters'' entry, 
nor is there any way to choose an input method AFAICT. I just tried 
switching to the Korean keyboard and it totally disabled typing in.


Maybe this works in Linux, but I haven't had that installed since the 
last time I installed mklinux on my wife's PowerMac at home for a 
contract job.



Swiching the LyX internals over to unicode is the "big plan" for a 1.5
release. The fun will come in getting unicode to fit seemlessly with
LaTeX. You're something of a LaTeX expert, no? I'm sure you could
point out some of the problems. (To the lyx-devel list please.)


I'll try to resubscribe and see if I can help out. Short version is 
it'd be ideal if there were a cross-platform version of XeTeX 
(http://scripts.sil.org/xetex) available now to make use of


Thanks!

William

--
William Adams, publishing specialist
voice - 717-731-6707 | Fax - 717-731-6708
www.atlis.com

Re[2]: Forget Windows

[Alex]

Dear All,

Ingar>> As a translator I have to say that the number of toolkits
Ingar>> increase the amount of work for the translators as well.
Ingar>> Different toolsets have different ways to specify shortcuts and
Ingar>> each have to be translated manually.

JML> Note we could make an effort to change this: use the &shortcut
JML> notation everywhere and avoid gratuitous differences between
JML> frontends.

Is it possible to create a translation code internally, to handle the
differences in GUIs?

I have (almost) finshed the translation of Qt strings. It would be
useful, If I could reuse all of them, without doublecating thoose strings.

Now, I have to copy/paste, change shortcut, verify, etc.

We could make it simplier, by making a string convertion for every GUI.

-- 
 Alexmailto:[EMAIL PROTECTED]

Re: Forget Windows

[Ingar Pareliussen]

Tysdag 8. november 2005 18:48 skreiv Stephen Harris:

> SH: Hmmm. I like the KDE desktop and looked into the Cygwin port
> of KDE to Windows, which has been abandoned. Now the effort is
> to produce a native Windows KDE. I thought I read that this effort
> relied on Qt (3?) similar to LyX?

For the time being kde on windows is vapor ware. As far as I know the only 
work being done is to make the buildsystem of kde working in windows. When 
that is done they would need a lot of dedicated windows developers to port 
the code. If those do not materialize there will never be a kde release for 
windows.
http://www.kdedevelopers.org/node/1530#comment

So you are correct that the upcoming kde on windows relies on Qt4 for windows. 
And that lyx as well depends on qt (at least for the qt-toolkit port of 
lyx :) ). But (for the time being) lyx do not depend on kde.

Ingar

Re: Forget Windows

[Ingar Pareliussen]

Tysdag 8. november 2005 17:59 skreiv Gour:
> Lars Gullik Bjønnes ([EMAIL PROTECTED]) wrote:
> > Note that code share is in the very high 90's %.

> So, it means that, in case qt goes non-gpl or something, it would not be
> too hard to port to another toolkit?

Lyx source code was divided in 2000(-01?) into two parts, one which is 
gui-independent and similar for all toolkits and a part that was dependent on 
the toolkit. (the toolkits started at that time was xforms, qt and gtk). 

So it is possible to port to other tookits without to much work (Not that I 
could do it :) ). However, there have been little interest in gtk port it 
seems, judging by the speed of development. 

However, this gui-independence means, as far as I have understood it, that you 
have to code into lyx a lot of library-stuff, like spellchecker, as you can 
not rely on code that might not be present in some toolkits/environments. 

You do not need to worry about trolltech removing qt from its gpl license. It 
can't happen, the source code is out there covered by gpl. Trolltech might, 
if they turn bad, stop releasing new versions of qt under gpl. In that case 
the last gpl released qt-version turns to a bsd license. 

http://www.kde.org/whatiskde/kdefreeqtfoundation.php
and even more kde myths debunked here :)
http://kdemyths.urbanlizard.com/

Ingar

Re: Forget Windows

[Adrien Rebollo]

Jean-Marc Lasgouttes a écrit :


"Ingar" == Ingar Pareliussen <[EMAIL PROTECTED]> writes:
   



Ingar> As a translator I have to say that the number of toolkits
Ingar> increase the amount of work for the translators as well.
Ingar> Different toolsets have different ways to specify shortcuts and
Ingar> each have to be translated manually.

Note we could make an effort to change this: use the &shortcut
notation everywhere and avoid gratuitous differences between
frontends.

JMarc
 

I can only subscribe to that. To have to test the different translations 
and shortcuts in the different frontends is a pain. I have myself nearly 
abandoned the coherence of the Xforms shortcuts.

Re: Forget Windows

[Stephen Harris]

- Original Message - 
From: "Ingar Pareliussen" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, November 08, 2005 9:00 AM
Subject: Re: Forget Windows


So as a translator I would like to have only one toolset to work with, and 
if

I could have chosen I would loved a kde-frontend. There is so many things we
could have gotten for free if we would made the plunge to kde instead of qt.
(on the fly spell check, kio-slaves to name two from the top of my head). 
And

offcourse as kde4 is going to be ported to win32 and osx it could be used on
those architectures as well. ;) (packing work still remains, though)

SH: Hmmm. I like the KDE desktop and looked into the Cygwin port
of KDE to Windows, which has been abandoned. Now the effort is
to produce a native Windows KDE. I thought I read that this effort
relied on Qt (3?) similar to LyX?

Re: Forget Windows

[Gour]

Ingar Pareliussen ([EMAIL PROTECTED]) wrote:

> As a translator I have to say that the number of toolkits increase the amount 
> of work for the translators as well. Different toolsets have different ways 
> to specify shortcuts and each have to be translated manually.

Good point.

> 
> So as a translator I would like to have only one toolset to work with, and if 
> I could have chosen I would loved a kde-frontend. There is so many things we 
> could have gotten for free if we would made the plunge to kde instead of qt. 
> (on the fly spell check, kio-slaves to name two from the top of my head). And 
> offcourse as kde4 is going to be ported to win32 and osx it could be used on 
> those architectures as well. ;) (packing work still remains, though)

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...

> However, I can see why it is not going to happen as it would mean ripping out 
> parts of lyx`s tookit independent parts and replacing them with kdelibs. So I 
> am happy with the status quo.

This I cannot comment, i.e. what is the work of tailoring the present
api to new layer.

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Jean-Marc Lasgouttes]

> "Ingar" == Ingar Pareliussen <[EMAIL PROTECTED]> writes:

Ingar> As a translator I have to say that the number of toolkits
Ingar> increase the amount of work for the translators as well.
Ingar> Different toolsets have different ways to specify shortcuts and
Ingar> each have to be translated manually.

Note we could make an effort to change this: use the &shortcut
notation everywhere and avoid gratuitous differences between
frontends.

JMarc

Re: Forget Windows

[Angus Leeming]

William F. Adams wrote:
>> I think we'd all like to see improved core functionality in future
>> releases. The last three or four years have seen increased
>> prettiness and stability and *much* nicer code but little real
>> increase in what LyX can actually do. Now that we have something
>> that's at least reasonably modern looking, let's turn the thing
>> into the world beater we always hoped it would be.

> While I sympathize here, doing a Cocoa / GNUstep front-end really
> provides a lot of nice capabilities ``for free'' 

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 define the dialog structure.

For those interested in such stats, the whole LyX source tree
(neglecting non-Qt frontend code) comprises 970 files and 170,000
lines of code. The thing is *big* and doesn't need to get any bigger.

> In particular, it'd jump-start native UTF-8 support.


Most modern toolkits have unicode support. So what? The Qt frontend
has native unicode support and works today.


Swiching the LyX internals over to unicode is the "big plan" for a 1.5
release. The fun will come in getting unicode to fit seemlessly with
LaTeX. You're something of a LaTeX expert, no? I'm sure you could
point out some of the problems. (To the lyx-devel list please.)

Regards,
Angus

Re: Forget Windows

[Gour]

Lars Gullik Bjønnes ([EMAIL PROTECTED]) wrote:

> Note that code share is in the very high 90's %. 

Really?

Did not know that.

So, it means that, in case qt goes non-gpl or something, it would not be
too hard to port to another toolkit?

> It is packaging that takes time, and you won't get that from just
> using a multi-platform lib. (qt-linux, qt-mac, qt-win)

Do you mean preparing the build or extra stuff which has to be included
like in win32 port?

> But I guess topic should be brought back to more LyX relevant musings.

Isn't the future and LyX ports very relevant topic ;)


Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Ingar Pareliussen]

Tysdag 8. november 2005 15:57 skreiv Lars Gullik Bjønnes:
> Gour <[EMAIL PROTECTED]> writes:
> | Yes, there is code-share, but every individial port (win32, gtk) takes
> | away the energy & time of devs, and that's why I'd prefer to e.g. have
> | gtk port which could (if) cover Win32, Linux-like OS-es & MaC OS in one
> | stroke.
>
> Note that code share is in the very high 90's %. It is packaging that
> takes time, and you won't get that from just using a multi-platform
> lib. (qt-linux, qt-mac, qt-win)

As a translator I have to say that the number of toolkits increase the amount 
of work for the translators as well. Different toolsets have different ways 
to specify shortcuts and each have to be translated manually.

So as a translator I would like to have only one toolset to work with, and if 
I could have chosen I would loved a kde-frontend. There is so many things we 
could have gotten for free if we would made the plunge to kde instead of qt. 
(on the fly spell check, kio-slaves to name two from the top of my head). And 
offcourse as kde4 is going to be ported to win32 and osx it could be used on 
those architectures as well. ;) (packing work still remains, though)

However, I can see why it is not going to happen as it would mean ripping out  
parts of lyx`s tookit independent parts and replacing them with kdelibs. So I 
am happy with the status quo.

Ingar

Re: Forget Windows

[William F. Adams]

On Nov 8, 2005, at 10:07 AM, Angus Leeming wrote:


However, before any eager soul jumps on this frontend bandwagon, I'd
like to introduce a note of caution and suggest that you really,
really shouldn't create yet another frontend to LyX. Time is limited,
there are only so many of us and another frontend would just be more
to maintain for no real benefit.

I think we'd all like to see improved core functionality in future
releases. The last three or four years have seen increased prettiness
and stability and *much* nicer code but little real increase in what
LyX can actually do. Now that we have something that's at least
reasonably modern looking, let's turn the thing into the world beater
we always hoped it would be.


While I sympathize here, doing a Cocoa / GNUstep front-end really 
provides a lot of nice capabilities ``for free'' (Services!) and 
provides one with a nice version for Mac OS X and Linux and possibly 
Windows depending on the state of the mgstep libraries, and I believe 
there's even a Zaurus port.


In particular, it'd jump-start native UTF-8 support.

William

--
William Adams, publishing specialist
voice - 717-731-6707 | Fax - 717-731-6708
www.atlis.com

Re: Forget Windows

[Angus Leeming]

Stephen Harris wrote:
> Yes, I looked at fltk and it is intended to be cross-platform.
> I've also seen some great screenshots and fltk was used for
> (and a variation is used for making special effects in movies)
> porting flpsed using Minsys rather than Cygwin on Windows.
> The result was as good as the original on Linux. I know very
> little about the other approaches, so I'm not comparing to GTK+

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,
really shouldn't create yet another frontend to LyX. Time is limited,
there are only so many of us and another frontend would just be more
to maintain for no real benefit.

I think we'd all like to see improved core functionality in future
releases. The last three or four years have seen increased prettiness
and stability and *much* nicer code but little real increase in what
LyX can actually do. Now that we have something that's at least
reasonably modern looking, let's turn the thing into the world beater
we always hoped it would be.

Regards,
Angus

Please don't (was Re: Forget Windows)

[William F. Adams]

While I agree w/ Marc in wanting a Cocoa / GNUstep front-end for LyX, I 
would like to echo the statements of Banibrata and others that it's 
better to have a wide variety, and please don't abandon people who need 
to use Windows for one reason or other.


Having Windows as an option makes LyX far more widely available, and 
more usage means more testing which makes LyX better.


It also means that LyX can run on systems with unique capabilities not 
afforded by Linux or Mac OS X --- I'm running LyX on Windows 2000 using 
Evernote's RitePen HWR software on a Fujitsu Stylistic pen slate, which 
means that I can work on my current book project wherever I happen to 
be, no need for a chair to sit on to use a laptop, or a table for a 
setting up a keyboardkeyboard, or a power outlet to drive a Wacom 
Cintiq connected to a Mac Mini (which I've still been tempted by).


While Inkwell, nee Rosetta in Mac OS X is nice, it's not as well 
integrated as RitePen, and there's still no widely available HWR 
program for Linux better than xscribble AFAIK.


For others who have Windows pen slates, or access to a graphics tablet, 
be sure to try out InftyReader (http://www.inftyproject.org/en/) 
contrast it w/ FFES on Linux.


William
(which reminds me, can I get the math area slightly increased in size?)
--
William Adams, publishing specialist
voice - 717-731-6707 | Fax - 717-731-6708
www.atlis.com

Re: Forget Windows

[Lars Gullik Bjønnes]

Gour <[EMAIL PROTECTED]> writes:

| Yes, there is code-share, but every individial port (win32, gtk) takes
| away the energy & time of devs, and that's why I'd prefer to e.g. have
| gtk port which could (if) cover Win32, Linux-like OS-es & MaC OS in one
| stroke.

Note that code share is in the very high 90's %. It is packaging that
takes time, and you won't get that from just using a multi-platform
lib. (qt-linux, qt-mac, qt-win)

But I guess topic should be brought back to more LyX relevant musings.
 
-- 
Lgb

Re: Forget Windows

[Angus Leeming]

John Coppens wrote:
>> | I'd also like to see more focus (especially) on GTK+.
>> 
>> The only way to make that happen is to get someone to do it, or do
>> it yourself. There is not really much developer attention on gtk.
> 
> I subscribed to this list to get LyX info for Linux, not Windoze.
> Lately, way too much of this list has been dedicated to the latter.

Frankly, I don't think that's true. Looking back over the mail list
archive as far as 22 Oct, I see the list of messages below. (Sorted
alphabetically.) Most all of 'em are probelms that aren't specific to
Windows, even if there's a Windows in the title.

> Why not split the list and have m$-related discussions separately?

Because we are all one big LyX community :)

> I'd have a go at the GTK+ version, in which I am also interested,
> but I'll surely need a hand, as I am not an ace programmer. Can
> someone indicate what has to be done?

I think that the definitive answer can best be provided by John Spray
(jcs116 AT york DOT ac DOT uk). Off the top of my head, there are
still a bunch of dialogs that needed to be written and the main
screen is very fragile in the presence of accented letters.

Regards,
Angus

Algorithm [7]
Beamer Compile Error
Can't see my layout environments [3]
Changing the parameters of "minipage"
Chapter with numbering but without word "chapter" - more quest [2]
Chapter* titel problem
Choice of fonts in LaTeX [3]
Creating DocBook stuff using LyX [2]
Custom layout and psmatrix from pstricks, 1.4.0pre2 [4]
Custom titlepage [5]
DPI [4]
Emacs keybindings on Windows? [2]
Faulty Latex generated by LyX ? [4]
Figure and table side by side [6]
Finding the Reason xdvi Output Disappeared [7]
Forcing LyX to retypeset included files? [4]
Forget Windows [15]
Grammar [3]
Grammar check? [3]
Graphics: jpicedt [2]
Help on article(IEEEtran) document class
Horizontal Rule [4]
How to put a box around an equation: is there a bug in Lyx? [3]
How to set latex path on windows? [2]
Installing a layout [2]
Is this possible in lyx? [8]
Is this possible with lyx? [8]
Left \cases [5]
Less spacing in figure captions [4]
LyX and xypic [5]
LyX displaying problem. [2]
Lyx Figure Placement [4]
Lyx on Windows and layout error [3]
MLA style for lyx [2]
Making a LyX environment with arguments [2]
Missing def'n for \implies causes latex problem... [3]
Missing latex classes are causing bugs
Modifying the koma-letter2 lyx template [3]
Need some trouble shootingideas [2]
Newbie question: newline before \and in author environment [5]
No line break after paragraph heading [5]
Pagination problem [5]
Please confirm your message [2]
Preamble code from the layout file gets "double linespacing" [2]
Putting Other Stuff On The Title Page
Some gohst haunting my Lyx
Some wishes [2]
Suggestion
Symbols for a figure key - adding a new font [15]
TeXLive 2005, LyX and Windows xp [8]
Unwanted new paragraph after change to embedded math [2]
Upcoming LyX versions [2]
Updating dvi [6]
User-defined macros outside of math mode [2]
Using Curly Brackets in Text [3]
Using lyx and multibib [3]
Where can I see what lyx is doing in the background when [5]
Windows Lyx-1.3.6: Font problems in headings [4]
[announce] beta release of new LyXWin installer
\columnsep with multicol [3]
\usepackage[dvips]{geometry}: How? [3]
accented words in lyx 1.3.6 and suse 9.3 [4]
add index with its page number to table of contents [3]
all footnotes at end of book [3]
centre a graphic [3]
converter for pdf [3]
data sources [7]
do we have something like #ifdef from C in LyX? [7]
figures blank in pdf in lyx1.3.6 + OSX
itemize/enumerate in theorem environment possible in LyX ? [2]
lyx keyboard shortcuts [3]
lyx-1.4 cvs assertion crash when resetting "wrong" language
lyx-gtk compilation error [4]
mtabular environment in LyX [6]
multiinclude with beamer [3]
period after author in reference list [5]
reference
textclass.lst [6]
unusual contents found?!?!
updating postscript file, but not eepic picture [3]
using natbib with sort&compress [4]
where did my citations go? [2]

Re: Forget Windows

[Banibrata Dutta]

Hi Folks,
 We may try to wish-away windows or maybe flame-it-down, but the fact is
that by saying things like -- "don't spend any more effort on developing it
further on Windows", what you are saying is turn the development into a
prejudiced-OpenSource, not a truely world-hugging OpenSource as OpenSource
is meant to be.
 I agree that win32 developers needs to pitch-in, but all the people who *
use* Lyx on Windows are not Windows-developers (myself included). I use
Windows because my company (a very large multi-national) chooses to use
Windows. You may say that I should try to influence them to move them to
Linux, but I know that it's easier said than done. A very large set of
applications that my company uses, doesn't have robust-enough or
featureful-enough counterparts on Linux.
 Move to Linux can only be gradual, i.e. it needs to be evolutionary and not
an overnight revolution. Just see how the acceptance & popularity of Linux
has grown over the years, and believe me, it has a lot to do with how easy
it was made for Windows user to move to Linux. If you don't do that, Linux
remains a domain of the so-called "nerds".
 I'd rather see the members of this list help, support and encourage Lyx
users without trying to judge them based on which OS they run Lyx. Living
with the prejudice "Bill Gates is Evil, Windoze is Evil", helps nobody.
 BTW, I own 5 PC's (and 4 of them are multi-boot capable). All my PC's run
Linux (but they also run BSD, Solarix x86, WindowsXP). I am a software
programmer by profession (been that for 8yrs now). I use really wish I could
help with win32 development of Lyx, because I use WindowsXP at work, and
find Lyx quite powerful (well I am still a newbie), but unfortunately my
knowledge of GUI programming is next to 0.
 my 2 cents,
bd

Re: Forget Windows

[Stephen Harris]

- Original Message - 
From: "Helge Hafting" <[EMAIL PROTECTED]>

To: "Gour" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, November 08, 2005 5:15 AM
Subject: Re: Forget Windows



Gour wrote:


Marc J. Driftmeyer ([EMAIL PROTECTED]) wrote:

 >>I'd also like to see more focus (especially) on GTK+.
 


Now, if we're making wishes - scratch the bloated gtk and
go for fltk.  Lightweight they way it should be, and it has
nice stuff like unicode and antialiasing anyway.  It probably
won't happen though - lack of manpower as always.

Helge Hafting



Yes, I looked at fltk and it is intended to be cross-platform.
I've also seen some great screenshots and fltk was used for
(and a variation is used for making special effects in movies)
porting flpsed using Minsys rather than Cygwin on Windows.
The result was as good as the original on Linux. I know very
little about the other approaches, so I'm not comparing to GTK+

Regards,
Stephen

Re: Forget Windows

[Gour]

John Coppens ([EMAIL PROTECTED]) wrote:

> I'd have a go at the GTK+ version, in which I am also interested, but
> I'll surely need a hand, as I am not an ace programmer. Can someone
> indicate what has to be done?

As I wrote earlier, I cannot code, but can contribute my time to
testing.

Probably some of core developers can tell you everything, I'll just
point you (if not seen already) to the: http://www.lyx.org/devel/guii.php
where it is shown (I cannot say if it is up to date) what is the status
of GTK+ port.

Maybe the more help can be asked on gtk-related mailing lists.

Sincerely,
Gour



> 
> John

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Gour]

Sven Schreiber ([EMAIL PROTECTED]) wrote:

Hi Sven!

> I don't understand why such a statement results in angry accusations.

I hope you didn't take my argument as a angry accusations, at least it
was not meant to be so, just a slightly provoking statement to backup your
statement :-)

> > People are using LyX/LaTeX for SERIOUS work, not to write 1-page letter,
> > and I don't understand for what you would use LyX if there would not be
> > win32 port?
> 
> What I meant is I would not be able to use Lyx for job-related work,
> or put differently, it would be quite impractical. I would use it at
> home on Linux, but if it weren't cross-platform I would have to use
> something different in the office(s).

That's why I wrote that if you need a tool for a serious work, you can
have a dual-boot setup, launch Linux LiveCD or whatever to do your work
if the boss does not allow non-Win32 OS.

> I simply wanted to back the cross-platform strategy of the Lyx team.
> They (especially Angus) have worked hard for the Windows part, and
> this work deserves admiration. When this thread started I was worried
> about the implicit verdict that all that work was useless or even
> counterproductive. 

In the past I suggested to do wxWidgets port to achieve real
multi-platformability (although, when I think today about it, I'll
choose GTK+ but with Haskell) 'cause, imho, win32 port, xforms, qt, gtk
cannot be considered multi-platform solution.

Yes, there is code-share, but every individial port (win32, gtk) takes
away the energy & time of devs, and that's why I'd prefer to e.g. have
gtk port which could (if) cover Win32, Linux-like OS-es & MaC OS in one
stroke.

However, since I cannot help in coding, I do not want to complain and
whine, but I'm trying to be grateful to LyX devs for everything what
they are doing (I'm with LyX since '99 and my 1st steps on Linux) and
help by some testing, reporting bugs, etc.

My hope is that LyX will atrract some new devs and that some new real
multi-platform port could be done in the future.

> So which is better: Me running Linux and Vmware, with my colleagues staying 
> away from Lyx, or everybody using native Lyx on Windows?

I'd say: better for you & your colleagues running LyX (on Linux) and
vmware - it will bring new users to both Linux & LyX :-)

Then, with more users on Linux desktop, more programmers will be interested to
program for Linux, more companies will give financial support by paying
some programmers to do full-time job on the open-source applications and
in the end the whole community will benefit.

There is another catch with Qt (have you read the recent decision of
Novell standardizing on GNOME desktop?) but I won't delve into it
producing more flame ;)

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Gour]

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? 

> Now, if we're making wishes - scratch the bloated gtk and
> go for fltk.  Lightweight they way it should be, and it has
> nice stuff like unicode and antialiasing anyway.  

I just moved kde --> gnome and do not understand what would be the
advantage of fltk over gtk and/or Qt?

Multi-platform?

I was thinking about that in the time when I proposed wxWidgets as a one
multi-platform kit, but today I'm more for GTK+.

However, I also understand that we won't see GTK and/or GNOME port soon,
but nobody can prevent me dreaming :-)

> It probably won't happen though - lack of manpower as always.

Well, we can still express wishes and maybe some soul(s) jump in to make
a GNOME port. Many GNOME libs are available for Mac OS and arriving for
Win32 (for those still needing that OS :-)

Sincerely,
Gour

p.s. Unfortunately, my time-for-contributing-to-the-open-source-community is
already slotted (e.g. gtk2hs) and I do not posess skill for coding in
C++ (trying to learn Haskell for other stuff).

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[John Coppens]

On 08 Nov 2005 13:19:46 +0100
[EMAIL PROTECTED] (Lars Gullik Bjønnes) wrote:

> Gour <[EMAIL PROTECTED]> writes:
> 
> | I'd also like to see more focus (especially) on GTK+.
> 
> The only way to make that happen is to get someone to do it, or do it
> yourself. There is not really much developer attention on gtk.

I subscribed to this list to get LyX info for Linux, not Windoze. Lately,
way too much of this list has been dedicated to the latter. Why not split
the list and have m$-related discussions separately?

I'd have a go at the GTK+ version, in which I am also interested, but
I'll surely need a hand, as I am not an ace programmer. Can someone
indicate what has to be done?

John

Re: Forget Windows

[Sven Schreiber]

Before this develops into a flamewar, let me rectify something:

I *like* Linux more than I like Windows, but that doesn't change the fact that 
some very specialized
apps simply don't exist on *nix. I'm very glad though that many open-source 
apps are cross-platform
so that I can work with them. This holds especially for Lyx, and by having said 
that I prefer Lyx
over a legal Scientific Word it should be clear that I think Lyx is better 
overall. I don't
understand why such a statement results in angry accusations.

> People are using LyX/LaTeX for SERIOUS work, not to write 1-page letter,
> and I don't understand for what you would use LyX if there would not be
> win32 port?

What I meant is I would not be able to use Lyx for job-related work, or put 
differently, it would be
quite impractical. I would use it at home on Linux, but if it weren't 
cross-platform I would have to
use something different in the office(s).

I simply wanted to back the cross-platform strategy of the Lyx team. They 
(especially Angus) have
worked hard for the Windows part, and this work deserves admiration. When this 
thread started I was
worried about the implicit verdict that all that work was useless or even 
counterproductive. The
opposite is true: There is a real chance I get many of my colleagues to use Lyx 
and thus to ditch
proprietary apps. But only if it runs on Windows, that's the reality for now, 
even if I (or you)
don't like it. So which is better: Me running Linux and Vmware, with my 
colleagues staying away from
Lyx, or everybody using native Lyx on Windows?

cheers,
sven

Re: Forget Windows

[Helge Hafting]

Gour wrote:


Marc J. Driftmeyer ([EMAIL PROTECTED]) wrote:

 

So if I read this correctly, because a Win32 port of LyX has been  
made possible to show the Windows User the Power of the UNIX/Linux  
World Design approach to Software and what Free Tools can produce  
using the TeX/LaTeX systems and their many prodigy as the guts  
underneath the highly abstracted WYSIWYM paradigm none of that  
matters and it's because of this Win32 option that you consider it  
for serious work?  Never mind the fact that it is more rock solid on  
its primary platforms and that countless Scientists, Engineers,  
Writers, Publishers use the these tools for serious work, it's  
because of the Win32 port it is now to be considered a serious solution?
   



Huh, this is a real point!
 


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.


I'd also like to see more focus (especially) on GTK+.
 


Now, if we're making wishes - scratch the bloated gtk and
go for fltk.  Lightweight they way it should be, and it has
nice stuff like unicode and antialiasing anyway.  It probably
won't happen though - lack of manpower as always.

Helge Hafting

Re: Forget Windows

[Lars Gullik Bjønnes]

Gour <[EMAIL PROTECTED]> writes:

| I'd also like to see more focus (especially) on GTK+.

The only way to make that happen is to get someone to do it, or do it
yourself. There is not really much developer attention on gtk.

-- 
Lgb

Re: Forget Windows

[Gour]

Sven Schreiber ([EMAIL PROTECTED]) wrote:

> There is no way that they switch OS because we need some specialized
> apps that only run under Windows. (Please don't reply with hints on
> wine, qemu, etc., I've tried it all.) 

What app you have that don't run under vmware?

> Bottom line: If Angus (and Ruurd before him) hadn't developed Lyx for 
> Windows,> I still would use Linux to some extent, but not for Lyx: I would 
> NOT use Lyx 
> for serious work. (Instead I would probably use Scientific Word for
> which btw I have a valid license and still prefer Lyx.)

How this one can hold water...

What is the logic to "...use Linux to some extent, but not for Lyx...", and
use LyX for win32 ?

People are using LyX/LaTeX for SERIOUS work, not to write 1-page letter,
and I don't understand for what you would use LyX if there would not be
win32 port?

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Gour]

Marc J. Driftmeyer ([EMAIL PROTECTED]) wrote:

> So if I read this correctly, because a Win32 port of LyX has been  
> made possible to show the Windows User the Power of the UNIX/Linux  
> World Design approach to Software and what Free Tools can produce  
> using the TeX/LaTeX systems and their many prodigy as the guts  
> underneath the highly abstracted WYSIWYM paradigm none of that  
> matters and it's because of this Win32 option that you consider it  
> for serious work?  Never mind the fact that it is more rock solid on  
> its primary platforms and that countless Scientists, Engineers,  
> Writers, Publishers use the these tools for serious work, it's  
> because of the Win32 port it is now to be considered a serious solution?

Huh, this is a real point!

> Personally, I'd say screw the Win32, focus on the X, GTK+ and Qt  
> ports and let the rest of the world smile with pleasure knowing they  
> actually produce the highest standards of publishing with such tools  
> the likes of which Springer Verlag, Addison-Wesley, Prentice Hall, so  
> on and so forth are more than happy to have in order to make their  
> jobs as publishing houses easier.

I'd also like to see more focus (especially) on GTK+.

> To all those that have developed this software your efforts have not  
> gone in vain as by the tens of thousands of email posts in this  
> mailing list should be proof enough.

I tried with XML technology, but I'm back to LyX/LaTeX not wanting to
look elsewhere.

Sincerely,
Gour

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Marc J. Driftmeyer]

Okay now what you just said spits on the entire *nix community.

I myself use LyX less than I do LaTeX with Kile on Debian [don't get  
me started with the transition LyX is having with the Debian upgrades  
after Sarge] and I use LyX for OS X and TeXShop for OS X.


This particular section is what caught my attention:

Bottom line: If Angus (and Ruurd before him) hadn't developed Lyx  
for Windows, I still would use
Linux to some extent, but not for Lyx: I would NOT use Lyx for  
serious work. (Instead I would
probably use Scientific Word for which btw I have a valid license  
and still prefer Lyx.)





So if I read this correctly, because a Win32 port of LyX has been  
made possible to show the Windows User the Power of the UNIX/Linux  
World Design approach to Software and what Free Tools can produce  
using the TeX/LaTeX systems and their many prodigy as the guts  
underneath the highly abstracted WYSIWYM paradigm none of that  
matters and it's because of this Win32 option that you consider it  
for serious work?  Never mind the fact that it is more rock solid on  
its primary platforms and that countless Scientists, Engineers,  
Writers, Publishers use the these tools for serious work, it's  
because of the Win32 port it is now to be considered a serious solution?


Please stop using LyX and any of these amateur tools already. By all  
means utilize that license and slave away at your Scientific Word.   
You're damn lucky they ported the app in the first place.


Personally, I'd say screw the Win32, focus on the X, GTK+ and Qt  
ports and let the rest of the world smile with pleasure knowing they  
actually produce the highest standards of publishing with such tools  
the likes of which Springer Verlag, Addison-Wesley, Prentice Hall, so  
on and so forth are more than happy to have in order to make their  
jobs as publishing houses easier.


If you're going to do another port I would love to see the GNUstep  
folks make a Cocoa Port to leverage CoreData, Foundation and full  
AppKit in OS X.  Perhaps my colors bleed NeXT having worked there a  
bit too much but one can dream.


When 1.4 comes out I look forward to seeing it.  For now I've become  
quite accustomed to Kile and using LaTeX directly : it's a nice new  
skill to add to my ever growing list.  I have no problem writing  
certain types of works in LyX and other types using a LaTeX editor.


To all those that have developed this software your efforts have not  
gone in vain as by the tens of thousands of email posts in this  
mailing list should be proof enough.


- Marc


Marc J. Driftmeyer
[EMAIL PROTECTED]
http://www.reanimality.com
"Infinite Nothingness is the Limit of Being" -- marc j. driftmeyer


On Nov 8, 2005, at 1:20 AM, Sven Schreiber wrote:


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 switching to a version of  
Linux,
where they really should be. Feeding software to Windows just lets  
it grow

profits for people who are doing nothing positive for the computing
community.



I use and try to spread the use of Lyx on Windows. My colleagues  
are likely to adopt it once 1.4 is
out with working latex import. There is no way that they switch OS  
because we need some specialized
apps that only run under Windows. (Please don't reply with hints on  
wine, qemu, etc., I've tried it
all.) Similar for me: I came from the Mac, have used Linux (and  
like it), and use Windows because I
must. Almost everything I work with is open source, except one or  
two show-stoppers. (Please don't

reply I should port/replicate the apps myself, I can't.)

Bottom line: If Angus (and Ruurd before him) hadn't developed Lyx  
for Windows, I still would use
Linux to some extent, but not for Lyx: I would NOT use Lyx for  
serious work. (Instead I would
probably use Scientific Word for which btw I have a valid license  
and still prefer Lyx.)


-Sven

Re: Forget Windows

[Gour]

Lars Gullik Bjønnes ([EMAIL PROTECTED]) wrote:

> Well depends on the effort needed to make it happen... and since
> we are in the Open Source world it is really is the community on the
> operating systems in question that should to the work to make it
> happen. 

I agree. 

LyX is developed on non-Win32 OS, so if Win32 community wants it, let
them help with the effort and save the time of the core devs for
enhancing native application.

With every day, there are less & less reasons to not switch from Win32,
and LyX being one of those 'killer-app' is a good reason to try
alternative OS.

There are lot of Linux users who still need some Win32 application and
therefore they either keep dual-boot setup or use some emulation software
(Win4lin, vmware, wine, CrossOver Office...), so Win32 users (if they
want ot stay) can deploy the similar strategy (e.g. vmware) or simply use some
Linux Live CD, but let not the effort of developing LyX get dispersed by
attempt to support Win32 version.


Sincerely,
Gour (utf8 user, anxious to see 1.4 happen so that Unicode-support can start :-)

-- 
Registered Linux User   | #278493
GPG Public Key  | 8C44EDCD
 

Re: Forget Windows

[Sven Schreiber]

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 switching to a version of Linux, 
> where they really should be. Feeding software to Windows just lets it grow 
> profits for people who are doing nothing positive for the computing 
> community.
> 

I use and try to spread the use of Lyx on Windows. My colleagues are likely to 
adopt it once 1.4 is
out with working latex import. There is no way that they switch OS because we 
need some specialized
apps that only run under Windows. (Please don't reply with hints on wine, qemu, 
etc., I've tried it
all.) Similar for me: I came from the Mac, have used Linux (and like it), and 
use Windows because I
must. Almost everything I work with is open source, except one or two 
show-stoppers. (Please don't
reply I should port/replicate the apps myself, I can't.)

Bottom line: If Angus (and Ruurd before him) hadn't developed Lyx for Windows, 
I still would use
Linux to some extent, but not for Lyx: I would NOT use Lyx for serious work. 
(Instead I would
probably use Scientific Word for which btw I have a valid license and still 
prefer Lyx.)

-Sven

Re: Forget Windows

[Paul Smith]

On 11/6/05, James W Dow <[EMAIL PROTECTED]> wrote:
> 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 switching to a version of Linux,
> where they really should be. Feeding software to Windows just lets it grow
> profits for people who are doing nothing positive for the computing
> community.

James,

I have an opposite view. I migrated to Linux at the moment I realized
that all software I was using (with MS Windows) was natively developed
for Linux. Thus, to have LyX and other (natively Linux) programs
available for MS Windows may help with conquering new users for Linux.

Paul

Re: Forget Windows

[Lars Gullik Bjønnes]

Gunnar <[EMAIL PROTECTED]> writes:

| On Sunday 06 November 2005 22:05, James W Dow wrote:
| > 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 switching to a version of
| > Linux, where they really should be. Feeding software to Windows just lets
| > it grow profits for people who are doing nothing positive for the computing
| > community.
| 
| You are wrong on two points.
| 
| 1) The operating system should not be of any importance (in a perfect world), 
| applications is what the people need! 
| They need LyX, give them LyX! 

Well depends on the effort needed to make it happen... and since
we are in the Open Source world it is really is the community on the
operating systems in question that should to the work to make it
happen. Angus has (IMHO) bent over backwards to make this windows port
happen (really integrated with the rest of the source base, installer
etc.), now it is time for the Windows community of LyX users to pick
this up at keep it up do date and working.

-- 
Lgb

Re: Forget Windows

[Gunnar]

On Sunday 06 November 2005 22:05, James W Dow wrote:
> 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 switching to a version of
> Linux, where they really should be. Feeding software to Windows just lets
> it grow profits for people who are doing nothing positive for the computing
> community.

You are wrong on two points.

1) The operating system should not be of any importance (in a perfect world), 
applications is what the people need! 
They need LyX, give them LyX! 
People (the computer illiterate?) are not going to switch OS until the OS's 
are so good that you never have to "interact" with the OS. Then why should 
you pay for it when there are free ones?

2) It's not a word processor. It's the best application ever created. That's a 
huge difference. ;-)

Forget Windows

[James W Dow]

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 switching to a version of Linux, 
where they really should be. Feeding software to Windows just lets it grow 
profits for people who are doing nothing positive for the computing 
community.