On Fri, Apr 22, 2005 at 08:23:33PM +0200, Juergen Spitzmueller wrote:
> confused nearly everyone. IMO the new ui is much better, though not perfect
> yet (we probably need subdialogs).
Yes, we need a subdialog a la Insert Citation Reference
regards
john
John Levon wrote:
> > By the way, I think the converter dialog is suboptimal UI. To add a
> > converter, I have to select an existing one and edit it, pressing the
> > Add button only at the end of the process. Because of this intuitively
> > backwards approach, the Add button is initially greyed,
> Ok, then could you try the attached patch please.
>
> --
> Angus
>
Yes, this works great. Thank you.
Rob
On Fri, Apr 22, 2005 at 01:57:46PM -0400, Rob Bearman wrote:
> By the way, I think the converter dialog is suboptimal UI. To add a
> converter, I have to select an existing one and edit it, pressing the
> Add button only at the end of the process. Because of this intuitively
> backwards approach,
> > As for the second question, I'm able to define an explicit
> > converter as you specified and the graphic loads correctly. I
> > removed the convertDefault.sh file to make sure I wasn't being
> > fooled that that was being run. Reinstating it, though, and then
> > removing the explicit converte
Rob Bearman wrote:
>> You mentioned earlier that you couldn't run LyX from the console? I
>> wonder why not. Here Start->Run "command", followed by
>> /lyx -dbg graphics,file > lyx.log
>> works perfectly.
>
> What I meant to say is that I can't get debug output displayed to the
> console, or
> You mentioned earlier that you couldn't run LyX from the console? I
> wonder why not. Here Start->Run "command", followed by
> /lyx -dbg graphics,file > lyx.log
> works perfectly.
What I meant to say is that I can't get debug output displayed to the
console, or anywhere else for that matter
Rob Bearman wrote:
>> > As for the second question, I'm able to define an explicit
>> > converter as you specified and the graphic loads correctly. I
>> > removed the convertDefault.sh file to make sure I wasn't being
>> > fooled that that was being run. Reinstating it, though, and then
>> > remov
> Ahhh. Thanks, Jean-Marc. I see that we already have the test
> and that Rob
> merely needs me to modify development/Win32/config.h.
>
> Looks Ok to commit?
>
> --
> Angus
This built fine.
Thanks
Rob
Jean-Marc Lasgouttes wrote:
>>> or make configure check for it and set it in config.h?
>
> Angus> I guess that it is *possible*, but really do we care? How would
> Angus> user code look?
>
> Angus> PID_TYPE foo();
>
> Angus> or would config.h have the typedef?
>
> AC_TYPE_PID_T.
Ahhh. Than
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> Angus Leeming wrote:
>> | Rob Bearman wrote:
With the recent changes to forkedcontr.h and forkedcall.*, I found that
I needed to reinstate the typedef shown below to forkedcall.h and
forkedcontr.h:
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> or make configure check for it and set it in config.h?
Angus> I guess that it is *possible*, but really do we care? How would
Angus> user code look?
Angus> PID_TYPE foo();
Angus> or would config.h have the typedef?
AC_TYPE_PID_T
Lars Gullik Bjønnes wrote:
> Angus Leeming wrote:
> | Rob Bearman wrote:
>>> With the recent changes to forkedcontr.h and forkedcall.*, I found that
>>> I needed to reinstate the typedef shown below to forkedcall.h and
>>> forkedcontr.h:
>>>
>>> #ifdef _WIN32
>>> typedef int pid_t;
>>> #endif
>>
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Rob Bearman wrote:
>
>> With the recent changes to forkedcontr.h and forkedcall.*, I found that
>> I needed to reinstate the typedef shown below to forkedcall.h and
>> forkedcontr.h:
>>
>> #ifdef _WIN32
>> typedef int pid_t;
>> #endif
>
| I think that t
On Friday 22 April 2005 00:18, Rob Bearman wrote:
> > Incidentally, do graphics now load asynchronously onto the
> > LyX screen for you? Ie, given an eps file can you continue
> > doing stuff whilst the graphic inset cyles throgh "loading",
> > "scaling", etc?
> >
> > Also, can you define a graph
> Incidentally, do graphics now load asynchronously onto the
> LyX screen for
> you? Ie, given an eps file can you continue doing stuff
> whilst the graphic
> inset cyles throgh "loading", "scaling", etc?
>
> Also, can you define a graphics converter explicitly? Ie,
> rather than let
> lyx fall
Pardon my obvious ignorance. I'm reading the wiki now on loading images
and I'll give better feedback after I've installed the appropriate
tools.
Thanks
Rob
> Incidentally, do graphics now load asynchronously onto the
> LyX screen for
> you? Ie, given an eps file can you continue doing stuff
> whilst the graphic
> inset cyles throgh "loading", "scaling", etc?
>
> Also, can you define a graphics converter explicitly? Ie,
> rather than let
> lyx fall
> I think that this one is fine, although it should become
>
> #if defined (_WIN32) && defined(_MSC_VER)
Yes, this continues to work for me.
> Well, given that the idea is eventually to remove this file entirely,
> perhaps you'll first see whether this cures the problem:
>
> - int const t
Angus Leeming wrote:
> Rob Bearman wrote:
>
>> With the recent changes to forkedcontr.h and forkedcall.*, I found that
>> I needed to reinstate the typedef shown below to forkedcall.h and
>> forkedcontr.h:
Incidentally, do graphics now load asynchronously onto the LyX screen for
you? Ie, given a
Rob Bearman wrote:
> With the recent changes to forkedcontr.h and forkedcall.*, I found that
> I needed to reinstate the typedef shown below to forkedcall.h and
> forkedcontr.h:
>
> #ifdef _WIN32
> typedef int pid_t;
> #endif
I think that this one is fine, although it should become
#if defined
With the recent changes to forkedcontr.h and forkedcall.*, I found that
I needed to reinstate the typedef shown below to forkedcall.h and
forkedcontr.h:
#ifdef _WIN32
typedef int pid_t;
#endif
I also needed to reinstate the #include "os_win32.h" to forkedcall.C,
which I think is necessary to hand
22 matches
Mail list logo
