On Mon, Aug 19, 2002 at 06:05:58PM +0900, Rob Lahaye wrote:
> Jean-Marc Lasgouttes wrote:
> >>"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> >
> >
> > Angus> Hm. What do the LaTeX experts say? Angus
> >
> > That will be a problem when it is used somewhere which is not an
> >
Angus Leeming wrote:
> On Monday 19 August 2002 10:03 am, Jean-Marc Lasgouttes wrote:
>
>>>"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>>Angus> Hm. What do the LaTeX experts say? Angus
>>
>>That will be a problem when it is used somewhere which is not an
>>image (minipage
Jean-Marc Lasgouttes wrote:
>>"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
>
> Angus> Hm. What do the LaTeX experts say? Angus
>
> That will be a problem when it is used somewhere which is not an
> image (minipage width or whatever).
Argh. Well, I may have to find another
On Monday 19 August 2002 10:03 am, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Hm. What do the LaTeX experts say? Angus
>
> That will be a problem when it is used somewhere which is not an
> image (minipage width or whatever).
Then it sh
On Monday 19 August 2002 9:59 am, Rob Lahaye wrote:
> >>but I need here also something like "image%%". May I add that?
> >
> > Not to xforms_helpers. It's used only by FormGraphics, so should go
> > there.
>
> I don't agree (I believe).
> I'll have an image% (well actually I renamed it to "scale%"
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Hm. What do the LaTeX experts say? Angus
That will be a problem when it is used somewhere which is not an
image (minipage width or whatever).
JMarc
Angus Leeming wrote:
> On Sunday 18 August 2002 3:50 am, Rob Lahaye wrote:
>
>>Angus Leeming wrote:
>>
>>>On Saturday 17 August 2002 7:05 am, Rob Lahaye wrote:
>>>
1) Image percentage unit needed for Width/Height output size.
>>>
>>>See xhorms_helpers.h. Do you want "choice_Length_All" rather
On Sunday 18 August 2002 3:50 am, Rob Lahaye wrote:
> Angus Leeming wrote:
> > On Saturday 17 August 2002 7:05 am, Rob Lahaye wrote:
> >>1) Image percentage unit needed for Width/Height output size.
> >
> > See xhorms_helpers.h. Do you want "choice_Length_All" rather than
> > "choice_Length_WithUn
On Mon, Aug 19, 2002 at 01:18:30AM +0900, Rob Lahaye wrote:
> graphics
> dialog needs an update, that removes the redundant buttons and intput
> fields.
> I would like to leave that up to you.
Sure.
> Indeed I'm removing stuff and reinterpreting the left-over stuff.
> Backwards compatibility m
On Sun, Aug 18, 2002 at 04:50:51PM +0100, John Levon wrote:
>
> That's what I mean - why ? I admit I am too lazy to look at the patch
> but I thought Rob was just removing stuff.
Even if he was only removing stuff, it should be considered as a format
change.
But we already have the change size_
John Levon wrote:
> On Sun, Aug 18, 2002 at 06:41:03PM +0300, Dekel Tsur wrote:
>
>
>>On Sun, Aug 18, 2002 at 04:03:55PM +0100, John Levon wrote:
>>
>>>On Sun, Aug 18, 2002 at 04:52:47PM +0300, Dekel Tsur wrote:
>>>
>>>
Shouldn't the format be > 1 ?
However, I don't see why we should sto
On Sun, Aug 18, 2002 at 06:41:03PM +0300, Dekel Tsur wrote:
> On Sun, Aug 18, 2002 at 04:03:55PM +0100, John Levon wrote:
> > On Sun, Aug 18, 2002 at 04:52:47PM +0300, Dekel Tsur wrote:
> >
> > > Shouldn't the format be > 1 ?
> > > However, I don't see why we should store the format # in the ins
On Sun, Aug 18, 2002 at 04:03:55PM +0100, John Levon wrote:
> On Sun, Aug 18, 2002 at 04:52:47PM +0300, Dekel Tsur wrote:
>
> > Shouldn't the format be > 1 ?
> > However, I don't see why we should store the format # in the inset.
>
> I don't see why the output format needs changing. Instead we j
On Sun, Aug 18, 2002 at 04:52:47PM +0300, Dekel Tsur wrote:
> Shouldn't the format be > 1 ?
> However, I don't see why we should store the format # in the inset.
I don't see why the output format needs changing. Instead we just
deprecate the bits we don't use any more.
regards
john
--
"Someon
On Sat, Aug 17, 2002 at 02:23:09AM +0900, Rob Lahaye wrote:
> The following is an excerpt from the LyX output file that has two graphics insets,
>the
> first simply with the graphics default values, the second with everthing non-default.
>
> --
On Thu, Aug 15, 2002 at 03:46:54PM -0300, Garst R. Reese wrote:
> > > when I write a article/book then I do not know for some images
> > > what kind of output (b/w - gray - color) maybe the best.
> > > No problem with current lyx, I switch to different views
> > > and decide "online" to what I wil
Angus Leeming wrote:
> On Saturday 17 August 2002 7:05 am, Rob Lahaye wrote:
>>
>>1) Image percentage unit needed for Width/Height output size.
>
>
> See xhorms_helpers.h. Do you want "choice_Length_All" rather than
> "choice_Length_WithUnit"?
In xforms_helpers.h I find:
// what we always nee
On Saturday 17 August 2002 7:05 am, Rob Lahaye wrote:
> Hi,
>
> Attached is a screenshot of the new dialog.
> Some implementation questions remain for the new graphics dialog.
>
> 1) Image percentage unit needed for Width/Height output size.
See xhorms_helpers.h. Do you want
Rob Lahaye wrote:
>
> 3) Compatibility with 1.2.0.
>
>In 1.2.0 one can select "Original Size", but still have a value for
>Scale. This does not go well with the new dialog for LyX View.
>The Read routine should remember it has read "Original Size", to
>
Hi,
Attached is a screenshot of the new dialog.
Some implementation questions remain for the new graphics dialog.
1) Image percentage unit needed for Width/Height output size.
--
Output size now only has three input fields: Width
On Friday 16 August 2002 6:23 pm, Rob Lahaye wrote:
> Angus Leeming wrote:
> > That should get you started.
>
> Yep, thanks for your help.
Pleasure
> Is the patch okay for applying? If so, I send it again tomorrow with a
> decent ChangLog. Next, I would like to do a clean up of all the stuff
> t
Angus Leeming wrote:
>
> That should get you started.
Yep, thanks for your help.
Attached is the new Xforms Graphics dialog. The dialog itself is slightly improved
from last prepatch and I've done the implementation of the new input fields.
Many buttons have disappeared in the dialog, so a lot
On Friday 16 August 2002 4:35 pm, John Levon wrote:
> > > Then do something like "igp.rotate == rotvalue != 0.0;"
> > > to enable it as necessary
> > support/lyxlib.h: if (float_equal(var, number, 0.0001))
> again that's not needed in this case is it ??
More barminess.
rotvalue is a float. Yo
On Fri, Aug 16, 2002 at 04:18:48PM +0100, Angus Leeming wrote:
> support/lyxlib.h: if (float_equal(var, number, 0.0001))
again that's not needed in this case is it ??
regards
john
--
"Someone turn off the good idea tap; we're drowning here!"
- Rusty Russell
On Friday 16 August 2002 4:35 pm, John Levon wrote:
> in apply() read the input box and convert it to a double using strToDbl
> as you do already. Then do something like "igp.rotate == rotvalue != 0.0;"
> to enable it as necessary
support/lyxlib.h: if (float_equal(var, number, 0.0001))
Angus
On Fri, Aug 16, 2002 at 07:59:43PM +0900, Rob Lahaye wrote:
> So the layout is there. I needed to introduce one new param,
> called "int lyxdisplay" in insetgrahpicsParams.h, to handle
> the new LyX display choice selector.
No, you don't need to do this. Convert the setting of the combo box into
On Fri, Aug 16, 2002 at 04:09:47PM +0900, Rob Lahaye wrote:
> If the last choice to be made boils down to either
>
> Display mode: |___| (Default|Don'tDisplay|Gs|Mono|Color)
>
> or
> o Display graphics
>
> in the graphics dialog, and we have about equal support for both,
> then let
On Friday 16 August 2002 11:59 am, Rob Lahaye wrote:
> Hi,
>
> I have attached a patch for the new graphics dialog.
> Main focus of the patch is the layout. I desperately need
> help to implement the (new) items, since I have no clue how
> and where to do that properly, without
Hi,
I have attached a patch for the new graphics dialog.
Main focus of the patch is the layout. I desperately need
help to implement the (new) items, since I have no clue how
and where to do that properly, without breaking too much.
So the layout is there. I needed to introduce one new param
On Thu, Aug 15, 2002 at 11:14:35PM +0100, John Levon wrote:
> Totally ! I don't know why we have this !
For marketing reasons.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Garst R. Reese wrote:
> Allan Rae wrote:
>
>>>Graphics dialog:
>>>
>>>Display mode: |___| (Default|Don'tDisplay|Gs|Mono|Color)
>>
>>This bit is still contraversial. Some want it to just be:
>>
>>Graphics dialog:
>> o Display graphics
>
> Only angry gerbils.
If the last choice to b
On Fri, 16 Aug 2002, Rob Lahaye wrote:
> I'm loosing track a bit of what is the concensus.
> Is it like this:
>
>
> Global prefs :
>
> Display mode: |___| (Gs|Mono|Color)
>
> o Display graphics
This bit is agreed upon (including the ordering change)
> Graphics dialog:
>
> Dis
Allan Rae wrote:
> On Thu, 15 Aug 2002, John Levon wrote:
>
>
>>On Thu, Aug 15, 2002 at 05:23:19PM +1000, Allan Rae wrote:
>>>
>>>Maybe reversing the order of the two preferences would be enough.
>>
>>Yes, you're right on this one.
>
> Woo hoo! Does this mean I are becoming a "Good UI" person?
Allan Rae <[EMAIL PROTECTED]> writes:
| On Thu, 15 Aug 2002, John Levon wrote:
>
>> On Thu, Aug 15, 2002 at 05:23:19PM +1000, Allan Rae wrote:
>>
>> > Even though the display mode widget will always be activated it would
>> > be good if the layout was such that a dependency wasn't implied
>> > vi
On Thu, 15 Aug 2002, John Levon wrote:
> On Thu, Aug 15, 2002 at 05:23:19PM +1000, Allan Rae wrote:
>
> > Even though the display mode widget will always be activated it would
> > be good if the layout was such that a dependency wasn't implied
> > visually (by placement I mean).
> >
> > Maybe rev
On Thu, Aug 15, 2002 at 04:55:12PM -0300, Garst R. Reese wrote:
> > It's pure featuritis IMHO
> Like support for Preview.sty?
Totally ! I don't know why we have this ! (actually I can understand the
\input support a lot better). But people seem to like it a lot so I
just demur on that one ...
>
On Thu, Aug 15, 2002 at 03:46:54PM -0300, Garst R. Reese wrote:
> It takes more time. I have to go through the file, see which images I
We're not emacs, we're not gnumeric, and I don't see why we should be xv
either, frankly. Embed a KPart into LyX, then I am (reasonably) happy.
It's pure featu
On Thu, Aug 15, 2002 at 05:23:19PM +1000, Allan Rae wrote:
> Even though the display mode widget will always be activated it would
> be good if the layout was such that a dependency wasn't implied
> visually (by placement I mean).
>
> Maybe reversing the order of the two preferences would be eno
On Thu, Aug 15, 2002 at 09:12:57AM +0200, Herbert Voss wrote:
> >Preferences:
> >
> >[x] Do/don't display
> >
> >Display mode []
>
>
> we have: one click
> you want: two clicks
No. Amazon patents aside, it is not a matter of number of clicks, or
number of widgets. Such metrics
On Thu, Aug 15, 2002 at 03:35:15PM +0900, Rob Lahaye wrote:
> Okay. I see. So maybe we can come a conclusive layout for the display setup:
/me boggles
This is EXACTLY what you dismissed yesterday !
> [x] Force display
Force is totally the wrong word here
regards
john
Garst R. Reese wrote:
>
> No. I look at graphics in my LyXView to determine the minimum level that
> I can put in a pdf. Having to reset my preferences to do this is a PITA.
> What we have works fine for me. If it ain't broke, don't fix it. But if
> you insist.
No, I don't insist on anything.
I'
On Thu, 15 Aug 2002, Rob Lahaye wrote:
Seems okay.
>
> Preferences:
>
> [x] Do/don't display
>
> Display mode []
Even though the display mode widget will always be activated it would
be good if the layout was such that a dependency wasn't
Rob Lahaye wrote:
>
> Preferences:
>
> [x] Do/don't display
>
> Display mode []
we have: one click
you want: two clicks
> Graphics:
>
> [x] Force display
>
>
>
> The "Do/don't display" and "For
Allan Rae wrote:
> Maybe you didn't read what Garst does?
Can't recall.
> FWIW, just 'cos it's in colour doesn't mean it will be printed in
> colour as some people like their LyX display to look a lot like their
Okay. I see. So maybe we can come a conclusive layout for the display setup:
-
> Maybe you didn't read what Garst does?
>
> FWIW, just 'cos it's in colour doesn't mean it will be printed in
> colour as some people like their LyX display to look a lot like their
> printouts (especially useful for foils if you get the width of the LyX
> window just right). In addition an im
On Thu, 15 Aug 2002, Rob Lahaye wrote:
> Another thought:
>
> Let's get rid of the gs/mono/color choice all together. Only implement the
> "Do not display" toggle in the prefs/graph dialogs; the rest should be dealt
> with automagically.
Automagic is the worst kind of magic. I'm sure John must
John Levon wrote:
> On Thu, Aug 15, 2002 at 12:20:01PM +0900, Rob Lahaye wrote:
>
>
>>No, I haven't changed my mind :).
>
>
> Hmmph. Well if we have this we should at least have the dont display
> checkbox as separate in both cases (with the combo box enable-dependent
> upon it)
>
> (I still
On Thu, Aug 15, 2002 at 12:20:01PM +0900, Rob Lahaye wrote:
> No, I haven't changed my mind :).
Hmmph. Well if we have this we should at least have the dont display
checkbox as separate in both cases (with the combo box enable-dependent
upon it)
(I still not sure how I'm going to even implement
John Levon wrote:
> On Thu, Aug 15, 2002 at 11:15:25AM +0900, Rob Lahaye wrote:
>
>
>>There could be an important disadvantage with the new setup.
>>
>>Now, per-graph I can overrule the prefs display by selecting one of
>>Monochrome, Grayscale, and Color. One graph may be better visible in
>>Gra
On Thu, Aug 15, 2002 at 11:15:25AM +0900, Rob Lahaye wrote:
> There could be an important disadvantage with the new setup.
>
> Now, per-graph I can overrule the prefs display by selecting one of
> Monochrome, Grayscale, and Color. One graph may be better visible in
> Grayscale, another in Color
John Levon wrote:
>
> Usability is not a linear function of the number of widgets. My
> suggestions are IMHO better for the following reasons :
>
> 1) the global don't display is far more discoverable and understandable
>
> 2) a combo box that only ever has two entries is logically a checkbox i
On Thu, Aug 15, 2002 at 10:20:27AM +0900, Rob Lahaye wrote:
> >OK, this is a "final" solution, taking in Rob's redesign, and everyone's
> >comments (I hope).
> >
> >Global prefs :
> >
> > o Display graphics
> >
> >
> > Display mode: | Color|
> > ---
John Levon wrote:
>
> OK, this is a "final" solution, taking in Rob's redesign, and everyone's
> comments (I hope).
>
> Global prefs :
>
> o Display graphics
>
>
> Display mode: | Color|
>
>
> disabling the checkbox does NOT disab
On Wed, Aug 14, 2002 at 07:42:07PM +0200, Herbert Voss wrote:
> >>Did you ever noticed that no user complained about this
> >>graphic dialog ...
> >
> >This is (almost) irrelevant.
>
> cool. LyX, an open source as playground for developers
You mis understand. It's the old "can't prove a negativ
John Levon wrote:
>>Did you ever noticed that no user complained about this
>>graphic dialog ...
>>
>
> This is (almost) irrelevant.
cool. LyX, an open source as playground for developers
Herbert
--
http://www.lyx.org/help/
On Wed, Aug 14, 2002 at 10:25:08AM +0200, Herbert Voss wrote:
> >Rob wants to be able to control display (on/off) locally. If the
> >global setting is off and the local setting is on with your option
> >how should the graphics be displayed? colour, grey or mono?
> >
> >Did you read Rob's descri
Dekel Tsur wrote:
> On Wed, Aug 14, 2002 at 06:20:44PM +1000, Allan Rae wrote:
>
> I believe that for this mode of work, the following interface would be better:
> in the global preferences you choose display type (mono/grey/color),
> and display mode: display/don't display/display only when dial
On Wed, Aug 14, 2002 at 04:54:57AM -0300, Garst R. Reese wrote:
> Jean-Marc Lasgouttes wrote:
> >
> > > "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
> >
> > Rob> But what to choose for the display mode, when it's selected; grey
> > Rob> scale, color, or monochrome. If this is not trivial,
On Wed, Aug 14, 2002 at 06:20:44PM +1000, Allan Rae wrote:
>
> Did you read Rob's description of how he uses graphics? It's the
> opposite of your way of doing things (he defaults of off globally and
> only enables display for a short time while fiddling locally).
Here is Rob's mail:
1) A la
On Wed, 14 Aug 2002, Herbert Voss wrote:
> and I use globally on and locally what the output may be and
> never use off.
Globally on what? colour/grey or mono?
Then override this locally to display an image as something different?
Is this really that useful? apart from selecting grey as global
Allan Rae wrote:
>>Allan> One for what to display as (grey/color/mono) and another to
>>Allan> decide whether displaying is on/off globally.
>>
>>It could be grey/color/mono/off.
>>
>
> How is that going to work?
>
> Rob wants to be able to control display (on/off) locally. If the
> global set
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> How is that going to work?
Allan> Rob wants to be able to control display (on/off) locally. If
Allan> the global setting is off and the local setting is on with your
Allan> option how should the graphics be displayed? colour, grey or
On 14 Aug 2002, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> On 14 Aug 2002, Jean-Marc Lasgouttes wrote:
> >> > "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
> >>
> Rob> But what to choose for the display mode, when it's selected; grey
> Ro
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> On 14 Aug 2002, Jean-Marc Lasgouttes wrote:
>> > "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
>>
Rob> But what to choose for the display mode, when it's selected; grey
Rob> scale, color, or monochrome. If this is not trivial, w
On 14 Aug 2002, Jean-Marc Lasgouttes wrote:
> > "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
>
> Rob> But what to choose for the display mode, when it's selected; grey
> Rob> scale, color, or monochrome. If this is not trivial, we better
> Rob> keep the full choice selector as before.
>
>
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
Rob> But what to choose for the display mode, when it's selected; grey
Rob> scale, color, or monochrome. If this is not trivial, we better
Rob> keep the full choice selector as before.
This is what I meant in my earlier posting: this grey/col
John Levon wrote:
> On Wed, Aug 14, 2002 at 10:54:44AM +0900, Rob Lahaye wrote:
>
>
>>So I won't be happy by removing the LyX View sizes. And I may not be
>>the only user that uses this feature this way.
>
>
> But we could just have a scale percentage ?
Ah, that is the perfect compromise!
Ke
On Wed, Aug 14, 2002 at 10:54:44AM +0900, Rob Lahaye wrote:
> So I won't be happy by removing the LyX View sizes. And I may not be
> the only user that uses this feature this way.
But we could just have a scale percentage ?
regards
john
--
"It is unbecoming for young men to utter maxims."
Dekel Tsur wrote:
> On Tue, Aug 13, 2002 at 10:12:28PM +0900, Rob Lahaye wrote:
>
>
> Since we don't have LyX View size buttons, the "Get LaTeX size"
> doesn't make sense, so it should also be removed.
Oh, I misunderstood that. You really want to get rid of the Width/Height
sizes for LyX View a
On Wed, Aug 14, 2002 at 01:01:34AM +0200, Lars Gullik Bjønnes wrote:
> | Lars must have reintroduced this then.
>
> I have done nothing with this.
So it seems
sorry,
john
--
"It is unbecoming for young men to utter maxims."
- Aristotle
John Levon <[EMAIL PROTECTED]> writes:
| Lars must have reintroduced this then.
I have done nothing with this.
--
Lgb
On Tue, Aug 13, 2002 at 10:34:33PM +0900, Rob Lahaye wrote:
> >Yes, but setting mono/color/whatever on a graph-by-graph level is
> >overkill IMO. Only don't display should remain.
>
> I don't understand this.
> When the prefs are set to "don't display", I need a per-graph
> toggle to "DO display
On Tue, Aug 13, 2002 at 10:12:28PM +0900, Rob Lahaye wrote:
> Alright agree. I never use that myself.
> But should we keep the "Get LaTeX size" for the LyX View sizes?
> Or should that also go?
Why can't we fill in the fields like that by default ? We could have a
"reset" button or something if
On Tue, Aug 13, 2002 at 10:12:28PM +0900, Rob Lahaye wrote:
> Dekel Tsur wrote:
> > - No LyX View buttons (except a single scale button)
>
> Hmmm, if I temporarily want to display a single graph, do you want me set that for
>all
> graphs in the prefs? I can imagine to have the prefs on "don't di
Jean-Marc Lasgouttes wrote:
>>"Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
>
>
> Rob> Dekel Tsur wrote:
>
>>>You seem to ignored my suggestions: - No LyX View buttons (except a
>>>single scale button)
>>
>
> Rob> Hmmm, if I temporarily want to display a single graph, do you
> Rob> wa
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
Rob> Dekel Tsur wrote:
>> You seem to ignored my suggestions: - No LyX View buttons (except a
>> single scale button)
Rob> Hmmm, if I temporarily want to display a single graph, do you
Rob> want me set that for all graphs in the prefs? I can
Dekel Tsur wrote:
>
> You seem to ignored my suggestions:
> - No LyX View buttons (except a single scale button)
Hmmm, if I temporarily want to display a single graph, do you want me set that for all
graphs in the prefs? I can imagine to have the prefs on "don't display", but when
inserting
a n
On Tue, Aug 13, 2002 at 02:29:18PM +0900, Rob Lahaye wrote:
>
> Hi,
>
> As a tried to merge Xforms Graphics dialog with the Qt-version (Qt version is really
>nice!),
> I have come up with the layout for Xforms as attached. Main changes are:
You seem to ignored my suggestions:
- No LyX View bu
On Tuesday 13 August 2002 6:29 am, Rob Lahaye wrote:
> Hi,
>
> As a tried to merge Xforms Graphics dialog with the Qt-version (Qt version
> is really nice!), I have come up with the layout for Xforms as attached.
Good idea. Taking the best ideas from each frontend to impove them all is a
Good Th
On Tuesday 13 August 2002 11:54 am, John Levon wrote:
> On Tue, Aug 13, 2002 at 02:29:18PM +0900, Rob Lahaye wrote:
> > Subtle detail: the [Cancel] button in Xforms has become a [Close]
> > button in Qt. Which one is better?
>
> Hmm, they should be the same - i.e. they change to Cancel when some
On Tue, Aug 13, 2002 at 02:29:18PM +0900, Rob Lahaye wrote:
> Subtle detail: the [Cancel] button in Xforms has become a [Close]
> button in Qt. Which one is better?
Hmm, they should be the same - i.e. they change to Cancel when some of
the dialog contents change.
> Another one: configure still
Hi,
As a tried to merge Xforms Graphics dialog with the Qt-version (Qt version is really
nice!),
I have come up with the layout for Xforms as attached. Main changes are:
1) Merge LyX-View tab into the File tab.
Merge LaTeX-size tab and BoundingBox tab into a single Output size tab.
Mov
On Wednesday 27 February 2002 14:56, Angus Leeming wrote:
> On Wednesday 27 February 2002 1:03 pm, Edwin Leuven wrote:
> > It didn't.
>
> So, I'm confused here. You have an empty Data d-tor and you stilll crash?
no after your little patch it looked like
GImageXPM::Data::~Data()
{
if (col
On Wednesday 27 February 2002 12:55 pm, Edwin Leuven wrote:
> > What I find interesting is
> > 2 I've been requesting testers for days. I have to put this thing in cvs
> > and inflict pain to make progress :-(
>
> The only way to progress. Let's delete the xforms code...I'll bet
> we'll have a n
On Wednesday 27 February 2002 1:03 pm, Edwin Leuven wrote:
> It didn't.
So, I'm confused here. You have an empty Data d-tor and you stilll crash?
Then it's something to do with the shared_c_ptrs. But why isn't this in the
backtrace?
Can you put an explicit:
data_.reset();
imag
> > why would that help?
It didn't. Can the crash be related to the following:
Error creating pixmap from xpm_image 'XpmColorFailed'
Ed.
> ?? So the bug isn't in free_color_table after all ??
I take that as a retorical question...
> > Now doing a clean compile
> why would that help?
It has helped before. Don't ask me why.
> What I find interesting is
> 2 I've been requesting testers for days. I have to put this thing in cvs
On Wednesday 27 February 2002 12:29 pm, Edwin Leuven wrote:
> Crash as well.
?? So the bug isn't in free_color_table after all ??
> Now doing a clean compile
why would that help?
What I find interesting is
1 I don't get the crash
2 I've been requesting testers for days. I have to put th
Crash as well. Now doing a clean compile
#0 0x402d2025 in __libc_free (mem=0x84c6d90) at malloc.c:3155
#1 0x0821c6ed in grfx::GImageXPM::Data::~Data (this=0x84adff4, __in_chrg=2)
at ../../src/support/utility.h:44
#2 0x0821ba69 in grfx::GImageXPM::~GImageXPM (this=0x84adff0, __in_chrg=3
On Wednesday 27 February 2002 11:21 am, Edwin Leuven wrote:
> > Do you get the crash if you comment out the call to free_color_table
> > entirely?
>
> No crash when:
>
> GImageXPM::Data::~Data()
> {
> }
And what effect does the attached patch have? Apply from the graphics directory to
current
On Wednesday 27 February 2002 11:21 am, Edwin Leuven wrote:
> > Do you get the crash if you comment out the call to free_color_table
> > entirely?
>
> No crash when:
>
> GImageXPM::Data::~Data()
> {
> }
Interesting!
A
> Do you get the crash if you comment out the call to free_color_table
> entirely?
No crash when:
GImageXPM::Data::~Data()
{
}
On Wednesday 27 February 2002 10:41 am, Edwin Leuven wrote:
> > GImageXPM::Data::~Data()
> > {
> > - if (colorTable_.unique())
> > + if (colorTable_.get() && colorTable_.unique())
> > free_color_table(colorTable_.get(), ncolors_);
> > }
Do you get the crash if you comment out the
> GImageXPM::Data::~Data()
> {
> - if (colorTable_.unique())
> + if (colorTable_.get() && colorTable_.unique())
> free_color_table(colorTable_.get(), ncolors_);
> }
then I get the following:
#0 0x402d2025 in __libc_free (mem=0x84c6d40) at malloc.c:3155
#1 0x0821c69d in gr
On Wednesday 27 February 2002 10:17 am, Edwin Leuven wrote:
> 1. new doc
> 2. insert eps
> 3. close without saving
>
> then Segmentation fault:
>
> #0 0x402d2025 in __libc_free (mem=0x84c6d18) at malloc.c:3155
> #1 0x0821c695 in grfx::GImageXPM::Data::~Data (this=0x84bf49c, __in_chrg=2)
>
1. new doc
2. insert eps
3. close without saving
then Segmentation fault:
#0 0x402d2025 in __libc_free (mem=0x84c6d18) at malloc.c:3155
#1 0x0821c695 in grfx::GImageXPM::Data::~Data (this=0x84bf49c, __in_chrg=2)
at ../../src/support/utility.h:44
#2 0x0821ba85 in grfx::GImageXPM::~GImageXP
Garst R. Reese wrote:
> Herbert Voss wrote:
>
>>my first round for the gui. I changed it to a tabbed
>>one, because I don't like those guis which are larger than
>>the main window ...
>>
>>are you missing anything?
>>I have no individuell mono/color/gray section. I think, it's
>>okay, when it's
On Thu, Jan 24, 2002 at 06:30:09PM +0100, Herbert Voss wrote:
> Open the file from within LyX may be better??
Yes.
Try
bool readBB(string const & file)
{
ifstream is(file.c_str());
while (is) {
string s;
is >> s;
if (s == "%%Boundi
Angus Leeming wrote:
> Well the concept of being able to crop the image still exists...
> It'd be nice if we could fill these inputs when the file was selcted.
what seems to be the best way to get the bb values from a
chosen eps/ps-file? A system grep under Unix/Linux is fine
and gives the lin
On Thursday 24 January 2002 5:01 pm, Herbert Voss wrote:
> Angus Leeming wrote:
>
> >>The coordinates are measured in the traditional typesetting units
> >>"points", where 1 inch = 72 points (1 cm = 28 points).
> >>Yes, we can convert things like 3cm into points, but
> >>I don't know, if its a go
1 - 100 of 117 matches
Mail list logo
