On Thu, Aug 14, 2003 at 05:33:19PM +0200, Michael Schmitt wrote:
> why is the button in the tabular dialog called "cancel"? "close" be more
> appropriate, wouldn't it?
Remove the setCancel() call for the button.
john
--
Khendon's Law:
If the same point i
Hi,
why is the button in the tabular dialog called "cancel"? "close" be more
appropriate, wouldn't it?
Michael
Juergen Vigna <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > This would make Sep 27 a good target, closely followed by Sep 20 and July
| > 26. The next bunch is July 19, and Sep 6.
|
| IMO Sep 27 would be a perfect date ;)
But it is awfully late...
--
Lgb
On Tuesday 11 March 2003 10:07 am, Andre Poenitz wrote:
> On Tue, Mar 11, 2003 at 09:48:01AM +, Angus Leeming wrote:
> > > The problem here is that we use direct access from the GUI to the
> > > kernel to extract information instead of using the 'pipe interface'.
> > > One reason for that is, o
Andre Poenitz wrote:
This would make Sep 27 a good target, closely followed by Sep 20 and July
26. The next bunch is July 19, and Sep 6.
IMO Sep 27 would be a perfect date ;)
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [E
On Tue, Mar 11, 2003 at 10:53:27AM +0100, Andre' Poenitz wrote:
> [- indicates Jose or Lars not attenting who could attend if we'd stick to
> June 22th. I would not like to use these dates.]
Uh... In noticed that should be extended to those dates concerning
Jean-Marc as well. So July 19 and Sep 6
On Tue, Mar 11, 2003 at 09:48:01AM +, Angus Leeming wrote:
> > The problem here is that we use direct access from the GUI to the kernel
> > to extract information instead of using the 'pipe interface'. One reason
> > for that is, of course, that our current 'pipe interface' does not allow
> > t
On Tue, Mar 11, 2003 at 10:41:07AM +0100, Jean-Marc Lasgouttes wrote:
> So, here what it would look like for me
Thanks.
> Note that I took the liberty to add June 29, which for some strange
> reason does not appear on the list.
Sorry. My mistake.
The current state now is:
Lars Jo
Andre Poenitz wrote:
> I think I'd still rather pass a
>
>FuncRequest(DIALOG_SHOW, arg, InsetBase*, whatever)
>
> to
>
>cmd.view()->dispatch()
>
> in the Inset::dispatch(cmd) instead of having all these mailer classes
> around, but I have no religious feelings about it.
Fair enough. B
Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 06:35:10PM +, Angus Leeming wrote:
>> > But I have another problem: I need to re-implement almost all of the
>> > TabularInset interface to make it play nicely with FormTabular.C
>> > (and I am not sure I like it)
>>
>> You mean you have to w
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Mon, Mar 10, 2003 at 06:46:51PM +0100, Jean-Marc Lasgouttes
Andre> wrote: PS: Jean-Marc, I still need a few numbers...
>> Yes, sorry about that. I am still waiting for answer of somebody I
>> am suppoed to visit at the beginning
On Mon, Mar 10, 2003 at 06:32:02PM +, Angus Leeming wrote:
> Actually, we could have
>
> static boost::signal2 Dialogs::hideDialog
>
> and connect this to any instance of the Dialogs class. It would be used as:
>
> void MailInset::hideDialog() {
> Dialogs::hideDialog
On Mon, Mar 10, 2003 at 06:35:10PM +, Angus Leeming wrote:
> > But I have another problem: I need to re-implement almost all of the
> > TabularInset interface to make it play nicely with FormTabular.C
> > (and I am not sure I like it)
>
> You mean you have to write a methods equivalent to
On Monday 10 March 2003 6:20 pm, Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 06:20:41PM +, Angus Leeming wrote:
> > Try the attached patch anyway...
>
> Doesn't look wrong...
>
> But I have another problem: I need to re-implement almost all of the
> TabularInset interface to make it play nic
Angus Leeming wrote:
> We could certainly pass a BufferView to showDialog and updateDialog and
> that BufferView could come from the calling FuncRequest. The problem comes
> with hideDialog which must be called from the inset's d-tor. I'm at a bit
> of a loss how to do that otherwise. I would reall
On Mon, Mar 10, 2003 at 06:20:41PM +, Angus Leeming wrote:
> Try the attached patch anyway...
Doesn't look wrong...
But I have another problem: I need to re-implement almost all of the
TabularInset interface to make it play nicely with FormTabular.C
(and I am not sure I like it)
Not toda
On Monday 10 March 2003 6:01 pm, Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 06:02:16PM +, Angus Leeming wrote:
> > Because the plan was to consider a LyXView as a GUI entity. This enitity
> > would have its own dialogs and (possibly) multiple BufferViews.
> > Moreover, we could have multipl
On Mon, Mar 10, 2003 at 06:08:10PM +, Angus Leeming wrote:
> You did. Anything before mid July is no good for me. Thereafter I have some
> commitments in mid August and the w/e of 11 Sep but the rest is free. I'll
> dig out my diary again.
Ok. I'll wait.
Sep 27 is starting to look really g
On Mon, Mar 10, 2003 at 07:07:17PM +0100, Lars Gullik Bjønnes wrote:
> | May 3 1 0 5 0 0
> | May10 1 0 5 0 0
> | May17 1 0 5 0 0
> | May24 1 0 5 0 0
> | June1 1 5 5 0
On Mon, Mar 10, 2003 at 06:02:16PM +, Angus Leeming wrote:
> Because the plan was to consider a LyXView as a GUI entity. This enitity
> would have its own dialogs and (possibly) multiple BufferViews.
> Moreover, we could have multiple LyXViews each with its own dialogs.
Hmm.. stupid me... the
On Monday 10 March 2003 5:53 pm, Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 06:47:25PM +0100, Lars Gullik Bjønnes wrote:
> > | You'll get an extra free beer in June. Oh, no, wait...
> >
> > btw. Have we decided on a date?
>
> I was waiting for Jean-Marc's wish list.
>
> Current plan is still 22
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Mar 10, 2003 at 06:46:51PM +0100, Jean-Marc Lasgouttes wrote:
| > Andre> PS: Jean-Marc, I still need a few numbers...
| >
| > Yes, sorry about that. I am still waiting for answer of somebody I am
| > suppoed to visit at the beginning of june. Wh
On Monday 10 March 2003 5:43 pm, Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 05:45:31PM +, Angus Leeming wrote:
> > > Ok, the view() is 0. But I do not want to store it somewhere, nor
> > > would I like to guess.
> > >
> > > Why is the view() essential for the dialogs?
> >
> > Something has
On Mon, Mar 10, 2003 at 06:47:25PM +0100, Lars Gullik Bjønnes wrote:
> | You'll get an extra free beer in June. Oh, no, wait...
>
> btw. Have we decided on a date?
I was waiting for Jean-Marc's wish list.
Current plan is still 22th of June, but it does not look like a very
senssible date right n
On Mon, Mar 10, 2003 at 06:46:51PM +0100, Jean-Marc Lasgouttes wrote:
> Andre> PS: Jean-Marc, I still need a few numbers...
>
> Yes, sorry about that. I am still waiting for answer of somebody I am
> suppoed to visit at the beginning of june. What are the periods you ar
> ethe most interested in?
On Mon, Mar 10, 2003 at 05:45:31PM +, Angus Leeming wrote:
> > Ok, the view() is 0. But I do not want to store it somewhere, nor would I
> > like to guess.
> >
> > Why is the view() essential for the dialogs?
>
> Something has to physically store the bloody things you burk ;-)
I'd guess so.
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Mar 10, 2003 at 05:32:58PM +, Angus Leeming wrote:
| > Dialogs.C and Dialog2.C were originally split over two files because the
| > template instatiations of the old scheme were by far the most expensive
| > part of the entire compilation p
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Mon, Mar 10, 2003 at 05:32:58PM +, Angus Leeming wrote:
>> Dialogs.C and Dialog2.C were originally split over two files
>> because the template instatiations of the old scheme were by far
>> the most expensive part of the ent
Andre Poenitz wrote:
>
> Ok, the view() is 0. But I do not want to store it somewhere, nor would I
> like to guess.
>
> Why is the view() essential for the dialogs?
Something has to physically store the bloody things you burk ;-)
bv->owner()->getDialogs().show(name(), inset2string(),
Ok, the view() is 0. But I do not want to store it somewhere, nor would I
like to guess.
Why is the view() essential for the dialogs?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
On Mon, Mar 10, 2003 at 05:32:58PM +, Angus Leeming wrote:
> Dialogs.C and Dialog2.C were originally split over two files because the
> template instatiations of the old scheme were by far the most expensive
> part of the entire compilation process. The new scheme is far, far cheaper
> as we
Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 05:23:55PM +, Angus Leeming wrote:
>> frontends/$GUI/Dialogs.Cwill all die when the new scheme
>> frontends/$GUI/Dialogs2.C is implemented fully
>> frontends/$GUI/Dialog3.C contains stuff that is dependent on the GUI
>> toolk
On Mon, Mar 10, 2003 at 05:23:55PM +, Angus Leeming wrote:
> frontends/$GUI/Dialogs.Cwill all die when the new scheme
> frontends/$GUI/Dialogs2.C is implemented fully
> frontends/$GUI/Dialog3.C contains stuff that is dependent on the GUI
> toolkit.
I meant these.
If two
Andre Poenitz wrote:
> On Mon, Mar 10, 2003 at 05:00:33PM +, Angus Leeming wrote:
>> The Dialogs::show method (frontends/Dialogs.C) will filter out crap if
>> you pass it a (!isValidName(name))... Does anything arrive here but
>> proceed no further?
>
> Hm.. why is this split over three files
On Mon, Mar 10, 2003 at 05:00:33PM +, Angus Leeming wrote:
> The Dialogs::show method (frontends/Dialogs.C) will filter out crap if you
> pass it a (!isValidName(name))... Does anything arrive here but proceed no
> further?
Hm.. why is this split over three files?
The files aren't _that_ bi
On Mon, Mar 10, 2003 at 05:00:33PM +, Angus Leeming wrote:
> One possible problem: MailInset::showDialog will fail silently if
> inset.view() == 0. Maybe this is the root of your problems?
Could well be. I'll have a look.
Andre'
--
Those who desire to give up Freedom in order to gain Secur
Andre Poenitz wrote:
>
> It does not get to ControlParam::initialiseParam() as far as I can tell.
>
> Andre'
The Dialogs::show method (frontends/Dialogs.C) will filter out crap if you
pass it a (!isValidName(name))... Does anything arrive here but proceed no
further?
One possible problem: Ma
It does not get to ControlParam::initialiseParam() as far as I can tell.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote: The major (multicolumn) bug was a
Juergen> new regression in 1.3 Bug 572 is a rather minor annoyance.
Juergen> It's not urgent, but I could backport it if requested.
>> So we can live without
Jean-Marc Lasgouttes wrote:
> Juergen> The major (multicolumn) bug was a new regression in 1.3 Bug
> Juergen> 572 is a rather minor annoyance. It's not urgent, but I could
> Juergen> backport it if requested.
>
> So we can live without it, then. However, if you do it, I'll apply it.
Here it comes.
Jean-Marc Lasgouttes wrote:
> Are there parts of it that apply to 1.2.x?
The major (multicolumn) bug was a new regression in 1.3
Bug 572 is a rather minor annoyance. It's not urgent, but I could backport it
if requested.
Jürgen.
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Michael Schmitt wrote:
>> thanks for the patch. It fixes my problem!
Juergen> Good. Here is the patch again (enable fixed width multicolumn
Juergen> cell in xforms + fix for bug 572). Please apply.
Are there parts of it
On Saturday 04 January 2003 3:57 pm, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
> > Good. Here is the patch again (enable fixed width multicolumn cell in
> > xforms + fix for bug 572).
> > Please apply.
>
> Please do not forget this. It is a showstopper for xforms tabular users.
>
>
Juergen Spitzmueller wrote:
> Good. Here is the patch again (enable fixed width multicolumn cell in
> xforms + fix for bug 572).
> Please apply.
Please do not forget this. It is a showstopper for xforms tabular users.
Thanks,
Jürgen.
Michael Schmitt wrote:
> thanks for the patch. It fixes my problem!
Good. Here is the patch again (enable fixed width multicolumn cell in xforms +
fix for bug 572).
Please apply.
Thanks,
Jürgen.
Index: src/frontends/xforms/ChangeLog
===
Hi Jürgen,
thanks for the patch. It fixes my problem!
Michael
[EMAIL PROTECTED] wrote:
> In the tabular dialog (xforms), it is impossible to specify
> a fixed width for multicolumn cells.
the attached patch fixes this. It also fixes bug 572 (hAlignment reset...).
http://bugzilla.lyx.org/show_bug.cgi?id=572
Michael, can you please test if both bu
Hello,
I have found a simple bug in LyX 1.3.0cvs that turns out as
a real showstopper for tabular power users:
In the tabular dialog (xforms), it is impossible to specify
a fixed width for multicolumn cells.
Shall I add a bugzilla entry or is the bug that trivial that it
is easier to fix
> No, the code is correct IMHO.
> I think it is not possible to set H. Alignment in a column with fixed
> width, multicolumn cell or not. That's why it is reset to "left" (Jug,
> please correct me if I'm wrong). What should be done to make this clear
> is disable H. Align in "Cell" if a fixed wid
Allan Rae <[EMAIL PROTECTED]> schrieb am 25.01.2002, 09:18:58:
> It seems so. Have you done anything in particular to cause the
> crash? Lots of undo/redo or something? Tables? Anything in common
> to each session that crashes?
Not really. Sometimes it happens even if you just enter a few wo
Angus Leeming wrote:
> The bogus part is duly forgotten. The change to the button appearance
> will go in.
Thanks!
IMHO the problem lies not in the dialog, but in the tabular inset. For
some reason, alignment is always set to "left" in multicolumn cell if
the column has fixed width. I suspect t
>From Juergen (Spitzmueller ) :
> I think it is not possible to set H. Alignment in a column
> with fixed width, multicolumn cell or not.
I didn't check for multicolumn (but I don't understand where there could
be a problem in this case), but it is possible in LaTeX to have a fixed
width column
On Friday 25 January 2002 9:23 am, Juergen Spitzmueller wrote:
> [EMAIL PROTECTED] wrote:
> > Dear Juergen,
> >
> > It is possible to have a _centered_ multicolumn cell (_without_ fixed
> > width) within a column where all other cells have a fixed width (as a
> > general property of the column)!
>
On Thursday 24 January 2002 8:30 pm, Juergen Spitzmueller wrote:
> Michael Schmitt wrote:
> > 1. If you create a table with a column of fixed width and
> > then you declare one of the cells in this column as a
> > multicolumn cell, the tabular dialog behaves incorr
[EMAIL PROTECTED] wrote:
> Dear Juergen,
>
> It is possible to have a _centered_ multicolumn cell (_without_ fixed
> width) within a column where all other cells have a fixed width (as a
> general property of the column)!
You're right. It is possible as long as you don't close the dialog.
Someth
On Fri, 25 Jan 2002 [EMAIL PROTECTED] wrote:
> Finally: Am I the only one who experiences regular crashes when closing
> LyX even without memory checker? (Please have a look at my bug list for
> a detailed njamd report)
It seems so. Have you done anything in particular to cause the
crash? Lots
Dear Juergen,
> I think it is not possible to set H. Alignment in a column
> with fixed width, multicolumn cell or not.
It is possible to have a _centered_ multicolumn cell (_without_ fixed
width) within a column where all other cells have a fixed width (as a
general property of the column)!
On Thu, Jan 24, 2002 at 09:30:44PM +0100, Juergen Spitzmueller wrote:
> > 2. While having a short look at the code, I noticed
> > that lines 206-208 and 240-242 seem to be contradictory.
>
> Why?
at least redundant - removing 206-208 can not change anything.
> Of course :-) The patch chang
Michael Schmitt wrote:
> 1. If you create a table with a column of fixed width and
> then you declare one of the cells in this column as a
> multicolumn cell, the tabular dialog behaves incorrectly:
> The "H. Alignment" in the "cell" tab is always rese
Hi,
a few comments on the tabular layout dialog:
1. If you create a table with a column of fixed width and
then you declare one of the cells in this column as a
multicolumn cell, the tabular dialog behaves incorrectly:
The "H. Alignment" in the "cell" ta
On 04-Dec-2001 John Levon wrote:
> can we add a dialog on pressing "close" if the text has been changed since
> opening the dialog to ask if it should be applied ?
Yes I guess we could. Who's the xforms guru right now ;)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
On Tue, Dec 04, 2001 at 09:15:34AM +0100, Andre Poenitz wrote:
> On Tue, Dec 04, 2001 at 09:01:21AM +0100, Juergen Vigna wrote:
> > Well then let me sum for you. We agreed that we should change to a
> > Apply/Ok policy also for the tabular-dialog, but this would involve
> &g
On Tue, Dec 04, 2001 at 09:01:21AM +0100, Juergen Vigna wrote:
> Well then let me sum for you. We agreed that we should change to a
> Apply/Ok policy also for the tabular-dialog, but this would involve
> a major rewrite of the TabularFeatures and the dialog so we decided to
> leave th
we should change to a
Apply/Ok policy also for the tabular-dialog, but this would involve
a major rewrite of the TabularFeatures and the dialog so we decided to
leave this for 1.3.0.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail
On Mon, 3 Dec 2001, Andre Poenitz wrote:
> On Mon, Dec 03, 2001 at 04:06:42PM +0100, Juergen Vigna wrote:
> > > On Mon, Dec 03, 2001 at 03:50:12PM +0100, Andre Poenitz wrote:
> > >> Not having a "Apply/Ok" button there is confusing.
> > > we know...
> >
> > Andre after we had X discussions about
On Mon, Dec 03, 2001 at 04:06:42PM +0100, Juergen Vigna wrote:
> > On Mon, Dec 03, 2001 at 03:50:12PM +0100, Andre Poenitz wrote:
> >> Not having a "Apply/Ok" button there is confusing.
> > we know...
>
> Andre after we had X discussions about this on the mailing-list the
> only answer I can give
On 03-Dec-2001 John Levon wrote:
> On Mon, Dec 03, 2001 at 03:50:12PM +0100, Andre Poenitz wrote:
>
>> Not having a "Apply/Ok" button there is confusing.
>
> we know...
Andre after we had X discussions about this on the mailing-list the
only answer I can give you is: Implement it and it will b
On Mon, Dec 03, 2001 at 03:50:12PM +0100, Andre Poenitz wrote:
> Not having a "Apply/Ok" button there is confusing.
we know...
john
--
"Faced with the prospect of rereading this book, I would rather have
my brains ripped out by a plastic fork."
- Charles Cooper on "Business at the S
Not having a "Apply/Ok" button there is confusing.
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
69 matches
Mail list logo
