On Wed, May 18, 2005 at 11:05:03PM +0200, Michael Schmitt wrote:
> 4. "Accept All Changes" and "Revert All Changes" should be atomic
> operations; otherwise "undo" is a real pain
This one's filed already
john
On Sat, May 21, 2005 at 02:47:05PM +0200, Michael Schmitt wrote:
> John, speak to us - we are awaiting your approval.
I just got off a long couple of flights from the US, I'm afraid you must
wait a little longer until I can see properly :)
john
On Mon, May 16, 2005 at 09:22:27AM +0200, Andre Poenitz wrote:
QSettings gives us e.g. (transparent) access to the Windows registry,
where all the Window native programs put there configuration stuff and
everybody expects it. When not using Qt we've a choice of either
programming this access
On Mon, May 16, 2005 at 04:36:21PM +0200, Michael Schmitt wrote:
Please check the patch carefully (John L.?) and commit it. Regarding the
use of ..., please note the following excerpt from the GNOME human
interface guidelines:
Label the menu item with a trailing ellipsis (...) only if
On Mon, May 16, 2005 at 03:42:23PM +0200, Andre Poenitz wrote:
They seemingly learned a lesson or two. Qt 4 is conceptionally much
cleaner than Qt 3 and older.
That's encouraging to hear, I suppose.
Surely you agree that the hard, time consuming stuff is in the core, and
it always has
On Mon, May 16, 2005 at 06:08:03PM +0200, Michael Schmitt wrote:
Unfortunately, I was over-ruled (by jmarc iirc) regarding the
interpretation of this. In particular, in LyX ellipses mean this will
bring up a dialog. I abide by the judge's decision :)
John + Michael = 2, Jean - Marc = 1.
On Mon, May 16, 2005 at 09:55:18PM +0200, Andre Poenitz wrote:
ControlBranch.C (for example) is pretty trivial,
[To a degree that make one wonder whether it is explicitly needed at all
... but you are right.]
I admit to be speaking from a position of ignorance wrt Qt 4, so I could
well be
On Mon, May 16, 2005 at 09:22:27AM +0200, Andre Poenitz wrote:
> QSettings gives us e.g. (transparent) access to the Windows registry,
> where all the Window native programs put there configuration stuff and
> "everybody" expects it. When not using Qt we've a choice of either
> programming this
On Mon, May 16, 2005 at 04:36:21PM +0200, Michael Schmitt wrote:
> Please check the patch carefully (John L.?) and commit it. Regarding the
> use of "...", please note the following excerpt from the GNOME human
> interface guidelines:
>
> "Label the menu item with a trailing ellipsis ("...")
On Mon, May 16, 2005 at 03:42:23PM +0200, Andre Poenitz wrote:
> They seemingly learned a lesson or two. Qt 4 is conceptionally much
> cleaner than Qt 3 and older.
That's encouraging to hear, I suppose.
> > Surely you agree that the hard, time consuming stuff is in the core, and
> > it always
On Mon, May 16, 2005 at 06:08:03PM +0200, Michael Schmitt wrote:
> >Unfortunately, I was over-ruled (by jmarc iirc) regarding the
> >interpretation of this. In particular, in LyX ellipses mean "this will
> >bring up a dialog". I abide by the judge's decision :)
> >
>
> John + Michael = 2, Jean -
On Mon, May 16, 2005 at 09:55:18PM +0200, Andre Poenitz wrote:
> > ControlBranch.C (for example) is pretty trivial,
>
> [To a degree that make one wonder whether it is explicitly needed at all
> ... but you are right.]
I admit to be speaking from a position of ignorance wrt Qt 4, so I could
On Sat, May 14, 2005 at 09:01:37PM +0200, Andre Poenitz wrote:
The GUI-I investment has already payed off by separating GUI and core.
Right now and in a foreseeable future, it will be a burden. A big one.
I see no evidence of this. When has it been a burden since Angus did the
dialogs nicely?
On Sun, May 15, 2005 at 08:01:50PM +0200, Andre Poenitz wrote:
I see no evidence of this. When has it been a burden since Angus did
the dialogs nicely?
It prevents us from using all the platform abstraction Qt would give us
for free. QSettings, QProcess etc. We have to use our own
On Sat, May 14, 2005 at 09:01:37PM +0200, Andre Poenitz wrote:
> The GUI-I investment has already payed off by separating GUI and core.
> Right now and in a foreseeable future, it will be a burden. A big one.
I see no evidence of this. When has it been a burden since Angus did the
dialogs
On Sun, May 15, 2005 at 08:01:50PM +0200, Andre Poenitz wrote:
> > I see no evidence of this. When has it been a burden since Angus did
> > the dialogs nicely?
>
> It prevents us from using all the platform abstraction Qt would give us
> for free. QSettings, QProcess etc. We have to use our own
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
So why not solve that he other way round: Do not blink the cursor unless
all draws have been finished?
I thought that's what Martin was planning (and it certainly sounds
right)
regards
john
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote:
OK, but that tells us also something about the current state of
incompleteness of GUI-I. Ideally, the front ends should only define a
set of primitives that the rest of LyX then uses. I am thinking of a
termcap type
On Sat, May 14, 2005 at 03:08:12PM +0200, Hammer Armin wrote:
I think I know what you mean. After digging in the code, perhaps
the lyx preferences file would be a better place to store and retrieve
the geometry settings.
We'd need to implement the session saving code that happens when e.g.
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote:
Yes... but then we should try to move them closer together again. Yes,
some differences will remain. We should certainly have only one
translatable string copy -- located in the common part outside the front
ends -- for every
On Sat, May 14, 2005 at 03:52:00PM +0100, Angus Leeming wrote:
This patch, part I, changes nothing in LyX's operation. Well actually,
that's not quite true; it enables the Qt Alert dialogs to know who their
parent is so that dialogs are stacked in the correct order.
Alarm bells are
On Sat, May 14, 2005 at 04:28:52PM +0100, Angus Leeming wrote:
Given that the QDialog destroys itself (the WDestructiveClose flag is set)
Yes, that's the ticket.
john
On Fri, May 13, 2005 at 09:25:31PM +0200, Andre Poenitz wrote:
> So why not solve that he other way round: Do not blink the cursor unless
> all draws have been finished?
I thought that's what Martin was planning (and it certainly sounds
right)
regards
john
On Sat, May 14, 2005 at 03:57:23PM +0300, Martin Vermeer wrote:
> OK, but that tells us also something about the current state of
> incompleteness of GUI-I. Ideally, the front ends should only define a
> set of primitives that the rest of LyX then uses. I am thinking of a
> termcap type
On Sat, May 14, 2005 at 03:08:12PM +0200, Hammer Armin wrote:
> I think I know what you mean. After digging in the code, perhaps
> the lyx "preferences" file would be a better place to store and retrieve
> the geometry settings.
We'd need to implement the session saving code that happens when
On Sat, May 14, 2005 at 05:19:54PM +0300, Martin Vermeer wrote:
> Yes... but then we should try to move them closer together again. Yes,
> some differences will remain. We should certainly have only one
> translatable string copy -- located in the common part outside the front
> ends -- for every
On Sat, May 14, 2005 at 03:52:00PM +0100, Angus Leeming wrote:
> >> This patch, part I, changes nothing in LyX's operation. Well actually,
> >> that's not quite true; it enables the Qt Alert dialogs to know who their
> >> parent is so that dialogs are stacked in the correct order.
> >
> > Alarm
On Sat, May 14, 2005 at 04:28:52PM +0100, Angus Leeming wrote:
> Given that the QDialog destroys itself (the WDestructiveClose flag is set)
Yes, that's the ticket.
john
On Thu, May 12, 2005 at 07:22:31PM +0100, Angus Leeming wrote:
This patch, part I, changes nothing in LyX's operation. Well actually,
that's not quite true; it enables the Qt Alert dialogs to know who their
parent is so that dialogs are stacked in the correct order.
Alarm bells are ringing.
On Thu, May 12, 2005 at 07:22:31PM +0100, Angus Leeming wrote:
> This patch, part I, changes nothing in LyX's operation. Well actually,
> that's not quite true; it enables the Qt Alert dialogs to know who their
> parent is so that dialogs are stacked in the correct order.
Alarm bells are
On Wed, May 11, 2005 at 04:58:47PM +0300, Martin Vermeer wrote:
Does anyone have an idea how the input order reversal could come about?
Again, are there any guarantees that the X queue gives events back in
time order?
I believe there is not, but Qt should be dealing with that for us by
On Wed, May 11, 2005 at 06:12:53PM +0300, Martin Vermeer wrote:
What came back was the original problem why sync_events was introduced:
when scrolling fast in big documents (PageDown) the screen update
doesn't keep up.
- // You are not expected to understand this. This forces Qt
-
On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
When was this flag introduced to Qt?
john
On Wed, May 11, 2005 at 04:28:02PM +0100, Angus Leeming wrote:
H. Rather than process all pending draw events fully, is it sufficient
to process the last draw event and discard the earlier ones? Ie, we should
be computing the metrics() on each page-down, but we should draw() only if
On Wed, May 11, 2005 at 04:57:11PM +0100, John Levon wrote:
On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
qApp-eventLoop()-processEvents(QEventLoop::ExcludeUserInput);
When was this flag introduced to Qt?
Has to be said that I don't see any of the problems about
On Wed, May 11, 2005 at 05:07:28PM +0100, John Levon wrote:
Has to be said that I don't see any of the problems about drawing
with current CVS...
But I do see the keypress re-ordering.
john
On Wed, May 11, 2005 at 07:07:26PM +0300, Martin Vermeer wrote:
When was this flag introduced to Qt?
3.1.
OK, then we need to make that the minimum Qt version we support,
finally. Pity about Qt/Win Free or whatever it was but there's not much
we can do otherwise.
regards
john
On Wed, May 11, 2005 at 07:44:30PM +0200, Jean-Marc Lasgouttes wrote:
Martin Patch attached. Please commit, this is your baby.
Feel free to do it, I am busy now. I guess you should guard it with
#if QTVERSION = 0x030100
so that older qt will only suffer from drawing glitches.
What about
On Wed, May 11, 2005 at 10:34:37PM +0300, Martin Vermeer wrote:
I think Jean-Marc wants to eliminate processEvents altogether for older
Qt. Then we will only suffer the drawing glitches that you objected so
vehemently against. I think a reasonable Faustian deal against forcing
people back to
On Wed, May 11, 2005 at 04:58:47PM +0300, Martin Vermeer wrote:
> Does anyone have an idea how the input order reversal could come about?
> Again, are there any guarantees that the X queue gives events back in
> time order?
I believe there is not, but Qt should be dealing with that for us by
On Wed, May 11, 2005 at 06:12:53PM +0300, Martin Vermeer wrote:
> What came back was the original problem why sync_events was introduced:
> when scrolling fast in big documents (PageDown) the screen update
> doesn't keep up.
>
> - // You are not expected to understand this. This forces Qt
On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
> qApp->eventLoop()->processEvents(QEventLoop::ExcludeUserInput);
When was this flag introduced to Qt?
john
On Wed, May 11, 2005 at 04:28:02PM +0100, Angus Leeming wrote:
> H. Rather than process all pending draw events fully, is it sufficient
> to process the last draw event and discard the earlier ones? Ie, we should
> be computing the metrics() on each page-down, but we should draw() only if
On Wed, May 11, 2005 at 04:57:11PM +0100, John Levon wrote:
> On Wed, May 11, 2005 at 05:05:47PM +0200, Jean-Marc Lasgouttes wrote:
>
> > qApp->eventLoop()->processEvents(QEventLoop::ExcludeUserInput);
>
> When was this flag introduced to Qt?
Has to be said that I don't
On Wed, May 11, 2005 at 05:07:28PM +0100, John Levon wrote:
> Has to be said that I don't see any of the problems about drawing
> with current CVS...
But I do see the keypress re-ordering.
john
On Wed, May 11, 2005 at 07:07:26PM +0300, Martin Vermeer wrote:
> > When was this flag introduced to Qt?
>
> 3.1.
OK, then we need to make that the minimum Qt version we support,
finally. Pity about Qt/Win Free or whatever it was but there's not much
we can do otherwise.
regards
john
On Wed, May 11, 2005 at 07:44:30PM +0200, Jean-Marc Lasgouttes wrote:
> Martin> Patch attached. Please commit, this is your baby.
>
> Feel free to do it, I am busy now. I guess you should guard it with
> #if QTVERSION >= 0x030100
> so that older qt will "only" suffer from drawing glitches.
On Wed, May 11, 2005 at 10:34:37PM +0300, Martin Vermeer wrote:
> I think Jean-Marc wants to eliminate processEvents altogether for older
> Qt. Then we will "only" suffer the drawing glitches that you objected so
> vehemently against. I think a reasonable Faustian deal against forcing
> people
On Tue, May 10, 2005 at 10:03:30AM +0300, Martin Vermeer wrote:
I tested the situations where the processEvents() call had been added,
to see if the reasons for doing so were still valid: I found none. The
symbol panel scrollbar in the math dialog; at least the tabular dialog
refresh; and
On Tue, May 10, 2005 at 05:05:39PM +0200, Jean-Marc Lasgouttes wrote:
I am not sure whether I want to block _all_ signals. I am not even
sure of what signals are fired, actually. I guess I'll stick to a bool
guard.
Just setUpdatesEnabled(false) ?
john
On Tue, May 10, 2005 at 08:05:39PM +0200, Michael Schmitt wrote:
Well, the question is whether Refs makes any sense to the user. What
would you expect Refs to do? Probably not to jump to the associated
label (note: label, not labels).
Anyway, I let you take the final decision...
It makes
On Tue, May 10, 2005 at 10:03:30AM +0300, Martin Vermeer wrote:
> I tested the situations where the processEvents() call had been added,
> to see if the reasons for doing so were still valid: I found none. The
> symbol panel scrollbar in the math dialog; at least the tabular dialog
> refresh; and
On Tue, May 10, 2005 at 05:05:39PM +0200, Jean-Marc Lasgouttes wrote:
> I am not sure whether I want to block _all_ signals. I am not even
> sure of what signals are fired, actually. I guess I'll stick to a bool
> guard.
Just setUpdatesEnabled(false) ?
john
On Tue, May 10, 2005 at 08:05:39PM +0200, Michael Schmitt wrote:
> Well, the question is whether "Refs" makes any sense to the user. What
> would you expect "Refs" to do? Probably not to jump to the associated
> label (note: label, not labels).
>
> Anyway, I let you take the final decision...
On Mon, May 09, 2005 at 10:58:51AM +0200, Lars Gullik Bj?nnes wrote:
| On Thu, May 05, 2005 at 05:23:56PM +0100, Angus Leeming wrote:
Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
| No, it means what it says, one before the start of the array in this
| case.
On Mon, May 09, 2005 at 05:27:47PM +0200, Asger Alstrup wrote:
What I fail to understand is how such thinks can be invoked during an
update.
Right, that's what I'm missing from Martin's explanation too. We can
only get such problems if we enter the event loop during an update.
john
On Mon, May 09, 2005 at 07:40:13PM +0300, Martin Vermeer wrote:
#4 0x080a48f2 in boost::assertion_failed (expr=0x83a8359 updating,
function=0x83c8f00 CoordCacheBaseInsetBase CoordCache::insets(),
file=0x83bcf51 ../../src/coordcache.h, line=131) at boost.C:56
#5 0x081d072a in
On Mon, May 09, 2005 at 07:50:56PM +0300, Martin Vermeer wrote:
#35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
john
On Mon, May 09, 2005 at 08:42:57PM +0300, Martin Vermeer wrote:
#35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
Meaning, in teletubby english?
We can't update any widgets at all during update(). All
On Mon, May 09, 2005 at 09:13:03PM +0300, Martin Vermeer wrote:
We can't update any widgets at all during update(). All the changing of
the environment drop down (say, to 'Section' when moving the cursor) has
to be done after the fact.
Not in my test case. All cells of the table are
On Mon, May 09, 2005 at 08:43:31PM +0200, Andre Poenitz wrote:
Asger suggested IIRC (and meanwhile I agree) not to have any incoming
keystrokes at all during an update. Given that we currently explicitly
asked for these by calling processEvents, the simple solution would be
not to call
On Mon, May 09, 2005 at 10:58:51AM +0200, Lars Gullik Bj?nnes wrote:
> | On Thu, May 05, 2005 at 05:23:56PM +0100, Angus Leeming wrote:
> >
> >> Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
> >
> | No, it means what it says, one before the start of the array in this
> |
On Mon, May 09, 2005 at 05:27:47PM +0200, Asger Alstrup wrote:
> What I fail to understand is how such thinks can be invoked during an
> update.
Right, that's what I'm missing from Martin's explanation too. We can
only get such problems if we enter the event loop during an update.
john
On Mon, May 09, 2005 at 07:40:13PM +0300, Martin Vermeer wrote:
> #4 0x080a48f2 in boost::assertion_failed (expr=0x83a8359 "updating",
> function=0x83c8f00 "CoordCacheBase& CoordCache::insets()",
> file=0x83bcf51 "../../src/coordcache.h", line=131) at boost.C:56
> #5 0x081d072a in
On Mon, May 09, 2005 at 07:50:56PM +0300, Martin Vermeer wrote:
> #35 0x027b2f94 in QWidget::setUpdatesEnabled ()
And thus, we have our black beast.
My guess is the environment drop down update.
john
On Mon, May 09, 2005 at 08:42:57PM +0300, Martin Vermeer wrote:
> > > #35 0x027b2f94 in QWidget::setUpdatesEnabled ()
> >
> > And thus, we have our black beast.
> >
> > My guess is the environment drop down update.
>
> Meaning, in teletubby english?
We can't update any widgets at all during
On Mon, May 09, 2005 at 09:13:03PM +0300, Martin Vermeer wrote:
> > We can't update any widgets at all during update(). All the changing of
> > the environment drop down (say, to 'Section' when moving the cursor) has
> > to be done after the fact.
>
> Not in my test case. All cells of the table
On Mon, May 09, 2005 at 08:43:31PM +0200, Andre Poenitz wrote:
> Asger suggested IIRC (and meanwhile I agree) not to have any incoming
> keystrokes at all during an update. Given that we currently explicitly
> asked for these by calling processEvents, the simple solution would be
> not to call
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
sync_events appears to be called on each and every blink of the cursor:
void LyXScreen::showCursor(BufferView bv)
{
// You are not expected to understand this. This forces Qt
// (the problem case) to deal with
On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
But... isn't this cursor drawing and hiding an asynchronous process
taking place every 400 msec? What happens if a drawing activity takes
longer than 400 (800?) msec and the cursor comes back all of itself in
the middle of it?
Note the line marked with !!!. This workAreaKeyPress shows btw up in
the backtrace of a nested update call.
Why are we calling workAreaKeyPress() during an update?
I don't care how the dialog manage to rebuild there sizes if the core
crashes.
The core didn't used to crash in 1.3. You
On Sun, May 08, 2005 at 10:28:59PM +0200, Andre Poenitz wrote:
What about removing cursor and cursor blinking timer at the begin of
update and start a new timer with a shown cursorat the end of update?
Sounds very sensible to me.
regards
john
On Sun, May 08, 2005 at 03:50:56PM +0100, Angus Leeming wrote:
> sync_events appears to be called on each and every blink of the cursor:
> void LyXScreen::showCursor(BufferView & bv)
> {
> // You are not expected to understand this. This forces Qt
> // (the problem case) to deal
On Sun, May 08, 2005 at 10:37:33PM +0300, Martin Vermeer wrote:
> But... isn't this cursor drawing and hiding an asynchronous process
> taking place every 400 msec? What happens if a drawing activity takes
> longer than 400 (800?) msec and the cursor comes back all of itself in
> the middle of
> Note the line marked with !!!. This workAreaKeyPress shows btw up in
> the backtrace of a nested update call.
Why are we calling workAreaKeyPress() during an update?
> I don't care how the dialog manage to rebuild there sizes if the core
> crashes.
The core didn't used to crash in 1.3. You
On Sun, May 08, 2005 at 10:28:59PM +0200, Andre Poenitz wrote:
> What about removing cursor and cursor blinking timer at the begin of
> update and start a new timer with a shown cursorat the end of update?
Sounds very sensible to me.
regards
john
On Sat, May 07, 2005 at 12:40:08PM +0200, Michael Schmitt wrote:
the menu entry NavigateRefs in LyX 1.3 is misleading, because the
user expects to navigate to the next reference in the document. Instead,
Refs lets the user jump from a reference to its corresponding label.
(Actually, I
On Sat, May 07, 2005 at 05:58:52PM +0200, Michael Schmitt wrote:
This is called 'Goto Reference'[1] in 1.4, we need to harmonise any
changes.
Don't worry. I will send a corresponding LyX 1.4 patch in a few seconds.
We still want the 'Goto'.
I've no idea why we have this but not the
On Sat, May 07, 2005 at 06:08:11PM +0200, Michael Schmitt wrote:
here are a few more text changes for LyX 1.4 (partly ported from the 1.3
branch). Once again, the objective is GUI consistency.
Looks fine
john
On Sat, May 07, 2005 at 12:40:08PM +0200, Michael Schmitt wrote:
> the menu entry "Navigate>Refs" in LyX 1.3 is misleading, because the
> user expects to navigate to the next reference in the document. Instead,
> "Refs" lets the user jump from a reference to its corresponding label.
>
On Sat, May 07, 2005 at 05:58:52PM +0200, Michael Schmitt wrote:
> >This is called 'Goto Reference'[1] in 1.4, we need to harmonise any
> >changes.
> >
> Don't worry. I will send a corresponding LyX 1.4 patch in a few seconds.
We still want the 'Goto'.
> >I've no idea why we have this but not
On Sat, May 07, 2005 at 06:08:11PM +0200, Michael Schmitt wrote:
> here are a few more text changes for LyX 1.4 (partly ported from the 1.3
> branch). Once again, the objective is GUI consistency.
Looks fine
john
On Fri, May 06, 2005 at 07:08:06PM +0200, Georg Baum wrote:
I think the patch is nice, but as non-native english speaker I can not
really judge the text changes. Was there consensus that they are good
Sorry, can I see the text changes again??
john
On Fri, May 06, 2005 at 07:21:27PM +0200, Georg Baum wrote:
Index: ui/BiblioModuleBase.ui
Seems OK to me.
john
On Fri, May 06, 2005 at 07:08:06PM +0200, Georg Baum wrote:
> I think the patch is nice, but as non-native english speaker I can not
> really judge the text changes. Was there consensus that they are good
Sorry, can I see the text changes again??
john
On Fri, May 06, 2005 at 07:21:27PM +0200, Georg Baum wrote:
> Index: ui/BiblioModuleBase.ui
Seems OK to me.
john
On Thu, May 05, 2005 at 05:23:56PM +0100, Angus Leeming wrote:
Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
No, it means what it says, one before the start of the array in this
case.
john
On Thu, May 05, 2005 at 05:23:56PM +0100, Angus Leeming wrote:
> Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
No, it means what it says, one before the start of the array in this
case.
john
On Thu, Apr 28, 2005 at 11:06:37AM +0200, Georg Baum wrote:
Let me rephrase: The concept of non-fatal warnings as opposed to fatal
errors does not exist in the error handling machinery: Errors are only
shown if something went wrong, if they are shown they are marked as
Error, and there is no
On Thu, Apr 28, 2005 at 11:06:37AM +0200, Georg Baum wrote:
> Let me rephrase: The concept of non-fatal warnings as opposed to fatal
> errors does not exist in the error handling machinery: Errors are only
> shown if something went wrong, if they are shown they are marked as
> "Error", and there
On Tue, Apr 26, 2005 at 07:28:15PM +0200, Georg Baum wrote:
http://bugzilla.lyx.org/show_bug.cgi?id=1591 for the full story):
1) insert synthetic warnings into the error list
The problem is that (AFAIK) 1) implies that such documents won't compile at
all anymore, and that is certainly not
On Tue, Apr 26, 2005 at 08:11:43PM +0200, Georg Baum wrote:
The problem is that (AFAIK) 1) implies that such documents won't compile
at all anymore, and that is certainly not what Cengiz wanted.
Why does it imply this?
As far as I know the code we only have errorlists for real errors,
On Tue, Apr 26, 2005 at 07:28:15PM +0200, Georg Baum wrote:
> http://bugzilla.lyx.org/show_bug.cgi?id=1591 for the full story):
>
> 1) insert synthetic warnings into the error list
>
> The problem is that (AFAIK) 1) implies that such documents won't compile at
> all anymore, and that is
On Tue, Apr 26, 2005 at 08:11:43PM +0200, Georg Baum wrote:
> >> The problem is that (AFAIK) 1) implies that such documents won't compile
> >> at all anymore, and that is certainly not what Cengiz wanted.
> >
> > Why does it imply this?
>
> As far as I know the code we only have errorlists for
On Fri, Apr 22, 2005 at 01:57:46PM -0400, Rob Bearman wrote:
By the way, I think the converter dialog is suboptimal UI. To add a
converter, I have to select an existing one and edit it, pressing the
Add button only at the end of the process. Because of this intuitively
backwards approach, the
On Fri, Apr 22, 2005 at 08:23:33PM +0200, Juergen Spitzmueller wrote:
confused nearly everyone. IMO the new ui is much better, though not perfect
yet (we probably need subdialogs).
Yes, we need a subdialog a la Insert Citation Reference
regards
john
On Fri, Apr 22, 2005 at 01:57:46PM -0400, Rob Bearman wrote:
> By the way, I think the converter dialog is suboptimal UI. To add a
> converter, I have to select an existing one and edit it, pressing the
> Add button only at the end of the process. Because of this intuitively
> backwards approach,
On Fri, Apr 22, 2005 at 08:23:33PM +0200, Juergen Spitzmueller wrote:
> confused nearly everyone. IMO the new ui is much better, though not perfect
> yet (we probably need subdialogs).
Yes, we need a subdialog a la Insert Citation Reference
regards
john
On Wed, Apr 20, 2005 at 10:18:16PM +0200, Helge Hafting wrote:
I believe removing those arguments should be default, I don't think
there is any particular table size much more common than others.
So there is no good default. Insert-tabular is great, because
one can get the table correctly
On Wed, Apr 20, 2005 at 10:18:16PM +0200, Helge Hafting wrote:
> I believe removing those arguments should be default, I don't think
> there is any particular table size much more common than others.
> So there is no good default. Insert->tabular is great, because
> one can get the table
701 - 800 of 13943 matches
Mail list logo
