> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> It compiles on cygwin provided that the anon namespace is
Enrico> moved ahead of os::init().
Enrico> Please, find attached an updated patch.
Thanks this is in branch and trunk now.
JMarc
Please, find attached an updated patch.
Confirmed win/mingw/qt4. JMarc's patch does not work, Enrico's updated
one does. Now I have correct number of menu items, when I uninstall
gsview, view->ps disappears.
Cheers,
Bo
On Wed, May 17, 2006 at 02:24:44AM +0200, Enrico Forestieri wrote:
> On Tue, May 16, 2006 at 04:58:01PM -0500, Bo Peng wrote:
>
> > >Now, if I only could discover why that damn'd acrobat5 is used...
> >
> > We are all curious. :-)
>
> Something bad happened to my win2k. When I double click on a
On Wed, May 17, 2006 at 12:47:52AM +0200, Jean-Marc Lasgouttes wrote:
> It would be too easy :) Here is the new version that move this stuff
> to os::. I think I like it, but I have no idea whether it compiles on
> win32 and cygwin :)
It compiles on cygwin provided that the anon namespace is move
On Tue, May 16, 2006 at 04:58:01PM -0500, Bo Peng wrote:
> >Now, if I only could discover why that damn'd acrobat5 is used...
>
> We are all curious. :-)
Something bad happened to my win2k. When I double click on a pdf file
or use start on it, AcroRd32.exe version 7 is used. But when I check
the
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> > If your claim is right, then I have no concern.
>>
>> Yes, I tested it.
Bo> Then, the patch is perfect for me (subject to the acrobat 5/7
Bo> mystery), and ready to submit.
It would be too easy :) Here is the new version that move this stuf
On Wed, May 17, 2006 at 12:13:31AM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> >> However I cannot see (yet) a case where it will cause a problem.
> >> The case would be like 1) there is no official PDF viewer and 2)
> >> xpdf.exe is a p
> If your claim is right, then I have no concern.
Yes, I tested it.
Then, the patch is perfect for me (subject to the acrobat 5/7
mystery), and ready to submit.
Bo
On Tue, May 16, 2006 at 04:58:01PM -0500, Bo Peng wrote:
> >No need to do anything more than what JMarc did. Even if an executable
> >is picked by configure.py it will be masked by the one associated with
> >that format.
>
> Are you sure about this? I need to re-read the patch then. My
> understan
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>> However I cannot see (yet) a case where it will cause a problem.
>> The case would be like 1) there is no official PDF viewer and 2)
>> xpdf.exe is a program that reformats the harddrive.
Enrico> You went very near it. Guess what
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Are you sure about this?
Personnally I am.
Bo> I need to re-read the patch then.
It may be that the logic is wrong. But it was my intent anyway.
JMarc
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> The problem is also that you may miss the correctly associated
Bo> viewer (like acrobat reader, which does not change $PATH), because
Bo> of an indecent viewer.
Let me repeat again: if there is a correctly associated viewer, any
autodetected i
On Tue, May 16, 2006 at 10:06:55PM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
> Enrico> Using your patch nothing is set to auto in lyxrc.defaults. In
> Enrico> the PDF entries I find "acroread" which is a shell script
> Enrico> calling acro
No need to do anything more than what JMarc did. Even if an executable
is picked by configure.py it will be masked by the one associated with
that format.
Are you sure about this? I need to re-read the patch then. My
understanding is that if an application is picked by configure.py, it
will not
On Tue, May 16, 2006 at 11:12:15PM +0200, Jean-Marc Lasgouttes wrote:
> > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>
> >> Why is that? If you have nothing else associated to pdf anyway, it
> >> is better than nothing. I really do not understand your concern.
>
> Bo> Any decent windows view
On Tue, May 16, 2006 at 04:23:11PM -0500, Bo Peng wrote:
> >So you mean that, if there is no default viewer, you'd rather tell the
> >user that he cannot see the file, than display it with an undecent
> >viewer?
>
> A native windows application will do that.
>
> The problem is also that you may m
So you mean that, if there is no default viewer, you'd rather tell the
user that he cannot see the file, than display it with an undecent
viewer?
A native windows application will do that.
The problem is also that you may miss the correctly associated viewer
(like acrobat reader, which does not
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Why is that? If you have nothing else associated to pdf anyway, it
>> is better than nothing. I really do not understand your concern.
Bo> Any decent windows viewer will associate itself with the format.
Bo> But the problem is that xpdf.exe may
Why is that? If you have nothing else associated to pdf anyway, it is
better than nothing. I really do not understand your concern.
Any decent windows viewer will associate itself with the format. But
the problem is that xpdf.exe may not be the only one, or the default
one to link with pdf, even
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> If xpdf.exe is in the $PATH, but not associated with pdf, we *do
Bo> not* want it.
Why is that? If you have nothing else associated to pdf anyway, it is
better than nothing. I really do not understand your concern.
Again, if something is ass
Bo> Minor concern: what if someone installs xpdf.exe? (is there such a
Bo> port?). xpdf will be set as view, instead of none.
If PDF is handled natively by windows, viewer will be set to "auto".
Otherwise, if it "none", it is reset to "". If it was autodetected
like "xpdf", this value is kept.
S
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>> This is very strange, I am not sure why the behaviour could be
>> different. Do you have one of the acrobat versions on your PATH?
Enrico> None of them is in the PATH.
>> Also, are the viewer and editor for PDF set to auto?
Enr
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> 1. configure.py get rid of win32 viewer names, but applications
Bo> are still searched and 'none' will be returned. Minor concern:
Bo> this slows down configure.py under windows.
I am not too concerned about this one.
Bo> Minor concern: what
OK, here is what I had in mind. The fixCommand helper looks a bit long
but this makes its intent clear I think.
I have a few questions (observations) about the patch:
1. configure.py get rid of win32 viewer names, but applications are
still searched and 'none' will be returned.
Minor concern:
On Tue, May 16, 2006 at 04:45:11PM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> I would say it almost works, as it doesn't peek the correct
> Enrico> viewer for pdf files. I have both acrobat 5 and acroread 7 and
> Enrico> the la
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Sigh. I don't want to undo anything, I only wanted to please
Georg> Bo. Now we have a different situation again and, and I'll wait
Georg> for you to commit.
OK, so if the patches do not interfere and if no new problems are
found, I'll
Jean-Marc Lasgouttes wrote:
> Are we sure that the last patch does not do what Bo wanted? I think it
> makes more sense to separate the patches, unless your plan is to undo
> some of the changes in my patch.
Sigh. I don't want to undo anything, I only wanted to please Bo. Now we have
a different
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I would say it almost works, as it doesn't peek the correct
Enrico> viewer for pdf files. I have both acrobat 5 and acroread 7 and
Enrico> the last is that associated with pdf files.
Enrico> I don't know what is happening, pe
Jean-Marc Lasgouttes wrote:
> That would be OK indeed. Now, who is doing it? :)
I nobody beats me to it I'll do it, but not before Thursday.
Georg
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I don't know why you seem to be so upset about the pollution
Enrico> of os.h. After all those declarations are #ifdef'd out for
Enrico> platforms different from cygwin.
Upset is not the word. The whole purpose of os.[Ch] was
On Tue, May 16, 2006 at 09:16:26AM -0500, Bo Peng wrote:
> Patch confirms to work under win/mingw. Reading the patch now.
I would say it almost works, as it doesn't peek the correct viewer
for pdf files. I have both acrobat 5 and acroread 7 and the last
is that associated with pdf files.
I don't
On Tue, May 16, 2006 at 04:11:32PM +0200, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> Jean-Marc Lasgouttes wrote:
> >> This is indeed a possibility. The only problem I see is that OSX
> >> uses os_unix.C. Where would you implement autoOpenFile?
Patch confirms to work under win/mingw. Reading the patch now.
Bo
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>> This is indeed a possibility. The only problem I see is that OSX
>> uses os_unix.C. Where would you implement autoOpenFile?
Georg> Using #ifdef in os_unix.C. I don't see why this should be worse
Georg> t
Jean-Marc Lasgouttes wrote:
> This is indeed a possibility. The only problem I see is that OSX uses
> os_unix.C. Where would you implement autoOpenFile?
Using #ifdef in os_unix.C. I don't see why this should be worse than #ifdef
in filetools.C. If os_unix.C becomes too cluttered with ifdefs we co
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Bo Peng wrote:
>> Since JMarc's version of the patch does not solve every problem, I
>> would prefer waiting for your patch and test them together. This
>> should not cause you any trouble since your patch can be
>> developed/tested in
Bo Peng wrote:
> Since JMarc's version of the patch does not solve every problem, I
> would prefer waiting for your patch and test them together. This
> should not cause you any trouble since your patch can be
> developed/tested independent of this one.
OK, I will present a combined one, probably
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> I think it does. We have basicaly two groups of formats:
> Georg> Document formats (like tex, ps, dvi, pdf, ooffice etc) and
> Georg> image formats (xpm, bmp, png etc). Some formats (pdf
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> However, this pure windows path is only needed on windows, so
Georg> with some code reorganization all is well: Move autoOpenFile()
Georg> and canAutoOpenFile() to os, and provide dummy implementations
Georg> for the other OSes. Then y
Enrico Forestieri wrote:
> On Mon, May 15, 2006 at 11:55:33PM +0200, Jean-Marc Lasgouttes wrote:
>
>> OK, here is what I had in mind. The fixCommand helper looks a bit long
>> but this makes its intent clear I think.
>>
> I think that Windows remembers previous associations in the registry,
> so
On Mon, May 15, 2006 at 11:55:33PM +0200, Jean-Marc Lasgouttes wrote:
> OK, here is what I had in mind. The fixCommand helper looks a bit long
> but this makes its intent clear I think.
>
> How does this fare in windows?
I tested it on cygwin. I only have what I expect to see in the View menu
an
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> That is the plan. I'll send a patch, and we'll see whether
Jean-Marc> it works.
OK, here is what I had in mind. The fixCommand helper looks a bit long
but this makes its intent clear I think.
How does this fare in w
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> And "auto" should be set for _all_ platforms when we did not
>> succeed to find a viewer. This auto value will be ignored when it
>> does not make sense.
Bo> Then you would like to differentiate between "" and "auto" for
Bo> other platforms as
Bo> Currently, "should not be viewed" is denoted by "" (or possibly
Bo> none), which is *not* os dependent.
It is not "should not be viewed", it is "I did not find a viewer and I
am not under windows".
I am not quite sure, but my understanding is that for many formats
(like the image one), it i
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Another possibility would be to have a special value like "never"
>> or "noauto" for the viewer meaning we should not make it viewable
>> even if the OS claims it can do it.
Bo> "" means never, "auto" means ...
>> Bo, one thing I do not like i
Another possibility would be to have a special value like "never" or
"noauto" for the viewer meaning we should not make it viewable even if
the OS claims it can do it.
"" means never, "auto" means ...
Bo, one thing I do not like in your "auto" approach is that it is
system-dependent. The flagg
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> Enrico has seen a long list of unwanted menu items and I guess they
>> are all "viewable"? Your solution does not solve this problem.
Georg> I think it does. We have basicaly two groups of formats:
Georg> Document formats (like tex, ps, d
If that is OK with you I'd suggest that either you or Jean-Marc apply
Jean-Marcs version of the patch, and I'll work from there. We would live
with may view items, but I will have a patch in the next few days (or the
weekend et the latest).
Since JMarc's version of the patch does not solve every
Bo Peng wrote:
> Let me summarize your logic (correct me if I am wrong):
>
> 1. noview: no view anyway (with or without viewer)
> 2. can view: will show up under view if a viewer is available.
Correct.
> Enrico has seen a long list of unwanted menu items and I guess they
> are all "viewable"?
If Enrico marks those formats as noview that will not show up in the menu.
What is wrong with that?
Maybe not.
That property can be set by the user, or the installer.
You see, the noview flag has multiple purposes, and I am not 100% sure
if it is safe to turn it on for all formats *excep
On Monday 15 May 2006 14:43, Bo Peng wrote:
> Enrico has seen a long list of unwanted menu items and I guess they
> are all "viewable"? Your solution does not solve this problem.
If Enrico marks those formats as noview that will not show up in the menu.
What is wrong with that?
That property
Your ooffice example would not require any setting by the user: It would be
listed as viewable format, and when ooffice is installed it will be
detected as autoviewable and show up in the menu.
Let me summarize your logic (correct me if I am wrong):
1. noview: no view anyway (with or without vi
Bo Peng wrote:
>> A "" viewer could either mean "don't view this format" or "use the auto
>> viewer". If we make it the latter (as in Jean-Marcs patch) we can use the
>> noview flag that I want to introduce (and that we need anyway to get rid
>> of some hardcoding) to mark those formats that shoul
A "" viewer could either mean "don't view this format" or "use the auto
viewer". If we make it the latter (as in Jean-Marcs patch) we can use the
noview flag that I want to introduce (and that we need anyway to get rid of
some hardcoding) to mark those formats that should not be viewable at all.
I
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> It is the flag thing we already discussed (and I still need to
Georg> merge your comments). That means that the configuration file
Georg> format will change, and that older 1.4.x versions will choke on
Georg> newer configuration files.
Jean-Marc Lasgouttes wrote:
> But is this something that could go in 1.4 too? I'd like to have
> autoopen in there in some way.
It is the flag thing we already discussed (and I still need to merge your
comments). That means that the configuration file format will change, and
that older 1.4.x vers
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> No time (it is still weekend :-) to test the patch. But the exact
Bo> reason for the auto entries is to tell lyx we want autoview for
Bo> certain formats, not for all entries with "" viewer.
OK, I understand that better now. In this case, I th
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Enrico Forestieri wrote:
>> With this patch I get much more entries in the View menu. I even
>> get a "View->Plain text" and a "View->LyX" which launches another
>> instance of LyX on a copy of the current file in tmpdir ;-)
Georg> Ig
Bo Peng wrote:
> No time (it is still weekend :-) to test the patch. But the exact
> reason for the auto entries is to tell lyx we want autoview for
> certain formats, not for all entries with "" viewer.
A "" viewer could either mean "don't view this format" or "use the auto
viewer". If we make i
Enrico Forestieri wrote:
> With this patch I get much more entries in the View menu. I even get
> a "View->Plain text" and a "View->LyX" which launches another instance
> of LyX on a copy of the current file in tmpdir ;-)
Ignore this for now. I have a nice and clean solution for that, but it sort
No time (it is still weekend :-) to test the patch. But the exact
reason for the auto entries is to tell lyx we want autoview for
certain formats, not for all entries with "" viewer.
Cheers,
Bo
On Sun, May 14, 2006 at 10:58:54PM +0200, Jean-Marc Lasgouttes wrote:
> > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>
> >> Why do you need configure.py to set "auto" entries? Isn't it enough
> >> to rely on canOpenFile in LyX itself?
>
> OK, I finally managed to put my finger on why I do n
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Why do you need configure.py to set "auto" entries? Isn't it enough
>> to rely on canOpenFile in LyX itself?
OK, I finally managed to put my finger on why I do not like the
setting of auto in configure.py: first it complicates the code and
more
Hi, JMarc,
As you wish, I have added support for "none". Updated patch is attached.
However, the trunk is totally messed up now in that lyxrc.default can
not be loaded at all, so I can not test. (It compiles OK, and 'auto'
was tested before.
OK to apply?
Bo
Index: src/graph.C
==
Why do you need configure.py to set "auto" entries? Isn't it enough to
rely on canOpenFile in LyX itself?
'' means no menu item, even if a viewer exists (for example, html
viewer without a broken converter should not appear)
'auto' means menu item if a view exists.
'specific viewer' means menu
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Please repost the patch as there are multiple versions from Enrico
>> and you and I don't know which one to apply.
Bo> Attached.
Thanks for the file. I have just one question (you have probably
explained it already, but my skull is thick, so b
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> This is Jean-Marc new stuff AFAIK.
I'll have a look.
JMarc
Bo Peng a écrit :
> So, the lyxrc.defult is OK after initial configuration, then what do
> you see in the preference dialog, do you see auto?
The first time no, the viewer section says "yap" for DVI and is empty
for all other File formats. After a restart (without reconfiguring), the
viewer ed
On Tue, May 02, 2006 at 05:50:27PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes a écrit :
> >Bo Peng a écrit :
> >>>Apparently they won't be set correctly as I need to reconfigure
> >>>after an
> >>>initial startup. See my previous mail.
> >>
> >>That was exactly what puzzled me. I do not h
> So, the lyxrc.defult is OK after initial configuration, then what do
> you see in the preference dialog, do you see auto?
The first time no, the viewer section says "yap" for DVI and is empty
for all other File formats. After a restart (without reconfiguring), the
viewer edit box contains aut
Bo Peng a écrit :
> 3. DO WE SEE auto in $HOME/.lyx/lyxrc.default?
yes I think, there are "auto" "" see attached. Also attached the same
file after reconfigure.
So, the lyxrc.defult is OK after initial configuration, then what do
you see in the preference dialog, do you see auto?
The first tim
> 3. DO WE SEE auto in $HOME/.lyx/lyxrc.default?
yes I think, there are "auto" "" see attached. Also attached the same
file after reconfigure.
So, the lyxrc.defult is OK after initial configuration, then what do
you see in the preference dialog, do you see auto?
If you do see auto, and the men
Abdelrazak Younes a écrit :
Bo Peng a écrit :
Apparently they won't be set correctly as I need to reconfigure
after an
initial startup. See my previous mail.
That was exactly what puzzled me. I do not have a windows machine
here. And I (or you) need to see the result of
1. clear Application
Bo Peng a écrit :
Apparently they won't be set correctly as I need to reconfigure after an
initial startup. See my previous mail.
That was exactly what puzzled me. I do not have a windows machine
here. And I (or you) need to see the result of
1. clear Application Data/lyx
2. start lyx
I've d
Apparently they won't be set correctly as I need to reconfigure after an
initial startup. See my previous mail.
That was exactly what puzzled me. I do not have a windows machine
here. And I (or you) need to see the result of
1. clear Application Data/lyx
2. start lyx
3. DO WE SEE auto in $HOME/
Bo Peng a écrit :
But with a second reconfigure, I have now three PDF (dvipdfm, pdflatek,
ps2pdf) that all work! And I have a new View HTML; but this one doesn't
work because htlatex doesn't understand paths with space and the temp
directory is by default in the "c:/Document and Settings/bla bla
When I delete my user directory (in Application Data) and I restart LyX
from the console, I have the same bad behavior as I described (only DVI
and two PDF that don't work) but I can see at the console that LyX is
being reconfigured at startup. After a tool->Reconfigure, the functional
menus appea
But with a second reconfigure, I have now three PDF (dvipdfm, pdflatek,
ps2pdf) that all work! And I have a new View HTML; but this one doesn't
work because htlatex doesn't understand paths with space and the temp
directory is by default in the "c:/Document and Settings/bla bla bla"
directory. Thi
Abdelrazak Younes a écrit :
Abdelrazak Younes a écrit :
Bo Peng a écrit :
> Please test.
I have not tested it but with svn of three days ago, I have only
View->{DVI, PDF(dvipdfm), PDF{pdflatek)}, PS is not there (used to use
gsview). DVI works OK but both PDF don't (dialog saying "cannot view
Abdelrazak Younes a écrit :
Bo Peng a écrit :
> Please test.
I have not tested it but with svn of three days ago, I have only
View->{DVI, PDF(dvipdfm), PDF{pdflatek)}, PS is not there (used to use
gsview). DVI works OK but both PDF don't (dialog saying "cannot view
file", "No information to vie
I have the exact same behavior with your patch applied to revision 13788
(which contains related changes from JMarc AFAIU).
Please report your lyxrc.default, and I will see what my have gone wrong next.
Bo
Bo Peng a écrit :
> Please test.
I have not tested it but with svn of three days ago, I have only
View->{DVI, PDF(dvipdfm), PDF{pdflatek)}, PS is not there (used to use
gsview). DVI works OK but both PDF don't (dialog saying "cannot view
file", "No information to view PDF"). I have Acrobat Reade
Please repost the patch as there are multiple versions from Enrico and
you and I don't know which one to apply.
Attached.
Bo
Index: src/graph.C
===
--- src/graph.C (revision 13787)
+++ src/graph.C (working copy)
@@ -77,8 +77,9 @@
Bo Peng a écrit :
> Please test.
I have not tested it but with svn of three days ago, I have only
View->{DVI, PDF(dvipdfm), PDF{pdflatek)}, PS is not there (used to use
gsview). DVI works OK but both PDF don't (dialog saying "cannot view
file", "No information to view PDF"). I have Acrobat Reade
> Please test.
I have not tested it but with svn of three days ago, I have only
View->{DVI, PDF(dvipdfm), PDF{pdflatek)}, PS is not there (used to use
gsview). DVI works OK but both PDF don't (dialog saying "cannot view
file", "No information to view PDF"). I have Acrobat Reader 7 installed
and F
Bo Peng a écrit :
I tested this last patch on Cygwin and it does not work well.
Specifically I have to delete /lyxrc.defaults otherwise I
only get "PDF (dvipdfm)" and "PDF (pdflatex)" in the View menu.
I finally have my mingw+lyx+qt4 set up and can test this patch.
Very good, may I asked whic
On Mon, May 01, 2006 at 12:50:22PM -0500, Bo Peng wrote:
> > I understand, but they are exactly the same: only QTDIR changes ;-)
> > please, compare lyconfig-x11 (used for the standalone qt3) and
> > lyxconfig-qt3-x11 (which I wrote for the cygwin qt3).
>
> At least cygwin/qt3 relies on cygwin1.d
I understand, but they are exactly the same: only QTDIR changes ;-)
please, compare lyconfig-x11 (used for the standalone qt3) and
lyxconfig-qt3-x11 (which I wrote for the cygwin qt3).
At least cygwin/qt3 relies on cygwin1.dll, standalone qt3 does not.
I will try your approach after my downgrad
On Mon, May 01, 2006 at 12:25:52PM -0500, Bo Peng wrote:
> > Yes, and I can also test it with my home grown qt3. Why don't you try
> > to build qt3 following http://wiki.lyx.org/LyX/LyXOnCygwin ?
>
> I was afraid of the potential configuration/link differences between
> cygwin/qt3 and standalone
Yes, and I can also test it with my home grown qt3. Why don't you try
to build qt3 following http://wiki.lyx.org/LyX/LyXOnCygwin ?
I was afraid of the potential configuration/link differences between
cygwin/qt3 and standalone qt3.
Then, what you do with this qt3 you simply redo it with the cyg
On Mon, May 01, 2006 at 11:25:54AM -0500, Bo Peng wrote:
> > That won't work as they don't take into account older releases, so the
> > package must work with what is current. I think that we have to wait
> > a new release of the cygwin dll which should be imminent for what I
> > read in their mai
That won't work as they don't take into account older releases, so the
package must work with what is current. I think that we have to wait
a new release of the cygwin dll which should be imminent for what I
read in their mailing list.
I know. But as you may have long noticed, I am not a patient
On Mon, May 01, 2006 at 09:10:09AM -0500, Bo Peng wrote:
> > I have changed again the cygwin part. After thinking about it I moved
> > the code syncing the cygwin and windows environment to os::init,
> > where IMO it belongs.
>
> I hope that this one is the last one for this patch. Otherwise, Lar
I have changed again the cygwin part. After thinking about it I moved
the code syncing the cygwin and windows environment to os::init,
where IMO it belongs.
I hope that this one is the last one for this patch. Otherwise, Lars
(or whoever it may concern) will never look at this patch seriously
an
On Sun, Apr 30, 2006 at 10:20:27PM -0500, Bo Peng wrote:
> >
> > I am returning your patch with a small enhancement to the cygwin part.
>
> Not a problem. I will apply your modifications as well.
I have changed again the cygwin part. After thinking about it I moved
the code syncing the cygwin a
That is probably the homegrown file type recognition in
lyx::support::getFormatFromContents() recognizing OOo files as zip. This
is not surprising since they are indeed zipped, but something has to be
done here.
i do not know much about OO and the conversion processes. I have added
a fs::exists(
Am Montag, 1. Mai 2006 01:57 schrieb Bo Peng:
> I am not sure this is related to this patch. I installed openoffice 2
> and I have the same error message. I then look at the file, it does
> not exist! Instead, I get a directory and two sub folders, with a
> message on the console saying "zip is no
I am returning your patch with a small enhancement to the cygwin part.
Not a problem. I will apply your modifications as well.
Bo
On Sun, Apr 30, 2006 at 07:54:22PM -0500, Bo Peng wrote:
> This is in the attached updated patch. Allow me to reiterate what
> this patch does:
>
> Under windows (including cygwin):
>
> 1. configure.py does not actually search for programs. %% is replaced
> by 'auto'.
>
> 2. A viewer item unde
Although this is unrelated to my patch, I will add a fs::exists check
in view() function to make the error message clearer.
This is in the attached updated patch. Allow me to reiterate what
this patch does:
Under windows (including cygwin):
1. configure.py does not actually search for program
1 - 100 of 116 matches
Mail list logo
