thanks as always
Andre Poenitz wrote:
On Tue, Oct 23, 2007 at 02:22:33AM -, [EMAIL PROTECTED] wrote:
Modified: lyx-devel/branches/personal/rgheck/icp/src/frontends/qt4/GuiRef.h
URL:
Abdelrazak Younes wrote:
Richard Heck wrote:
Angus Leeming wrote:
Richard Heck wrote:
The attached patch finishes this bit of work, left over from the
InsetCommand conversion. Comments welcome before I commit.
This sort of change gives me a nice, warm, fuzzy feeling. It's obvious
Abdelrazak Younes wrote:
Richard Heck wrote:
The attached patch finishes this bit of work, left over from the
InsetCommand conversion. Comments welcome before I commit.
Looks obviously good ;-)
Next step is to remove the InsetCommandMailer...
That's a different project
rh
Jean-Marc Lasgouttes wrote:
Richard Heck [EMAIL PROTECTED] writes:
Hum, if these are command strings you should not use to_utf8() but
to_ascii().
ok.
Note that the only difference is an assertion if the string is not
ascii. You must therefore be sure that the user can never
Some of what needs fixing here will be fixed in the next commit, e.g.,
whitespace, parentheses.
rh
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Tue Oct 23 17:02:15 2007
New Revision: 21149
URL: http://www.lyx.org/trac/changeset/21149
Log:
InsetInclude becomes an InsetCommand.
Georg Baum wrote:
Richard Heck wrote:
The attached patch finishes this bit of work, left over from the
InsetCommand conversion. Comments welcome before I commit.
I don't have time to read the patch, but this goes definitely into the right
direction. Since I was thinking to do
Andre Poenitz wrote:
On Tue, Oct 23, 2007 at 11:09:20AM -0400, Richard Heck wrote:
Some of what needs fixing here will be fixed in the next commit, e.g.,
whitespace, parentheses.
It usually works the other way round: First fix, then commit. At least
for whitespace etc. this should
Andre Poenitz wrote:
On Tue, Oct 23, 2007 at 11:43:22PM +0200, Pavel Sanda wrote:
hi,
when i press enter in text i get the note character instead of new line.
can anybody confirm ?
slightly different receipt:
1. new file
2. tools preferences, change something so you can use apply
Sorry for the top-post, but, after lots of thought about this, I've come
to the conclusion that Georg is right, and we shouldn't go the way I was
suggesting. There's then a different design problem that arises, but
I'll post a note about that later. That said:
IMHO the text classes are
In reworking the InsetCommand stuff, I've run into the following
problem. Each InsetCommand needs to have an InsetCommandParams to
represent its parameters. At present, it is assumed that the parameters
an InsetCommand accepts are determined statically, by the C++ type of
the inset. For
This is very boring:
CommandInfo const * InsetCommandParams::findInfo(
InsetCode code, std::string const cmdName)
{
switch (code) {
case BIBITEM_CODE:
return InsetBibitem::findInfo(cmdName);
case BIBTEX_CODE:
return InsetBibtex::findInfo(cmdName);
case CITE_CODE:
Subject: Re: footnote in caption
From: Richard Heck [EMAIL PROTECTED]
To: Alexander Sklar [EMAIL PROTECTED]
Date: Wed Oct 24 2007 04:37:30 GMT+0200
Alexander Sklar wrote:
Well...it compiles, but doesn't produced the expected result :) (see
attached pdf, where's the footnote?)
I
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
+bool InsetCommandParams::isCompatibleCommand(
+ InsetCode code, std::string const s)
+{
+ switch (code) {
+ case BIBITEM_CODE:
+ return InsetBibitem::isCompatibleCommand(s);
+ case BIBTEX_CODE:
+
Andre Poenitz wrote:
On Tue, Oct 23, 2007 at 09:49:56PM -0400, Richard Heck wrote:
[snip]
Would it help if all insets knew the buffer they belong to?
That might be enough. But it's not clear to me if this causes problems
with cut and paste.
rh
Andre Poenitz wrote:
In any case, it wouln't help with the typos (Compati_a_ble(
I wrote that message while compiling
rh
Andre Poenitz wrote:
Call a 'register' function from a constructor of a static dummy object.
This is sometimes troublesome with shared objects/older compiler,
though.
Can you sketch this in pseudo code, perhaps? This is beyond my C++
experience.
rh
Abdelrazak Younes wrote:
Richard Heck wrote:
Now, so far as I can see, the un-handled variable here is the current
Buffer. The Buffer will determine the CiteEngine; and if we have
user-defined InsetCommand's, those too will be fixed by the Buffer
(i.e., by the text class and modules). So
Abdelrazak Younes wrote:
Richard Heck wrote:
Jean-Marc Lasgouttes wrote:
[EMAIL PROTECTED] writes:
+bool InsetCommandParams::isCompatibleCommand(
+InsetCode code, std::string const s)
+{
+switch (code) {
+case BIBITEM_CODE: +return
InsetBibitem
Andre Poenitz wrote:
On Wed, Oct 24, 2007 at 12:26:17PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
Call a 'register' function from a constructor of a static dummy object.
This is sometimes troublesome with shared objects/older compiler,
though.
Can you sketch
Andre Poenitz wrote:
On Wed, Oct 24, 2007 at 01:37:06PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
On Wed, Oct 24, 2007 at 12:26:17PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
Call a 'register' function from a constructor of a static dummy object
Andre Poenitz wrote:
On Wed, Oct 24, 2007 at 12:23:54PM -0400, Richard Heck wrote:
Andre Poenitz wrote:
On Tue, Oct 23, 2007 at 09:49:56PM -0400, Richard Heck wrote:
[snip]
Would it help if all insets knew the buffer they belong to?
That might be enough
Every day, and in every way, it gets better and better. (With apologies
to Inspector Dreyfus, not to mention Emile Coue.)
rh
Martin Vermeer wrote:
On Wed, Oct 24, 2007 at 12:38:54PM +0200, Jean-Marc Lasgouttes wrote:
Martin Vermeer [EMAIL PROTECTED] writes:
Ah. But doesn't
Angus Leeming wrote:
Richard Heck [EMAIL PROTECTED] writes:
This is very boring:
CommandInfo const * InsetCommandParams::findInfo(
InsetCode code, std::string const cmdName)
{
switch (code) {
case BIBITEM_CODE:
return InsetBibitem::findInfo(cmdName);
case
Angus Leeming wrote:
Richard Heck [EMAIL PROTECTED] writes:
This is very boring:
CommandInfo const * InsetCommandParams::findInfo(
InsetCode code, std::string const cmdName)
{
switch (code) {
case BIBITEM_CODE:
return InsetBibitem::findInfo(cmdName);
case
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 04:13:58AM -, [EMAIL PROTECTED] wrote:
+ICPInfo::ICPInfo(std::string const s, bool b)
+ : paramName(s), optional(b)
+{}
+
+
+void ICPList::addParam(std::string const s, bool b) {
+ plist_.push_back(ICPInfo(s, b));
+}
+
+
+bool
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
+/// Return parameter information for command cmdName.
+/// Not implemented here. Must be implemented in derived class.
+static CommandInfo const * findInfo(std::string const cmdName);
So make it pure virtual:
vitual CommandInfo
Abdelrazak Younes wrote:
Something like the attached, unfinished, patch
Thanks for these ideas. They'll be useful.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
URL: http://www.lyx.org/trac/changeset/21194
+CommandInfo const * InsetBibitem::findInfo(std::string const /*
cmdName */)
+{
+static const char * const paramnames[] = {label, key, };
+static const bool isoptional[] = {true, false};
+
Alfredo Braunstein wrote:
Andre Poenitz wrote:
That might be enough. But it's not clear to me if this causes problems
with cut and paste.
Sure there will problems, but right now we already have special handling
for e.g. and three hundred inset function or so taking a buffer
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 09:26:31AM -0400, Richard Heck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
+/// Return parameter information for command cmdName.
+/// Not implemented here. Must be implemented in derived class.
+static
Richard Heck wrote:
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 09:26:31AM -0400, Richard Heck wrote:
Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
+ /// Return parameter information for command cmdName.
+ /// Not implemented here. Must be implemented in derived class.
+ static
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 04:17:27PM +0200, Pavel Sanda wrote:
hi,
dont know whether this is according to last changesets or the fact i tried to
use monolithic compilation.
make[6]: Entering directory
`/home/installer/lyx/trunk_disable/src/frontends/qt4'
/bin/sh
Andre Poenitz wrote:
Ugh. So you are planning to reintroduce back pointers?
I am not sure about the whole thing.
If so, it would be something that wouldn't change during an inset's
lifetime, so it should be conceptionally simpler to handle than we had
we the inset parent.
But as I
Andre Poenitz wrote:
On Thu, Oct 25, 2007 at 04:47:17PM -0400, Richard Heck wrote:
vitual CommandInfo const * findInfo(std::string const cmdName) = 0;
I didn't do that because it needs, at least in the base classes, to
be static, and I wanted to indicate here that it needed
Am I right that with the recent changes to InsetIndex, GuiIndex is now
non-functional and could be removed?
rh
Am I right that with the recent changes to InsetIndex, GuiIndex is now
non-functional and could be removed?
rh
Forwarding to lyx-devel.
Original Message
Subject:Small LyX 1.5.2 (OS X only?) ERT bug
Date: Fri, 26 Oct 2007 11:54:09 -0500
From: Chris Menzel [EMAIL PROTECTED]
Reply-To: Chris Menzel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
I suppose it's possible there are connectivity problems between the US
and Down Under, but last night and now today the svn server is
horrendously slow. A two line svn commit seems to be dying due to server
timeout. And I've just tried logging in over ssh as well, and it's
taking over a
Martin Vermeer wrote:
On Fri, Oct 26, 2007 at 01:45:26PM -0400, Richard Heck wrote:
I suppose it's possible there are connectivity problems between the US
and Down Under, but last night and now today the svn server is
horrendously slow. A two line svn commit seems to be dying due to server
Many of these are reasonable ideas. You're welcome to add them to bugzilla.
1. todo tag
puts a tag in (much like a comment), but also adds this to a list of
some sort so that you can switch between items todo
perhaps this todo tag could be placed in the headings to flag a section
as
Alexander Streit wrote:
Something like this is already possible: Type Alt-I, C, start typing,
hit Ctrl-Enter when you get the one you want.
Yes, this works very well! Thanks, I didn't know about this and have been
using the mouse for over 200 pages now, so you've saved me a lot of time!
Some silly comments.
+ /// is this inset based on the CollapsableInset class?
+ virtual InsetCollapsable * asCollapsableInset() { return 0; }
+ /// is this inset based on the CollapsableInset class?
+ virtual InsetCollapsable const * asCollapsableInset() const { return 0;
Martin Vermeer wrote:
On Wed, Oct 31, 2007 at 10:28:04PM +0200, Martin Vermeer wrote:
On Wed, Oct 31, 2007 at 07:53:22PM +0100, Andre Poenitz wrote:
On Wed, Oct 31, 2007 at 06:24:22PM +0200, Martin Vermeer wrote:
// Read a font definition from given file in lyx format
// Used
sebastian guttenberg wrote:
Shall I report bug's here or directly at bugzilla?
There's no fixed rule. But if it's a relatively minor thing, then I'd go
to bugzilla. If it's a crash, or if it's significant enough that it
prevents you from getting work done, then report it here, the idea
Tommaso Cucinotta wrote:
Index: src/ParagraphMetrics.h
===
--- src/ParagraphMetrics.h (revisione 21411)
+++ src/ParagraphMetrics.h (copia locale)
@@ -113,6 +113,7 @@
InsetDims inset_dims_;
};
+
} // namespace
Bo Peng wrote:
Hi, Andre,
What are our rules for preprocessor indentation? Please choose from A,
B, or C from the attache file. I personally prefer B.
I hereby declare that I have no preference. I vote with Andre. ;-)
rh
Cheers,
Bo
Dov Feldstern wrote:
Helge Hafting wrote:
But I can't make more URL's, except by copy+pasting the existing ones.
Edit-charstyle offers code and such from logical markup,
URL is not offered.
URL is in a separate module (not in logical markup). I'm not sure why
this is, though...
If it
Martin Vermeer wrote:
Eh, shouldn't URL rather be in stdinsets? If it's a standard
feature...
That'd be fine with me. Should the URL module then be removed
altogether? If so, then I guess the lyx2lyx would need to be changed, as
well.
Richard
Martin Vermeer wrote:
On Fri, Nov 09, 2007 at 05:18:34PM +, [EMAIL PROTECTED] wrote:
Author: rgheck
Date: Fri Nov 9 18:18:32 2007
New Revision: 21533
URL: http://www.lyx.org/trac/changeset/21533
Log:
Fix URL module.
Modified:
lyx-devel/trunk/lib/layouts/url.module
Modified:
Pavel Sanda wrote:
ui_TextLayoutUi.h: In member function 'void
Ui_TextLayoutUi::setupUi(QWidget*)':
ui_TextLayoutUi.h:154: error: expected primary-expression before '('
token
ui_TextLayoutUi.h:154: error: expected type-specifier
ui_TextLayoutUi.h:154: error: expected `'
ui_TextLayoutUi.h:154:
Tommaso Cucinotta wrote:
Just want to signal a assert/crash when opening EmbeddedObjects.lyx
(actually, I have to
say when computing metrics of some paragraph within that document --
this happens
while opening, in my patch).
The assert seems to fade away by patching insets/InsetInclude.cpp
sebastian guttenberg wrote:
On Tue, 2007-11-13 at 15:55 +0100, Stefan Schimanski wrote:
I did a commit yesterday about this. Have you updated your code?
Stefan
Ah, interesting! Things evolve quickly!
Now I have updated the source, but I get an error during the
make-procedure:
sebastian guttenberg wrote:
Hi all!
A few minutes ago, I wanted to mark a complete numbered equation (of
type eqnarray, with two rows) with the mouse. I clicked directly in
front and moved horizontally over the equation. As a result, not only
the equation, but also the line above and the line
Abdelrazak Younes wrote:
Looks like Fedora 4 and Redhat 9 are still at Qt4.1 but do we care?
Fedora 6 is about to be EOL. That's why Fedora 4 is still Qt4.1. There
haven't been upgrades for it for a year, even security upgrades. So it's
basically dead, and if anyone is still using it, they
Helge Hafting wrote:
URL recently moved from a textstyle to a custom inset. Fine with me.
But it doesn't work, at least not today.
The URL looks fine in LyX, but it is simply exported as
plain text, and url.sty is not used.
I work around this by using ERT for now.
I think putting LatexType
Jean-Marc Lasgouttes wrote:
To be more precise, I agree to upgrade a bit the Qt version at each
release, as long as we keep a version older than the one bleeding edge guys
think is widespread. 4.2.0 is one year old now, and we won't realease
right now, so it is OK.
This seems like a sensible
Richard Heck wrote:
Helge Hafting wrote:
URL recently moved from a textstyle to a custom inset. Fine with me.
But it doesn't work, at least not today.
The URL looks fine in LyX, but it is simply exported as
plain text, and url.sty is not used.
I work around this by using ERT for now.
I think
this, I can just remove the columnsep lines from
this file.
Best,
Richard Heck
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://bobjweil.com/heck
Helge Hafting wrote:
Two of my students, Inge Solvåg and Stian Schie Bergan have written a
java program for editing lyx .layout files.
Fabulous. This could address one of THE most common concerns about LyX.
I'll have a look, too.
Richard
--
Just wanted to say quickly that the tabbed document feature in svn is
excellent, as is the new citation dialog. Nice work indeed.
rh
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
I've figured out what's causing bug 3144 and posted a comment to
bugzilla about it. Someone who knows the code well should now be able to
solve the problem. I don't understand it well enough myself.
Richard
Abdelrazak Younes wrote:
3143 new paragraph doesn't reset text style
3144 text style ignored in many cases
I've sent patches to bugzilla that resolve these for me. They are really
very simple in the end, but they'll need to be checked, especially the
first one.
Richard
--
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
3143 new paragraph doesn't reset text style
Patch for 3143 attached.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
3144 text style ignored in many cases
Patch for 3144 attached.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
3143 new paragraph doesn't reset text style
Patch for 3143 attached.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
3144 text style ignored in many cases
Patch for 3144 attached.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http
Also at bugzilla
The problem seems to have arisen from some changes made during the port
to QT4. I've re-instated some of what was removed---basically, a
timer---and cleaned up a few things as well. In particular, it seems to
me it's not work tracking the location of the original double
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
Abdelrazak Younes wrote:
3143 new paragraph doesn't reset text style
Patch for 3143 attached.
Richard
Index: text3
for the
various mouse events more uniform. Some of them were using double_click
to get information about mouse events instead of simply using the mouse
event itself.
Richard
Jürgen Spitzmüller wrote:
Richard Heck wrote:
Also at bugzilla
Erm, I just fixed that (r17588).
Jürgen
I hereby grant permission to license my contributions to LyX under the Gnu
General Public Licence, version 2 or later.
Richard
Jürgen Spitzmüller wrote:
Richard Heck wrote:
Whoops. Well, do you want to have a quick look at the attached patch
anyway? (This supersedes the previous one.) I
Just a quick question. When I run svn diff, I get a lot of this:
@@ -4,10 +4,10 @@
* Licence details can be found in the file COPYING.
*
* \author Alfredo Braunstein
- * \author Lars Gullik Bjnnes
+ * \author Lars Gullik Bjnnes
* \author John Levon
- * \author Andr�P�itz
- * \author
Here's another idea. Basically, what I've done is added an optional
setFont argument to editXY, so we can call it with setFont = false
during mere mouse movements and still take advantage of its recursion
without messing up the font. setFont then has to be carried through the
whole editXY
Peter Kümmel wrote:
Seems it's all about functions and arguments:
Wenn in einem Ausdrucke, dessen Inhalt nicht beurtheilbar zu sein
braucht, ein einfaches oder zusammengesetztes Zeichen an einer oder
an mehreren Stellen vorkommt, und wir denken es an allen oder einigen
dieser Stellen durch
Peter Kümmel wrote:
Seems it's all about functions and arguments:
Wenn in einem Ausdrucke, dessen Inhalt nicht beurtheilbar zu sein
braucht, ein einfaches oder zusammengesetztes Zeichen an einer oder
an mehreren Stellen vorkommt, und wir denken es an allen oder einigen
dieser Stellen durch
When I go to save a file---save I choose save as---I get all the
directories and file names in the dialog on a single line, with most of
the dialog box empty. This is on FC6. Can anyone confirm this?
If I comment out the line dlg.setFileMode(QFileDialog::AnyFile), then
the dialog looks as
Absolutely sure, no, but I did test it pretty extensively. So I'm pretty
sure.
Richard
Bernhard Roider wrote:
Richard Heck wrote:
When I go to save a file---save I choose save as---I get all the
directories and file names in the dialog on a single line, with most of
the dialog box empty
Jean-Marc Lasgouttes wrote:
Richard Here's another idea. Basically, what I've done is added an
Richard optional setFont argument to editXY, so we can call it with
Richard setFont = false during mere mouse movements and still take
Richard advantage of its recursion without messing up the font.
The attached is intended to resolve bug 3246: OK button disabled when
selecting cross ref with keyboard. A similar problem affected the
TeXInfo dialog, and I have fixed that one, too. My fix is essentially
the same as in the Thesaurus dialog, which did not suffer from this
problem (though it
So what, if anything, do we all need to do to get fast builds out of this?
Peter Kümmel wrote:
Andre Poenitz wrote:
On Tue, Mar 27, 2007 at 08:31:33PM +0200, Peter Kümmel wrote:
OK, I've committed.
Incidently,
if(release)
- set(CMAKE_BUILD_TYPE Release)
+
The attached patch addresses bug 3109: Preferences do not take effect
immediately. Comments requested before I commit.
The issue was that the newcolors_ were being checked against prefcolors_
to make sure the color had changed, but prefcolors_ contained the colors
from the preferences file and
OK, now I've learned about mutable. This seems to be a better patch for
3109. Comments
requested before I commit.
The issue was that the newcolors_ were being checked against prefcolors_
to make sure the color had changed, but prefcolors_ contained the colors
from the preferences file and was not
Abdelrazak Younes wrote:
Richard Heck wrote:
The issue was that the newcolors_ were being checked against prefcolors_
to make sure the color had changed, but prefcolors_ contained the colors
from the preferences file and was not updated when changes were made.
Hence any attempt to revert
The attached patch resolves bug 3381. I am not so much suggesting it at
this point as just asking about it. It needs to be tested on a variety
of systems, in particular with different versions of QT4, before any
further action can be taken. I've posted a message to Trolltech telling
them about
Abdelrazak Younes wrote:
Richard Heck wrote:
Or maybe better: Is there any way to check if we're running under 4.2.3,
I think you can use this :
#if QT_VERSION == 0x040203
...
#endif
But I think it needs to be a run-time check...
rh
I've looked more closely at this and think I should go ahead and commit
the simple patch I sent yesterday:
http://bugzilla.lyx.org/show_bug.cgi?id=3109#c10
It works, and it is perfectly sensible given how the code is currently
organized. So I'll do that later, after adding some comments along the
Can someone give me a quick explanation of the difference between these two?
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
Or maybe better: Is there any way to check if we're running under
4.2.3,
I think you can use this : #if QT_VERSION == 0x040203 ... #endif
Richard But I think it needs to be a run-time check...
Why a run-time check?
Because if we're compiling a binary, we wouldn't know
Discussion of bug 3215
http://bugzilla.lyx.org/show_bug.cgi?id=3215
revealed some problems with the current UI in the graphics dialog.
Attached is a screenshot of an idea for a new organization. The Set
width and Set height checkboxes are enabled only when Scale graphic
is not; when they are
So is the suggestion that I should make the check with #if? If so, can
someone remind me how to do this? I.e, what the QT_VERSION syntax is?
Richard
[EMAIL PROTECTED] wrote:
Quoting Jean-Marc Lasgouttes [EMAIL PROTECTED]:
younes == younes a [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Quoting Andre Poenitz [EMAIL PROTECTED]:
On Thu, Mar 29, 2007 at 05:36:54PM -0400, Richard Heck wrote:
Some discussion with Abdel and my own emerging understanding of what MVC
is all about makes it clear that the code needs to be re-organized. The
real
This is the reply I received from Trolltech regarding the 3381 bug. So
it looks as if we can go ahead and incorporate the simple patch
discussed earlier and hope 4.2.3 doesn't stick around too long.
Committed.
Richard
Original Message
Subject:Re: [Issue N156723]
I've been visting bugzilla from time to time to do bug triage. Suppose I
see a bug, such as 2628, where a request has been made for more
information over two months ago, and there's been no reply. (In this
case, it's also a question about 1.4.1, so) Can I mark this bug
resolved so that I
===
--- QGraphics.C (revision 17651)
+++ QGraphics.C (working copy)
@@ -6,6 +6,7 @@
* \author John Levon
* \author Edwin Leuven
* \author Herbert Voß
+ * \author Richard Heck
*
* Full author contact details are available in file CREDITS
Btw. I just saw that Richard updated our element naming scheme to clearify
this:
http://www.lyx.org/trac/changeset/17644
I wasn't aware of an existing naming scheme.
Well, even if the scheme mentioned there does not really match my
personal preferences it is better than no scheme at
I don't want to be difficult, but this patch does not give correct
behavior. In particular, this is not true:
Assume you have a 2cm x 4cm image and want to have it in double size.
So you would write in the dialog the values 4cm x 8cm but as the
smaller value is taken as border you get as result
Uwe Stöhr wrote:
That is too much black magic IMHO. The fields should _not_ be set
automatically to any number.
But this is what the user expects: When the image has an aspect ratio
of 2 and he enters a 4 as width, the height should of course be set
accordingly. This behaviour is e.g. also
Jean-Marc Lasgouttes wrote:
...I do not think that we should entice people to always use explicit lengths
(centimeters, inches...). Most of the cases, a percentage of column width or
text width is more appropriate IMO. Are people going to get a ruler and
measure the size they want?
This
Richard Of course, one can get those specific settings using the
Richard Text Width %, etc, dimensions. But advanced users might
Richard appreciate the flexibility LaTeX offers here. One option
Richard would be to add to LengthCombo another choice, like
Richard [literal], and allow the
In thinking about LyXLengths and the like, something occurred to me that
I thought I'd share, just in case anyone else comes this way: You can't
in general compare lengths, as LyX understands them. The reason is that
LyX's lengths include units like LaTeX's \lineheight and \textwidth.
(Check,
Comments on this bug welcome: http://bugzilla.lyx.org/show_bug.cgi?id=3416.
How big a problem is this?
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
801 - 900 of 9793 matches
Mail list logo
