rgheck wrote:
This is along the way to dealing with the InsetTableCell issue. But
even this little bit causes LyX to crash when you try to make a table.
Debugging shows that the problem is in Tabular::init(), at this line:
cell_info = cell_vvector(rows_arg, cell_vector(columns_arg,
CellDat
This is along the way to dealing with the InsetTableCell issue. But even
this little bit causes LyX to crash when you try to make a table.
Debugging shows that the problem is in Tabular::init(), at this line:
cell_info = cell_vvector(rows_arg, cell_vector(columns_arg,
CellData(buf)));
The f
Richard Heck wrote:
>> Ed wrote:
>> ignoring the challenge, i would get rid of those headers all together...
>
> Yes, well, a different project.
like attached ?
Index: src/frontends/qt4/PanelStack.cpp
===
--- src/frontends/qt4/Panel
Edwin Leuven wrote:
Richard Heck wrote:
Could someone have a look at this patch? The idea here is not to
allow the "headers"---the labels that don't correspond to panels---in
these panel stacks to be selected. This is in response to bug 4153.
It's very minor, to be sure, but my question is m
Richard Heck wrote:
Could someone have a look at this patch? The idea here is not to allow
the "headers"---the labels that don't correspond to panels---in these
panel stacks to be selected. This is in response to bug 4153. It's very
minor, to be sure, but my question is more: Why doesn't this
Could someone have a look at this patch? The idea here is not to allow
the "headers"---the labels that don't correspond to panels---in these
panel stacks to be selected. This is in response to bug 4153. It's very
minor, to be sure, but my question is more: Why doesn't this work? As
you'll see
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> What about src/frontends/qt2/ui/moc/Makefile.am,
Georg> src/frontends/qt2/ui/Makefile.am
Georg> src/frontends/qt2/moc/Makefile.am
Georg> ?
Georg> Or did you levae them out on purpose?
Hmmm, do we care? I am not sure what this define
Jean-Marc Lasgouttes wrote:
> Index: src/frontends/qt2/Makefile.am
> ===
> RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/Makefile.am,v
> retrieving revision 1.93
> diff -u -r1.93 Makefile.am
> --- src/frontends/qt2/Make
Le dimanche 8 Août 2004 17:19, Jean-Marc Lasgouttes a écrit :
> I propose to apply this. The only problem I see is that when the locale is
> ar (arabic) or iw (hebrew[*]), all the interface is changed to be
> right-to-left, which looks a bit stupid considering that LyX does not have
> a proper loca
Le dimanche 8 Août 2004 17:33, Lars Gullik Bjønnes a écrit :
> | [*] it appears that we use he for hebrew. So, which one is the right one?
>
> iw(Hebrew, to be removed, see he) ISO 639
So we don't care about problems with the iw locale, right?
Alternatively, I could add a
qApp->setRev
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Le dimanche 8 Août 2004 17:19, Jean-Marc Lasgouttes a écrit :
>> I propose to apply this. The only problem I see is that when the locale is
>> ar (arabic) or iw (hebrew[*]), [...]
>
| It seems that I forgot the footnote, so here it is:
>
| [*] it
Le dimanche 8 Août 2004 17:19, Jean-Marc Lasgouttes a écrit :
> I propose to apply this. The only problem I see is that when the locale is
> ar (arabic) or iw (hebrew[*]), [...]
It seems that I forgot the footnote, so here it is:
[*] it appears that we use he for hebrew. So, which one is the righ
Le dimanche 8 Août 2004 14:15, Georg Baum a écrit :
> It works if you make the translator static:
Thanks to Georg's help, I got it to work in a satisfactory way.
I propose to apply this. The only problem I see is that when the locale is
ar (arabic) or iw (hebrew[*]), all the interface is changed
Le dimanche 8 Août 2004 14:15, Georg Baum a écrit :
> Am Sonntag, 8. August 2004 00:21 schrieb Jean-Marc Lasgouttes:
> > The following patch is supposed to make sure that the qt-internal
> > strings like in the FileDialog or menu shortcuts get translated (at
> > least in german and french, the only
Am Sonntag, 8. August 2004 00:21 schrieb Jean-Marc Lasgouttes:
>
> The following patch is supposed to make sure that the qt-internal
> strings like in the FileDialog or menu shortcuts get translated (at
> least in german and french, the only two translations provided by
> trolltech...)/
They have
The following patch is supposed to make sure that the qt-internal
strings like in the FileDialog or menu shortcuts get translated (at
least in german and french, the only two translations provided by
trolltech...)/
However, although I thought I followed the recipe, it does say that
the translatio
Below is a patch that makes the changes I discussed earlier. It works
except for two bugs :
1) core dump on exit
2) t doesn't complete to anything, but ta will do
I'm stuck on these ones, I would greatly appreciate any help !
thanks
john
Index: lyxfunc.C
=
On 5 Feb 2002, Jean-Marc Lasgouttes wrote:
> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
>
> R> Much better would be if a context sensitive help would open a
> R> documentation file and jump to the right spot automagically. A
> R> "Context Sensitive Help" entry under the help button could d
On Tue, Feb 05, 2002 at 02:42:29PM +0100, Herbert Voss wrote:
> while (true) {
> my position is not important for me, only the ones from
> the users...
> }
unfortunately we as developers have to second-guess what the users as a whole
want, and come up with good compromises. In particular mot
On Tue, Feb 05, 2002 at 01:23:50PM +, Angus Leeming wrote:
> It seems like you are in a minority of one here, Herbert. Here's my take on
> it:
I partly agree with Herbert - there is room for intermediate online help. But this
should
remain short and to the point.
WhatsThis context sensiti
On Tue, Feb 05, 2002 at 01:54:08PM +0100, Herbert Voss wrote:
> toolstips are one thing, every application has it more or
> less. They are okay, but you are _very_ limited in the
> length! The help-button gives you a help whuch is more than
> a tip, it explains some important interaction which th
> "R" == R Lahaye <[EMAIL PROTECTED]> writes:
R> Much better would be if a context sensitive help would open a
R> documentation file and jump to the right spot automagically. A
R> "Context Sensitive Help" entry under the help button could do that.
That's what I proposed with some labels adde
On Tuesday 05 February 2002 1:44 pm, Juergen Spitzmueller wrote:
> Angus Leeming wrote:
> > However, rather than define C_FormTexinfoFeedbackCB, setPreHandler,
> > feedbackCB for every class, you should make these methods part of the
> > FormBase collection of functions. Then the derived classes w
Jean-Marc Lasgouttes wrote:
> Knowing in which forms online help should be given is definitely a
> question of design, yes. It is a matter of user knowing immediately
> how to get help in a dialog.
Presently there is a problem if you quickly want to be remembered
how a certain feature works. Ope
Herbert Voss wrote:
> I never said that in all cases the help files are better than
> tooltips. And I never said that every gui needs a help button.
> But I said that the tabular-, the graphic-, the preferences-,
> a.s.o should have one.
> And don't tell me, that tooltips are really enough help in
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>> A good help system is really needed, but I have to say I am not
>> sure your solution is a good help system.
Herbert> while (true) { my position is not important for me, only the
Herbert> ones from the users... }
... as long as you
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> [Hint] here is one: the tooltips are not accessible with the mouse
>> (I'm not sure this matters much, though).
Angus> What d'ya mean? Sure they are. Have you ever moved your mouse
Angus> over the preferences dialog?
I meant _without
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>> So you say we should implement both and let people select one from
>> prefs? Yuck!
Herbert> cool conclusion ... the users can say: the help-buttons in
Herbert> _some_ of the guis are very fine (do more) or totally
Herbert> bullshit (
Angus Leeming wrote:
> However, rather than define C_FormTexinfoFeedbackCB, setPreHandler,
> feedbackCB for every class, you should make these methods part of the
> FormBase collection of functions. Then the derived classes will need
> only to override the virtual method
Angus, can you give me a
Jean-Marc Lasgouttes wrote:
>>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>>
>
> Herbert> Juergen Spitzmueller wrote:
>
>>>Developers have to decide what is good and bad ui-design.
>>>
>
> Herbert> you are kidding, or do you want to tell me, that one button
> Herbert> is a qu
On Tuesday 05 February 2002 1:31 pm, Jean-Marc Lasgouttes wrote:
> > "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
>
> Herbert> Juergen Spitzmueller wrote:
> >> Developers have to decide what is good and bad ui-design.
>
> Herbert> you are kidding, or do you want to tell me, that one
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> Juergen Spitzmueller wrote:
>> Developers have to decide what is good and bad ui-design.
Herbert> you are kidding, or do you want to tell me, that one button
Herbert> is a question of design ...
Knowing in which forms online h
On Tuesday 05 February 2002 1:13 pm, Herbert Voss wrote:
> Juergen Spitzmueller wrote:
>
> > Developers have to decide what is good and bad ui-design.
>
>
> you are kidding, or do you want to tell me, that one button
> is a question of design ...
>
> > No one besides you knows better what user
Herbert Voss wrote:
> > Developers have to decide what is good and bad ui-design.
>
> you are kidding, or do you want to tell me, that one button
> is a question of design ...
It is of course not the button. It is the approach. But I think you
know this.
Juergen.
Juergen Spitzmueller wrote:
> Developers have to decide what is good and bad ui-design.
you are kidding, or do you want to tell me, that one button
is a question of design ...
> No one besides you knows better what users want when it comes to help.
aha ...
> But UI-design is a thing that i
Jean-Marc Lasgouttes wrote:
>
> Herbert> This is _absolutely_ user-dependent and it will be the best
> Herbert> way to let them decide which is more or less helpful!
>
> So you say we should implement both and let people select one from
> prefs? Yuck!
cool conclusion ...
the users can say: th
Herbert Voss wrote:
> toolstips are one thing, every application has it more or
> less. They are okay, but you are _very_ limited in the
> length! The help-button gives you a help whuch is more than
> a tip, it explains some important interaction which the toolstips
> can't. The next step are the
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes:
Herbert> toolstips are one thing, every application has it more or
Herbert> less. They are okay, but you are _very_ limited in the
Herbert> length! The help-button gives you a help whuch is more than a
Herbert> tip, it explains some impo
Juergen Spitzmueller wrote:
> IMHO a context sensitive help ("tooltips" like we have in preferences)
> is much clearer than a help button, which opens another dialog
> containing nothing else than (non-context-sensitive) tooltips.
>
> So I propose to replace the help stuff by context sensitive
On Tuesday 05 February 2002 11:28 am, Juergen Spitzmueller wrote:
> IMHO a context sensitive help ("tooltips" like we have in preferences)
> is much clearer than a help button, which opens another dialog
> containing nothing else than (non-context-sensitive) tooltips.
>
> So I propose to replac
IMHO a context sensitive help ("tooltips" like we have in preferences)
is much clearer than a help button, which opens another dialog
containing nothing else than (non-context-sensitive) tooltips.
So I propose to replace the help stuff by context sensitive hints. The
attached patch does this f
On Wed, Jan 09, 2002 at 10:41:39AM +, Angus Leeming wrote:
> Actually, this looks suspicious. par_ is the pointer to the paragraph whose
> parameters originally filled the dialog. It should be reset only on a
> restore. I think you want:
> Paragraph const * p = getCurrentParagraph();
On Tuesday 08 January 2002 6:03 pm, John Levon wrote:
> Try the below patch. The ehaviour seems totally random: sometimes a
fixed-width
> cell allows the dialog, sometimes it doesn't. I have NO idea why. Juergen,
Angus,
> can you look please ?
>
> thanks
> john
>
>
> Index: FormParagraph.C
>
On Tuesday 08 January 2002 7:42 pm, John Levon wrote:
> On Tue, Jan 08, 2002 at 07:31:23PM +, Angus Leeming wrote:
[snip future ways forward]
> Again, what is /actually/ wrong with the current code + my patch ? I can't
> see the problem; it seems getCurrentParagraph is returning different pa
On Tue, Jan 08, 2002 at 07:31:23PM +, Angus Leeming wrote:
> > can you look please ?
>
> It seems to me that the fundamental problem here is that we store a pointer
> to a paragraph in this dialog as our unit of comparison. Really we should be
> storing a paragraphParameters instance.
wel
On Tuesday 08 January 2002 6:03 pm, John Levon wrote:
> Try the below patch. The ehaviour seems totally random: sometimes a
fixed-width
> cell allows the dialog, sometimes it doesn't. I have NO idea why. Juergen,
Angus,
> can you look please ?
>
> thanks
> john
It seems to me that the fundamen
Try the below patch. The ehaviour seems totally random: sometimes a fixed-width
cell allows the dialog, sometimes it doesn't. I have NO idea why. Juergen, Angus,
can you look please ?
thanks
john
Index: FormParagraph.C
===
RCS fil
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> ... but maybe put the HD manufacturers out of business
Applied.
JMarc
On 15 Jun 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | ... but maybe put the HD manufacturers out of business
>
> As long as we don't remove it from CVS.
>
> What do others say?
Ooooh, I don't know. It definitely needs to stay in CVS.
It would be nice to trim
John Levon <[EMAIL PROTECTED]> writes:
| ... but maybe put the HD manufacturers out of business
As long as we don't remove it from CVS.
What do others say?
--
Lgb
... but maybe put the HD manufacturers out of business
thanks
john
--
"Research is not a warm puppy. At least, I hope not."
- David Rydeheard
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
re
51 matches
Mail list logo
