Re: No more slush state.
On Wednesday 23 January 2002 8:05 am, Martin Vermeer wrote: On Wed, Jan 23, 2002 at 08:15:00AM +0100, Andre Poenitz wrote: On Tue, Jan 22, 2002 at 10:46:14PM +0200, Martin Vermeer wrote: What's wrong is that the math panel opens up bang on top of the *formula* you're working on. So why don't you simply move it by a fixed amount into some 'safe' direction? Or open it always over the top right corner of the main LyX window or something similar? Ah: 2. Program the math panel to appear elsewhere, not covering the formula. I have to find out what policies are actually available. This might benefit tabular too. Andre' I am about to find the solution. See patch. With thanks to everybody ;-) If this is a preference thing (and to me this is a preference thing) then I think you should define a new lyxrc variable dialogs_placement_policy or something and use it in the same way we use lyxrc.dialogs_iconify_with_main. No need fro extra spagetti in the structure then and all dialogs behave in the same manner. Angus
Re: Re: [Devel] Re: No more slush state
On Thursday 24 January 2002 8:11 am, [EMAIL PROTECTED] wrote: Lars Gullik Bjønnes [EMAIL PROTECTED] schrieb am 23.01.2002, 22:26:15: the async loading/rendering of images is not a show-stopper in my book. Hmm ... but if this is not a show-stopper than what is the problem with the graphics inset as it is right now? Of course, the improvements proposed by Herbert and Angus are very nice but they are not vital either. Michael Look, I keep saying that I already have publicly accessible code http://www.devel/lyx.org/~aleem/guiitest.tar.bz2 that gets the graphics loading asynchronously. The converters need to be converted to work with it. Feel free to help... Angus
Re: No more slush state.
On Thu, Jan 24, 2002 at 09:32:02AM +, Angus Leeming wrote: On Wednesday 23 January 2002 8:05 am, Martin Vermeer wrote: On Wed, Jan 23, 2002 at 08:15:00AM +0100, Andre Poenitz wrote: On Tue, Jan 22, 2002 at 10:46:14PM +0200, Martin Vermeer wrote: What's wrong is that the math panel opens up bang on top of the *formula* you're working on. So why don't you simply move it by a fixed amount into some 'safe' direction? Or open it always over the top right corner of the main LyX window or something similar? Ah: 2. Program the math panel to appear elsewhere, not covering the formula. I have to find out what policies are actually available. This might benefit tabular too. Andre' I am about to find the solution. See patch. With thanks to everybody ;-) If this is a preference thing (and to me this is a preference thing) then I think you should define a new lyxrc variable dialogs_placement_policy or something and use it in the same way we use lyxrc.dialogs_iconify_with_main. No need fro extra spagetti in the structure then and all dialogs behave in the same manner. Angus But Angus, some dialogues are more equal than others! IMHO the ones that require you to see the underlying object, should move themselves out of the way. For the graphics dialog e.g. this is not so, and it is in fact better to have them come up under your mouse. But math, and tabular, should get out of the way. I have code that also chooses the alternative placement strategy for tabular. No big deal. The idea of a lyxrc parameter is great. Why not two of them while we're at it? I suspect it could even be done so that by adding a data member to the FormBaseDeprecated class, we could get around the split-up I implemented here. Just assign a strategy constant to the inherited instance, and call ::show. In that way you could have per-dialogue-type strategies. Do you think that could work? Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq msg31981/pgp0.pgp Description: PGP signature
Re: No more slush state.
But Angus, some dialogues are more equal than others! IMHO the ones that
require you to see the underlying object, should move themselves out of the
way. For the graphics dialog e.g. this is not so, and it is in fact better
to have them come up under your mouse. But math, and tabular, should get out
of the way.
I have code that also chooses the alternative placement strategy for
tabular.
No big deal.
The idea of a lyxrc parameter is great. Why not two of them while we're at
it?
I suspect it could even be done so that by adding a data member to the
FormBaseDeprecated class, we could get around the split-up I implemented
here.
Just assign a strategy constant to the inherited instance, and call ::show.
In that way you could have per-dialogue-type strategies.
Do you think that could work?
Sure. After 1.2.0 is out.
We should probably do something like this:
class LyXRC {
public:
enum DialogPlacementPolicy {
UNDER_MOUSE,
FREE_SPACE
};
DialogPlacementPolicy default_placement;
};
class BaseController {
public:
virtual DialogPlacementPolicy showStrategy() const
{ return default_placement;}
};
class SomeController : public BaseController {
public:
/// Override the default
DialogPlacementPolicy showStrategy() const;
};
and whilst these few dialogs still exist that have yet to be converted to MCV:
class FormBaseDeprecated {
public:
virtual DialogPlacementPolicy showStrategy() const
{ return default_placement;}
};
class SomeForm : public FormBaseDeprecated {
public:
/// Override the default
DialogPlacementPolicy showStrategy() const;
};
Re: No more slush state.
On Thu, Jan 24, 2002 at 12:05:00PM +, Angus Leeming wrote: ... I suspect it could even be done so that by adding a data member to the FormBaseDeprecated class, we could get around the split-up I implemented here. Just assign a strategy constant to the inherited instance, and call ::show. In that way you could have per-dialogue-type strategies. Do you think that could work? Sure. After 1.2.0 is out. We should probably do something like this: ... Hmmm... I came up with the attached. A minimal solution for dialog-type-dependent policies. Does precisely what I originally wanted. Tested and works ;-) Is there a real need to allow the user to set these? Not that it cannot be done... Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq diff.gz Description: application/gunzip msg31988/pgp0.pgp Description: PGP signature
Re: [Devel] Re: No more slush state
Angus Leeming wrote: Look, I keep saying that I already have publicly accessible code http://www.devel/lyx.org/~aleem/guiitest.tar.bz2 that gets the graphics loading asynchronously. The converters need to be converted to work with it. Feel free to help... can you give a working link ... ;-) Herbert -- http://www.lyx.org/help/
Re: [Devel] Re: No more slush state
On Thursday 24 January 2002 4:02 pm, Herbert Voss wrote: Angus Leeming wrote: Look, I keep saying that I already have publicly accessible code http://www.devel/lyx.org/~aleem/guiitest.tar.bz2 that gets the graphics loading asynchronously. The converters need to be converted to work with it. Feel free to help... can you give a working link ... ;-) Herbert ;-) http://www.devel.lyx.org/~leeming/guiitest.tar.bz2 This seems to work A
Re: [Devel] Re: No more slush state
Lars Gullik Bjønnes wrote: Does the InsetGraphics have all the features of figinset? At least I am not missing anything. And the inset dialog suggests that the new inset supercharges the old one. Michael
Re: [Devel] Re: No more slush state
On Thu, Jan 24, 2002 at 06:52:55PM +0100, Michael Schmitt wrote: Lars Gullik Bjønnes wrote: Does the InsetGraphics have all the features of figinset? At least I am not missing anything. And the inset dialog suggests that the new inset supercharges the old one. waiting for all the graphics to load is a serious pain. You cannot insert a large graphics sensibly and display it in lyx since no resizing is done. The extension-removal code is broken. There's more on bugzilla I believe. regards john -- ALL television is children's television. - Richard Adler
Re: No more slush state.
FWIW, I don't particularly like the idea of splitting the code up or adding yet another parameter to the base class implementation. For starters these problems are a combo of XForms and window manager policy. Secondly, different toolkits have different ways of doing the same or similar things. Thirdly, the base class arrangement Angus developed for the XForms port is almost general enough to make another common directory of code out of. I'm not 100% convinced it should be though but it should certainly be viewed as a reference implementation. If a change really must be made then I'd rather the last location of the dialog be remembered and it be reopened where I last left it. I don't know how well XForms or other toolkits can handle that. Allan. (ARRae)
Re: No more slush state.
On Wednesday 23 January 2002 8:05 am, Martin Vermeer wrote: > On Wed, Jan 23, 2002 at 08:15:00AM +0100, Andre Poenitz wrote: > > > On Tue, Jan 22, 2002 at 10:46:14PM +0200, Martin Vermeer wrote: > > > What's wrong is that the math panel opens up bang on top of the > > > *formula* you're working on. > > > > So why don't you simply move it by a fixed amount into some 'safe' > > direction? Or open it always over the top right corner of the main LyX > > window or something similar? > > > > Ah: > > > > > 2. Program the math panel to appear elsewhere, not covering the formula. > > > I have to find out what policies are actually available. This might > > > benefit tabular too. > > > > Andre' > > I am about to find the solution. See patch. > With thanks to everybody ;-) If this is a preference thing (and to me this is a preference thing) then I think you should define a new lyxrc variable dialogs_placement_policy or something and use it in the same way we use lyxrc.dialogs_iconify_with_main. No need fro extra spagetti in the structure then and all dialogs behave in the same manner. Angus
Re: Re: [Devel] Re: No more slush state
On Thursday 24 January 2002 8:11 am, [EMAIL PROTECTED] wrote: > Lars Gullik Bjønnes <[EMAIL PROTECTED]> schrieb am 23.01.2002, 22:26:15: > > > the async loading/rendering of images is not a show-stopper in my > > book. > > Hmm ... but if this is not a show-stopper than what is the problem with > the graphics inset as it is right now? Of course, the improvements > proposed by Herbert and Angus are very nice but they are not vital > either. > > Michael Look, I keep saying that I already have publicly accessible code http://www.devel/lyx.org/~aleem/guiitest.tar.bz2 that gets the graphics loading asynchronously. The converters need to be "converted" to work with it. Feel free to help... Angus
Re: No more slush state.
On Thu, Jan 24, 2002 at 09:32:02AM +, Angus Leeming wrote: > On Wednesday 23 January 2002 8:05 am, Martin Vermeer wrote: > > On Wed, Jan 23, 2002 at 08:15:00AM +0100, Andre Poenitz wrote: > > > > > On Tue, Jan 22, 2002 at 10:46:14PM +0200, Martin Vermeer wrote: > > > > What's wrong is that the math panel opens up bang on top of the > > > > *formula* you're working on. > > > > > > So why don't you simply move it by a fixed amount into some 'safe' > > > direction? Or open it always over the top right corner of the main LyX > > > window or something similar? > > > > > > Ah: > > > > > > > 2. Program the math panel to appear elsewhere, not covering the > formula. > > > > I have to find out what policies are actually available. This might > > > > benefit tabular too. > > > > > > Andre' > > > > I am about to find the solution. See patch. > > With thanks to everybody ;-) > > If this is a preference thing (and to me this is a preference thing) then I > think you should define a new lyxrc variable dialogs_placement_policy or > something > and use it in the same way we use lyxrc.dialogs_iconify_with_main. > > No need fro extra spagetti in the structure then and all dialogs behave in > the same manner. > > Angus But Angus, some dialogues are more equal than others! IMHO the ones that require you to see the underlying object, should move themselves out of the way. For the graphics dialog e.g. this is not so, and it is in fact better to have them come up under your mouse. But math, and tabular, should get out of the way. I have code that also chooses the alternative placement strategy for tabular. No big deal. The idea of a lyxrc parameter is great. Why not two of them while we're at it? I suspect it could even be done so that by adding a data member to the FormBaseDeprecated class, we could get around the split-up I implemented here. Just assign a strategy constant to the inherited instance, and call ::show. In that way you could have per-dialogue-type strategies. Do you think that could work? Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq msg31981/pgp0.pgp Description: PGP signature
Re: No more slush state.
> But Angus, some dialogues are more equal than others! IMHO the ones that
> require you to see the underlying object, should move themselves out of the
> way. For the graphics dialog e.g. this is not so, and it is in fact better
> to have them come up under your mouse. But math, and tabular, should get out
> of the way.
>
> I have code that also chooses the alternative placement strategy for
tabular.
> No big deal.
>
> The idea of a lyxrc parameter is great. Why not two of them while we're at
it?
> I suspect it could even be done so that by adding a data member to the
> FormBaseDeprecated class, we could get around the split-up I implemented
here.
> Just assign a strategy constant to the inherited instance, and call ::show.
> In that way you could have per-dialogue-type strategies.
>
> Do you think that could work?
Sure. After 1.2.0 is out.
We should probably do something like this:
class LyXRC {
public:
enum DialogPlacementPolicy {
UNDER_MOUSE,
FREE_SPACE
};
DialogPlacementPolicy default_placement;
};
class BaseController {
public:
virtual DialogPlacementPolicy showStrategy() const
{ return default_placement;}
};
class SomeController : public BaseController {
public:
/// Override the default
DialogPlacementPolicy showStrategy() const;
};
and whilst these few dialogs still exist that have yet to be converted to MCV:
class FormBaseDeprecated {
public:
virtual DialogPlacementPolicy showStrategy() const
{ return default_placement;}
};
class SomeForm : public FormBaseDeprecated {
public:
/// Override the default
DialogPlacementPolicy showStrategy() const;
};
Re: No more slush state.
On Thu, Jan 24, 2002 at 12:05:00PM +, Angus Leeming wrote: ... > > I suspect it could even be done so that by adding a data member to the > > FormBaseDeprecated class, we could get around the split-up I implemented > here. > > Just assign a strategy constant to the inherited instance, and call ::show. > > In that way you could have per-dialogue-type strategies. > > > > Do you think that could work? > > Sure. After 1.2.0 is out. > > We should probably do something like this: ... Hmmm... I came up with the attached. A minimal solution for dialog-type-dependent policies. Does precisely what I originally wanted. Tested and works ;-) Is there a real need to allow the user to set these? Not that it cannot be done... Martin -- Martin Vermeer [EMAIL PROTECTED] Helsinki University of Technology Department of Surveying P.O. Box 1200, FIN-02015 HUT, Finland :wq diff.gz Description: application/gunzip msg31988/pgp0.pgp Description: PGP signature
Re: [Devel] Re: No more slush state
Angus Leeming wrote: > Look, I keep saying that I already have publicly accessible code > http://www.devel/lyx.org/~aleem/guiitest.tar.bz2 > that gets the graphics loading asynchronously. The converters need to be > "converted" to work with it. Feel free to help... can you give a working link ... ;-) Herbert -- http://www.lyx.org/help/
Re: [Devel] Re: No more slush state
On Thursday 24 January 2002 4:02 pm, Herbert Voss wrote: > Angus Leeming wrote: > > > Look, I keep saying that I already have publicly accessible code > > http://www.devel/lyx.org/~aleem/guiitest.tar.bz2 > > that gets the graphics loading asynchronously. The converters need to be > > "converted" to work with it. Feel free to help... > > > can you give a working link ... ;-) > Herbert ;-) http://www.devel.lyx.org/~leeming/guiitest.tar.bz2 This seems to work A
Re: [Devel] Re: No more slush state
Lars Gullik Bjønnes wrote: > Does the InsetGraphics have all the features of figinset? At least I am not missing anything. And the inset dialog suggests that the new inset supercharges the old one. Michael
Re: [Devel] Re: No more slush state
On Thu, Jan 24, 2002 at 06:52:55PM +0100, Michael Schmitt wrote: > Lars Gullik Bjønnes wrote: > > >Does the InsetGraphics have all the features of figinset? > > At least I am not missing anything. And the inset dialog suggests that > the new inset supercharges the old one. waiting for all the graphics to load is a serious pain. You cannot insert a large graphics sensibly and display it in lyx since no resizing is done. The extension-removal code is broken. There's more on bugzilla I believe. regards john -- "ALL television is children's television." - Richard Adler
Re: No more slush state.
FWIW, I don't particularly like the idea of splitting the code up or adding yet another parameter to the base class implementation. For starters these problems are a combo of XForms and window manager policy. Secondly, different toolkits have different ways of doing the same or similar things. Thirdly, the base class arrangement Angus developed for the XForms port is almost general enough to make another common directory of code out of. I'm not 100% convinced it should be though but it should certainly be viewed as a reference implementation. If a change really must be made then I'd rather the last location of the dialog be remembered and it be reopened where I last left it. I don't know how well XForms or other toolkits can handle that. Allan. (ARRae)
Re: Re: [Devel] Re: No more slush state
Lars Gullik Bjønnes [EMAIL PROTECTED] schrieb am 23.01.2002, 22:26:15: the async loading/rendering of images is not a show-stopper in my book. Hmm ... but if this is not a show-stopper than what is the problem with the graphics inset as it is right now? Of course, the improvements proposed by Herbert and Angus are very nice but they are not vital either. Michael
Re: Re: [Devel] Re: No more slush state
Lars Gullik Bjønnes <[EMAIL PROTECTED]> schrieb am 23.01.2002, 22:26:15: > the async loading/rendering of images is not a show-stopper in my > book. Hmm ... but if this is not a show-stopper than what is the problem with the graphics inset as it is right now? Of course, the improvements proposed by Herbert and Angus are very nice but they are not vital either. Michael
Re: No more slush state.
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars We have been in a slush state regarding patches for a log time Lars now. I belive we have fixed most of the really important Lars problems now, so I want us to move to a near-full-freeze state. Good. Lars So... fix those bugs in Bugzilla. The last remaining ones are a bit difficult, methinks. We have also two patches from Juergen which should be finished/commited. Lars again: Only Bug Fixing now, and be sure to have other people to Lars have a look at your patches before committing. On a related note: my time hacking actively on lyx is finished for now (but I get my family back!)... Also, I won't have much time this week. So if someone can review/commit recent patches from martin and herbert that will be appreciated. JMarc
Re: No more slush state.
Lars Gullik Bjønnes wrote: We have been in a slush state regarding patches for a log time now. I belive we have fixed most of the really important problems now, so I want us to move to a near-full-freeze state. This means that patches that fix _anything_ that is not in Bugzilla shall not be committed to CVS. but telle me, what is a bug? for example: http://cvs.koziarski.com/show_bug.cgi?id=38 is not a bug, only a missing feature. And there are a lot of them. Herbert -- http://www.lyx.org/help/
Re: No more slush state.
On Tue, Jan 22, 2002 at 03:55:53PM +0100, Herbert Voss wrote: but telle me, what is a bug? for example: http://cvs.koziarski.com/show_bug.cgi?id=38 is not a bug, only a missing feature. And there are a lot of them. well the question is, can 1.2.0 be OK without this ? If so we can remove the milestone. regards john -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. - Gnome bugzilla
Re: No more slush state.
On Tue, Jan 22, 2002 at 03:58:18PM +0100, Lars Gullik Bjønnes wrote: and it is marked as an enhancement right? no, it's a bug because it's a regression from insetfig So, not a bug. and I do not want anybody to even look at it for now. i'll remove the milestone. what about synchronous rendering ? lyx is unusable on big docs with lots of insetgraphics right now john -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. - Gnome bugzilla
Re: No more slush state.
On Tue, Jan 22, 2002 at 04:08:56PM +0100, Lars Gullik Bjønnes wrote: then since no one is working on getting insetgraphics to work as well as the old figinset we will have to revert to figinset. not true, angus has some ideas and even some preliminary proof of concept code 1.2.0 proper is likely to be quite some time away (when we get deluged by bugs on 1.2.0pre1) regards john -- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. - Gnome bugzilla
Re: No more slush state.
On Tuesday 22 January 2002 3:08 pm, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Tue, Jan 22, 2002 at 03:58:18PM +0100, Lars Gullik Bjønnes wrote: and it is marked as an enhancement right? | no, it's a bug because it's a regression from insetfig Then it should prefereably be fixed. So, not a bug. and I do not want anybody to even look at it for now. | i'll remove the milestone. | what about synchronous rendering ? lyx is unusable on big docs with lots | of insetgraphics right now then since no one is working on getting insetgraphics to work as well as the old figinset we will have to revert to figinset. Well, this seems sensible. Basically it involves just removing the new Graphics inset from the menu. Not even coding. However, I was in the process of tackling the insetgraphics bugs myself. I'll continue in private then. Angus
Re: No more slush state.
Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | On Tuesday 22 January 2002 3:08 pm, Lars Gullik Bjønnes wrote: John Levon [EMAIL PROTECTED] writes: | On Tue, Jan 22, 2002 at 03:58:18PM +0100, Lars Gullik Bjønnes wrote: and it is marked as an enhancement right? | no, it's a bug because it's a regression from insetfig Then it should prefereably be fixed. ok, I hope that it's a bug for today, maybe it changed tomorrow ... ;-) any comments to the gui? HErbert -- http://www.lyx.org/help/
Re: No more slush state.
On Tue, Jan 22, 2002 at 03:44:39PM +0100, Jean-Marc Lasgouttes wrote: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars We have been in a slush state regarding patches for a log time Lars now. I belive we have fixed most of the really important Lars problems now, so I want us to move to a near-full-freeze state. Good. Lars So... fix those bugs in Bugzilla. The last remaining ones are a bit difficult, methinks. We have also two patches from Juergen which should be finished/commited. Lars again: Only Bug Fixing now, and be sure to have other people to Lars have a look at your patches before committing. On a related note: my time hacking actively on lyx is finished for now (but I get my family back!)... Also, I won't have much time this week. So if someone can review/commit recent patches from martin and herbert that will be appreciated. JMarc Yes, we *must* get a working 1.2.0pre out now. Agreed! I have been sinning lately, working on the mathed xforms interface (styles/fonts and space, moved the latter from radio buttons to self- applying buttons; and the AMS symbol panels). Also I made this cool little patch below that allows you to right click on a formula to bring up the math panel. But about unistd.h and usleep... so very C. Is there a better way for this? Works a charm. I hope at least someone gives it a swirl while waiting for the next thaw :-) -- Martin 2002-01-14 Martin Vermeer [EMAIL PROTECTED] * formulabase.C: math panel comes up 0.5 s after right mouse click on formula. Delay is to allow positioning of the panel. Index: formulabase.C === RCS file: /cvs/lyx/lyx-devel/src/mathed/formulabase.C,v retrieving revision 1.121 diff -u -b -B -p -r1.121 formulabase.C --- formulabase.C 2002/01/16 14:24:37 1.121 +++ formulabase.C 2002/01/22 15:18:48 @@ -17,6 +17,7 @@ #include Lsstream.h #include support/LAssert.h +#include unistd.h #ifdef __GNUG__ #pragma implementation @@ -32,6 +33,7 @@ #include LaTeXFeatures.h #include debug.h #include math_support.h +#include frontends/Dialogs.h #include support/lstrings.h #include LyXView.h #include Painter.h @@ -309,6 +311,11 @@ void InsetFormulaBase::insetButtonPress( } break; */ + case 3: + // launch math panel for right mouse button + usleep(50); + bv-owner()-getDialogs()-showMathPanel(); + break; } bv-updateInset(this, false); } msg31933/pgp0.pgp Description: PGP signature
Re: No more slush state.
Herbert Voss [EMAIL PROTECTED] writes: any comments to the gui? Seems ok, I especially like the Scale % thing. How is the % of column width handled? Is it in Width/Height? Maybe all the scaling could be combined? And I don't quite like the |#x lables. They just look a bit messy. Yours (unbiased by any thorough understanding of it :-)) Thomas [EMAIL PROTECTED]
Re: No more slush state.
Herbert Voss wrote: any comments to the gui? Just a few cosmetics (matter of taste, of course): IMHO Enable is useless and unusual (compared to the other dialogs in LyX). Natural Size - Custom Width/ Height - Scale, Subcaption, Dither etc. are better and match the overall design. And Natural Size - Custom Width/ Height - Scale should of course have radio buttons instead of checkboxes ;-) But isn't Angus working on the dialog, too? Greets, Juergen.
Re: No more slush state.
Thomas Steffen wrote: Herbert Voss [EMAIL PROTECTED] writes: any comments to the gui? Seems ok, I especially like the Scale % thing. How is the % of column width handled? Is it in Width/Height? Maybe all the scaling could be combined? And I don't quite like the |#x lables. They just look a bit messy. it's only grabbed from the form_designer. This is not the real label. Herbert -- http://www.lyx.org/help/
Re: No more slush state.
On Tuesday 22 January 2002 3:40 pm, Herbert Voss wrote:
any comments to the gui?
How about, it's messy?
More seriously, I think that we're getting there. You've added
* dither
* rotation origin
variables to your previous proposal.
I think that we should, in addition, have
* a way to specify the image size in LyX (separate to that of the output
image).
* a way to display/output only a part of the image (crop it).
Ultimately, I think we should have a dialog that allows the user to input all
the supported options of the graphicx version of the \includegraphics*
command and, in addition, has some specific size-in-LyX options.
\usepackage{graphicx}
\includegraphics*[keyval list]{file}
see grfguide.pdf for a full documentation.
Angus
Re: No more slush state.
On Tue, Jan 22, 2002 at 05:09:59PM +0100, Lars Gullik Bjønnes wrote: | Also I made this cool little patch below that allows you to right | click on a formula to bring up the math panel. But about unistd.h | and usleep... so very C. Is there a better way for this? Why sleep at all? | 2002-01-14 Martin Vermeer [EMAIL PROTECTED] | * formulabase.C: math panel comes up 0.5 s after right mouse | click on formula. Delay is to allow positioning of the panel. better to make the panel movable then. -- Lgb How? -- Martin the C++ Moron msg31939/pgp0.pgp Description: PGP signature
Re: No more slush state.
Angus Leeming wrote:
More seriously, I think that we're getting there. You've added
* dither
* rotation origin
variables to your previous proposal.
I think that we should, in addition, have
* a way to specify the image size in LyX (separate to that of the output
image).
* a way to display/output only a part of the image (crop it).
Ultimately, I think we should have a dialog that allows the user to input all
the supported options of the graphicx version of the \includegraphics*
command and, in addition, has some specific size-in-LyX options.
\usepackage{graphicx}
\includegraphics*[keyval list]{file}
agreed!
Herbert
--
http://www.lyx.org/help/
Re: No more slush state.
On Tuesday 22 January 2002 4:23 pm, Martin Vermeer wrote: | 2002-01-14 Martin Vermeer [EMAIL PROTECTED] | * formulabase.C: math panel comes up 0.5 s after right mouse | click on formula. Delay is to allow positioning of the panel. better to make the panel movable then. How? -- Martin the C++ Moron Dear Martin. No need to be so self-deprecating. We're all morons here! Anyway, the MathsPanel is derived from FormBaseDeprecated. The show() method of this base class contains the code that defines where the dialog appears: fl_show_form(form(), FL_PLACE_MOUSE | FL_FREE_SIZE, (lyxrc.dialogs_iconify_with_main ? FL_TRANSIENT : 0), title_.c_str()); Ie, place the dialog underneath the mouse. This is the same for all dialogs and shouldn't be different for just one. I think. It's easy enough to move the newly visible dialog. So just remove the usleep command and your patch is very nice (and good C++ as well as C)! Angus
Re: No more slush state.
On Tue, Jan 22, 2002 at 04:38:37PM +, Angus Leeming wrote: Dear Martin. No need to be so self-deprecating. We're all morons here! :-) Appreciated. Anyway, the MathsPanel is derived from FormBaseDeprecated. The show() method of this base class contains the code that defines where the dialog appears: fl_show_form(form(), FL_PLACE_MOUSE | FL_FREE_SIZE, (lyxrc.dialogs_iconify_with_main ? FL_TRANSIENT : 0), title_.c_str()); Ie, place the dialog underneath the mouse. This is the same for all dialogs and shouldn't be different for just one. I think. It's easy enough to move the newly visible dialog. Did you actually try it without the sleep code? It's a PITA! A bit like our cat that used to come and lie on the book I was just reading or the paper I was just writing :-) The math panel differs from most other panels (tabular?) in that you want the object it is working on to be simultaneously visible! So just remove the usleep command and your patch is very nice (and good C++ as well as C)! Angus -- Martin msg31945/pgp0.pgp Description: PGP signature
Re: No more slush state.
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin The math panel differs from most other panels (tabular?) in Martin that you want the object it is working on to be simultaneously Martin visible! So you open it with right click, and keep it open until you think it annoying and keep it closed for some time. What's wrong with that? JMarc
Bugzilla alterations (Was Re: No more slush state.)
John wrote: 1.2.0 proper is likely to be quite some time away (when we get deluged by bugs on 1.2.0pre1) Well, I'll try to get a bugzilla helper like ximian's or Eazel's (before they popped). Ideally users will be able to submit the bugs directly rather than posting them to a mailing list. Also, I'd prefer to *not* have the url as cvs.koziarski.com once bugzilla starts getting serious external use. Can bugzilla.lyx.org point to 203.96.63.156? Finally, I'll try to fix the seemingly random From: field in mail from bugzilla. Cheers Koz I refuse to attach a permanence to anything I see around me, including the pessimism I read today in the Wall Street Journal. With my 60 years of experience, I can't say that anything I've witnessed, including two world wars, and the spread of communism, have had any identifiable long-term effect on common stock investments. -- Ben Graham, June 15, 1975
Re: No more slush state.
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> We have been in a slush state regarding patches for a log time Lars> now. I belive we have fixed most of the really important Lars> problems now, so I want us to move to a near-full-freeze state. Good. Lars> So... fix those bugs in Bugzilla. The last remaining ones are a bit difficult, methinks. We have also two patches from Juergen which should be finished/commited. Lars> again: Only Bug Fixing now, and be sure to have other people to Lars> have a look at your patches before committing. On a related note: my time hacking actively on lyx is finished for now (but I get my family back!)... Also, I won't have much time this week. So if someone can review/commit recent patches from martin and herbert that will be appreciated. JMarc
Re: No more slush state.
Lars Gullik Bjønnes wrote: > We have been in a slush state regarding patches for a log time now. I > belive we have fixed most of the really important problems now, so I > want us to move to a near-full-freeze state. > > This means that patches that fix _anything_ that is not in Bugzilla > shall not be committed to CVS. but telle me, what is a bug? for example: http://cvs.koziarski.com/show_bug.cgi?id=38 is not a bug, only a missing feature. And there are a lot of them. Herbert -- http://www.lyx.org/help/
Re: No more slush state.
On Tue, Jan 22, 2002 at 03:55:53PM +0100, Herbert Voss wrote: > but telle me, what is a bug? for example: > > http://cvs.koziarski.com/show_bug.cgi?id=38 > > is not a bug, only a missing feature. And there are a lot of > them. well the question is, can 1.2.0 be OK without this ? If so we can remove the milestone. regards john -- "The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world." - Gnome bugzilla
Re: No more slush state.
On Tue, Jan 22, 2002 at 03:58:18PM +0100, Lars Gullik Bjønnes wrote: > and it is marked as an enhancement right? no, it's a bug because it's a regression from insetfig > So, not a bug. and I do not want anybody to even look at it for now. i'll remove the milestone. what about synchronous rendering ? lyx is unusable on big docs with lots of insetgraphics right now john -- "The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world." - Gnome bugzilla
Re: No more slush state.
On Tue, Jan 22, 2002 at 04:08:56PM +0100, Lars Gullik Bjønnes wrote: > then since no one is working on getting insetgraphics to work as well > as the old figinset we will have to revert to figinset. not true, angus has some ideas and even some preliminary proof of concept code 1.2.0 proper is likely to be quite some time away (when we get deluged by bugs on 1.2.0pre1) regards john -- "The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world." - Gnome bugzilla
Re: No more slush state.
On Tuesday 22 January 2002 3:08 pm, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Tue, Jan 22, 2002 at 03:58:18PM +0100, Lars Gullik Bjønnes wrote: > > > >> and it is marked as an enhancement right? > > > | no, it's a bug because it's a regression from insetfig > > Then it should prefereably be fixed. > > >> So, not a bug. and I do not want anybody to even look at it for now. > > > | i'll remove the milestone. > > > | what about synchronous rendering ? lyx is unusable on big docs with lots > | of insetgraphics right now > > then since no one is working on getting insetgraphics to work as well > as the old figinset we will have to revert to figinset. Well, this seems sensible. Basically it involves just removing the new Graphics inset from the menu. Not even coding. However, I was in the process of tackling the insetgraphics bugs myself. I'll continue in private then. Angus
Re: No more slush state.
Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | On Tuesday 22 January 2002 3:08 pm, Lars Gullik Bjønnes wrote: > >>>John Levon <[EMAIL PROTECTED]> writes: >>> >>>| On Tue, Jan 22, 2002 at 03:58:18PM +0100, Lars Gullik Bjønnes wrote: >>> >and it is marked as an enhancement right? > >>>| no, it's a bug because it's a regression from insetfig >>> >>>Then it should prefereably be fixed. ok, I hope that it's a bug for today, maybe it changed tomorrow ... ;-) any comments to the gui? HErbert -- http://www.lyx.org/help/
Re: No more slush state.
On Tue, Jan 22, 2002 at 03:44:39PM +0100, Jean-Marc Lasgouttes wrote: > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > > Lars> We have been in a slush state regarding patches for a log time > Lars> now. I belive we have fixed most of the really important > Lars> problems now, so I want us to move to a near-full-freeze state. > > Good. > > Lars> So... fix those bugs in Bugzilla. > > The last remaining ones are a bit difficult, methinks. We have also > two patches from Juergen which should be finished/commited. > > Lars> again: Only Bug Fixing now, and be sure to have other people to > Lars> have a look at your patches before committing. > > On a related note: my time hacking actively on lyx is finished for now > (but I get my family back!)... Also, I won't have much time this week. > So if someone can review/commit recent patches from martin and herbert > that will be appreciated. > > > JMarc Yes, we *must* get a working 1.2.0pre out now. Agreed! I have been "sinning" lately, working on the mathed xforms interface (styles/fonts and space, moved the latter from radio buttons to self- applying buttons; and the AMS symbol panels). Also I made this cool little patch below that allows you to right click on a formula to bring up the math panel. But about unistd.h and usleep... so very C. Is there a better way for this? Works a charm. I hope at least someone gives it a swirl while waiting for the next thaw :-) -- Martin 2002-01-14 Martin Vermeer <[EMAIL PROTECTED]> * formulabase.C: math panel comes up 0.5 s after right mouse click on formula. Delay is to allow positioning of the panel. Index: formulabase.C === RCS file: /cvs/lyx/lyx-devel/src/mathed/formulabase.C,v retrieving revision 1.121 diff -u -b -B -p -r1.121 formulabase.C --- formulabase.C 2002/01/16 14:24:37 1.121 +++ formulabase.C 2002/01/22 15:18:48 @@ -17,6 +17,7 @@ #include "Lsstream.h" #include "support/LAssert.h" +#include "unistd.h" #ifdef __GNUG__ #pragma implementation @@ -32,6 +33,7 @@ #include "LaTeXFeatures.h" #include "debug.h" #include "math_support.h" +#include "frontends/Dialogs.h" #include "support/lstrings.h" #include "LyXView.h" #include "Painter.h" @@ -309,6 +311,11 @@ void InsetFormulaBase::insetButtonPress( } break; */ + case 3: + // launch math panel for right mouse button + usleep(50); + bv->owner()->getDialogs()->showMathPanel(); + break; } bv->updateInset(this, false); } msg31933/pgp0.pgp Description: PGP signature
Re: No more slush state.
Herbert Voss <[EMAIL PROTECTED]> writes: > any comments to the gui? Seems ok, I especially like the "Scale %" thing. How is the "% of column width" handled? Is it in Width/Height? Maybe all the scaling could be combined? And I don't quite like the |#x lables. They just look a bit messy. Yours (unbiased by any thorough understanding of it :-)) Thomas <[EMAIL PROTECTED]>
Re: No more slush state.
Herbert Voss wrote: > any comments to the gui? Just a few cosmetics (matter of taste, of course): IMHO "Enable" is useless and unusual (compared to the other dialogs in LyX). Natural Size - Custom Width/ Height - Scale, Subcaption, Dither etc. are better and match the overall design. And Natural Size - Custom Width/ Height - Scale should of course have radio buttons instead of checkboxes ;-) But isn't Angus working on the dialog, too? Greets, Juergen.
Re: No more slush state.
Thomas Steffen wrote: > Herbert Voss <[EMAIL PROTECTED]> writes: > > >>any comments to the gui? >> > > Seems ok, I especially like the "Scale %" thing. > > How is the "% of column width" handled? Is it in Width/Height? Maybe > all the scaling could be combined? > > And I don't quite like the |#x lables. They just look a bit messy. it's only grabbed from the form_designer. This is not the real label. Herbert -- http://www.lyx.org/help/
Re: No more slush state.
On Tuesday 22 January 2002 3:40 pm, Herbert Voss wrote:
> any comments to the gui?
How about, "it's messy"?
More seriously, I think that we're getting there. You've added
* dither
* rotation origin
variables to your previous proposal.
I think that we should, in addition, have
* a way to specify the image size in LyX (separate to that of the output
image).
* a way to display/output only a part of the image (crop it).
Ultimately, I think we should have a dialog that allows the user to input all
the supported options of the graphicx version of the \includegraphics*
command and, in addition, has some specific size-in-LyX options.
\usepackage{graphicx}
\includegraphics*[keyval list]{file}
see grfguide.pdf for a full documentation.
Angus
Re: No more slush state.
On Tue, Jan 22, 2002 at 05:09:59PM +0100, Lars Gullik Bjønnes wrote: > > > | Also I made this cool little patch below that allows you to right > | click on a formula to bring up the math panel. But about unistd.h > | and usleep... so very C. Is there a better way for this? > > Why sleep at all? > > | 2002-01-14 Martin Vermeer <[EMAIL PROTECTED]> > | * formulabase.C: math panel comes up 0.5 s after right mouse > > | click on formula. Delay is to allow positioning of the panel. > > better to make the panel movable then. > > -- > Lgb How? -- Martin the C++ Moron msg31939/pgp0.pgp Description: PGP signature
Re: No more slush state.
Angus Leeming wrote:
> More seriously, I think that we're getting there. You've added
> * dither
> * rotation origin
> variables to your previous proposal.
>
> I think that we should, in addition, have
> * a way to specify the image size in LyX (separate to that of the output
> image).
> * a way to display/output only a part of the image (crop it).
>
> Ultimately, I think we should have a dialog that allows the user to input all
> the supported options of the graphicx version of the \includegraphics*
> command and, in addition, has some specific size-in-LyX options.
>
> \usepackage{graphicx}
> \includegraphics*[keyval list]{file}
agreed!
Herbert
--
http://www.lyx.org/help/
Re: No more slush state.
On Tuesday 22 January 2002 4:23 pm, Martin Vermeer wrote: > > | 2002-01-14 Martin Vermeer <[EMAIL PROTECTED]> > > | * formulabase.C: math panel comes up 0.5 s after right mouse > > | click on formula. Delay is to allow positioning of the panel. > > > > better to make the panel movable then. > How? > > -- Martin the C++ Moron Dear Martin. No need to be so self-deprecating. We're all morons here! Anyway, the MathsPanel is derived from FormBaseDeprecated. The show() method of this base class contains the code that defines where the dialog appears: fl_show_form(form(), FL_PLACE_MOUSE | FL_FREE_SIZE, (lyxrc.dialogs_iconify_with_main ? FL_TRANSIENT : 0), title_.c_str()); Ie, place the dialog underneath the mouse. This is the same for all dialogs and shouldn't be different for just one. I think. It's easy enough to move the newly visible dialog. So just remove the usleep command and your patch is very nice (and good C++ as well as C)! Angus
Re: No more slush state.
On Tue, Jan 22, 2002 at 04:38:37PM +, Angus Leeming wrote: > Dear Martin. No need to be so self-deprecating. We're all morons here! :-) Appreciated. > Anyway, the MathsPanel is derived from FormBaseDeprecated. The show() method > of this base class contains the code that defines where the dialog appears: > > fl_show_form(form(), > FL_PLACE_MOUSE | FL_FREE_SIZE, > (lyxrc.dialogs_iconify_with_main ? FL_TRANSIENT : 0), > title_.c_str()); > > Ie, place the dialog underneath the mouse. This is the same for all dialogs > and shouldn't be different for just one. I think. It's easy enough to move > the newly visible dialog. Did you actually try it without the sleep code? It's a PITA! A bit like our cat that used to come and lie on the book I was just reading or the paper I was just writing :-) The math panel differs from most other panels (tabular?) in that you want the object it is working on to be simultaneously visible! > So just remove the usleep command and your patch is very nice (and good C++ > as well as C)! > > Angus > -- Martin msg31945/pgp0.pgp Description: PGP signature
Re: No more slush state.
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> The math panel differs from most other panels (tabular?) in Martin> that you want the object it is working on to be simultaneously Martin> visible! So you open it with right click, and keep it open until you think it annoying and keep it closed for some time. What's wrong with that? JMarc
Bugzilla alterations (Was Re: No more slush state.)
John wrote: "1.2.0 proper is likely to be quite some time away (when we get deluged by bugs on 1.2.0pre1)" Well, I'll try to get a bugzilla helper like ximian's or Eazel's (before they popped). Ideally users will be able to submit the bugs directly rather than posting them to a mailing list. Also, I'd prefer to *not* have the url as cvs.koziarski.com once bugzilla starts getting serious external use. Can bugzilla.lyx.org point to 203.96.63.156? Finally, I'll try to fix the seemingly random From: field in mail from bugzilla. Cheers Koz "I refuse to attach a permanence to anything I see around me, including the pessimism I read today in the Wall Street Journal. With my 60 years of experience, I can't say that anything I've witnessed, including two world wars, and the spread of communism, have had any identifiable long-term effect on common stock investments." -- Ben Graham, June 15, 1975
