Le 28/09/2015 19:56, Jürgen Spitzmüller a écrit :
Am Montag 28 September 2015, 04:11:37 schrieb Guillaume Munch:
The attached patch includes the above features along with other
enhancements like a symbol that indicates disabled entries. (See
description.) OK to commit?
Looks very good. Thanks.
Am Montag 28 September 2015, 04:11:37 schrieb Guillaume Munch:
> The attached patch includes the above features along with other
> enhancements like a symbol that indicates disabled entries. (See
> description.) OK to commit?
Looks very good. Thanks.
Jürgen
Le 18/09/2015 16:06, Cyrille Artho a écrit :
Jürgen Spitzmüller wrote:
2015-09-18 2:37 GMT+02:00 Guillaume Munch mailto:g...@lyx.org>>:
And in fact, I'd also like to navigate there directly. > >
Navigation would be analoguous to sections that have subsections,
so > this
Jürgen Spitzmüller wrote:
2015-09-18 2:37 GMT+02:00 Guillaume Munch mailto:g...@lyx.org>>:
And in fact, I'd also like to navigate there directly. > >
Navigation would be analoguous to sections that have subsections,
so > this seems just right to me. > >> Do you have a sit
o the table if > you want to edit it).
>
> Actually it would make sense to show the float, but put the cursor inside
> the caption. For instance if the caption is at the bottom of the float, the
> screen would be filled with the bottom part of the float and the cursor
> would be at th
Sorry for the formatting issues, I don't know what happened.
From http://www.lyx.org/trac/ticket/9759 :
#9759: "List of figures" navigation menu is not convenient
-+
Reporter: gadmm| Owner: gadmm
Type: defect
From http://www.lyx.org/trac/ticket/9759 :
Le 16/09/2015 09:06, LyX Ticket Tracker a écrit :
#9759: "List of figures" navigation menu is not convenient > -+ Reporter: gadmm >
| Owner: gadmm Type: defect | Status
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>>>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
| Georg> Angus Leeming wrote:
>>> Jean-Marc Lasgouttes wrote:
>>>> The two solutions I see are Figure/Table (use the G
>>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Angus Leeming wrote:
>> Jean-Marc Lasgouttes wrote:
>>> The two solutions I see are Figure/Table (use the GUIName of the
>>> float) or "List of Figures"/"List of
Angus Leeming wrote:
> Jean-Marc Lasgouttes wrote:
>> The two solutions I see are Figure/Table (use the GUIName of the
>> float) or "List of Figures"/"List of Tables" (we have this string
>> too).
>
>> Which one would you prefer?
>
> "List of Figures"/"List of Tables"
Me too.
Georg
Jean-Marc Lasgouttes wrote:
> The two solutions I see are Figure/Table (use the GUIName of the
> float) or "List of Figures"/"List of Tables" (we have this string
> too).
> Which one would you prefer?
"List of Figures"/"List of Tables"
--
Angus
>>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I noticed that the Navigate menu contains "figure" and "table"
Georg> (all frontends). I think that this should be "figures" and
Georg> "tables".
The
Juergen Spitzmueller wrote:
> Unfortunately, I cannot verify if it works with gtk, because my gtkmm etc.
> libs (and pkg-config) are totally messed up since the recent distro
> update. But it compiles (this I could verify at least).
>
> I'd propose to shove it in, so that someone with working gtk
Georg Baum wrote:
> I was wondering about the recent encoding related changes. Can I still use
> fromqstr/toqstr everywhere?
I didn't encounter any problems by now. But OTOH I didn't really follow the
encoding changes.
Jürgen
Juergen Spitzmueller wrote:
> Georg Baum wrote:
>> Is the attached patch the
>> correct solution?
>
> Yes.
I was wondering about the recent encoding related changes. Can I still use
fromqstr/toqstr everywhere?
Georg
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| Unfortunately it does not compile for qt :-( Is the attached patch
| the correct solution?
Lars> Hmm does this mean that the check J-M added to avoid using
Lars> implict conversion operators with Qt does not work?
That's what I wa
Georg Baum wrote:
> Unfortunately it does not compile for qt :-(
Oops. It compiles here.
> Is the attached patch the
> correct solution?
Yes.
Thanks,
Jürgen
Georg Baum <[EMAIL PROTECTED]> writes:
| Juergen Spitzmueller wrote:
>
>> Unfortunately, I cannot verify if it works with gtk, because my gtkmm etc.
>> libs (and pkg-config) are totally messed up since the recent distro
>> update. But it compiles (this I could verify at least).
>
| Unfortunately i
Juergen Spitzmueller wrote:
> Unfortunately, I cannot verify if it works with gtk, because my gtkmm etc.
> libs (and pkg-config) are totally messed up since the recent distro
> update. But it compiles (this I could verify at least).
Unfortunately it does not compile for qt :-( Is the attached pat
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> This looks good. It is verified (i.e. you have tested it) that this
>> works for all frontends and fix the original problem that triggered
>> this, then please commit it.
>
| Unfortunately, I cannot verify if it works
Lars Gullik Bjønnes wrote:
> This looks good. It is verified (i.e. you have tested it) that this
> works for all frontends and fix the original problem that triggered
> this, then please commit it.
Unfortunately, I cannot verify if it works with gtk, because my gtkmm etc.
libs (and pkg-config) ar
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> And getGuiName should never be used for any comparisons... just to be
>> displayed. So imo the translation should be done there...
>>
>> -... but... if the change to make that happen is "largish" then I'd go
>> with
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Lars Gullik Bjønnes wrote:
>> And getGuiName should never be used for any comparisons... just to
>> be displayed. So imo the translation should be done there...
>>
>> -... but... if the change to make that happen is "lar
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> Do you plan to adapt it to 1.3.7cvs?
Juergen> If I still have the energy once this is in.
:)
I have to say that you have been very patient on this one...
JMarc
Juergen Spitzmueller wrote:
> Not at all. It's not more than the attached.
Loverly!
--
Angus
Jean-Marc Lasgouttes wrote:
> Do you plan to adapt it to 1.3.7cvs?
If I still have the energy once this is in.
Jürgen
Lars Gullik Bjønnes wrote:
> And getGuiName should never be used for any comparisons... just to be
> displayed. So imo the translation should be done there...
>
> -... but... if the change to make that happen is "largish" then I'd go
> with this proposed change and try to fix it proper in 1.5.
No
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>> Why is "Table of Contents" not translated?
>
| Because the result of getGuiName gets translated in the frontends. You cannot
| translate a string twice, can you?
| BTW, the string "Table of Contents" is marked in several o
Angus Leeming <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
>
>> But I guess you know by now that adding random transformation (like
>> trim()) in helper functions just because you are lazy is not always a
>> good idea ;)
>
| Of course, getGuiName(...) suggests a transformation whereas
Jean-Marc Lasgouttes wrote:
> But I guess you know by now that adding random transformation (like
> trim()) in helper functions just because you are lazy is not always a
> good idea ;)
Of course, getGuiName(...) suggests a transformation whereas getString
doesn't imply a trim. getTrimmedString, h
Angus Leeming wrote:
> Why is "Table of Contents" not translated?
Because the result of getGuiName gets translated in the frontends. You cannot
translate a string twice, can you?
BTW, the string "Table of Contents" is marked in several other places, e.g. in
QToc, GToc, FormToc. So it's already t
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Why is "Table of Contents" not translated? I guess that this
Angus> question stems from my disbelief that you don't translate these
Angus> strings until you get to QToc.C, etc.
It is part of the fix to the bug. It happens that it w
Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
>> Jean-Marc Lasgouttes wrote:
>> > Except that I do not think this requires to create a vector. But I may
>> > be mistaken.
>>
>> No, you're right. I'm just about to implement this.
>
> Attached.
+string const getGuiName(string const & t
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Attached. But I cannot compile gtk at the moment, so somebody
Juergen> has to test and adjust this.
Juergen> Better?
It looks very good to me. Do you plan to adapt it to 1.3.7cvs?
JMarc
Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
> > Except that I do not think this requires to create a vector. But I may
> > be mistaken.
>
> No, you're right. I'm just about to implement this.
Attached. But I cannot compile gtk at the moment, so somebody has to test and
adjust this.
Jean-Marc Lasgouttes wrote:
> Except that I do not think this requires to create a vector. But I may
> be mistaken.
No, you're right. I'm just about to implement this.
Jürgen
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> Isn't it possible to use the index in the combox? This would avoid
>> comparing translated strings, wouldn't it?
Juergen> But the index differs depending on what kind of floats the
Juergen>
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> Isn't it possible to use the index in the combox? This would avoid
>> comparing translated strings, wouldn't it?
Angus> Isn't that the "store a vector of "identifier strings"
Angus> solution? Ie, use the combox index as the identifier
Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
>> Isn't it possible to use the index in the combox? This would avoid
>> comparing translated strings, wouldn't it?
>
> But the index differs depending on what kind of floats the document has.
> Or do I misunderstand you?
But for a given
Jean-Marc Lasgouttes wrote:
> Isn't it possible to use the index in the combox? This would avoid
> comparing translated strings, wouldn't it?
But the index differs depending on what kind of floats the document has. Or do
I misunderstand you?
Jürgen
Jean-Marc Lasgouttes wrote:
> Juergen> I had a look at this again. The problem is that we only have
> Juergen> the translated names (from the combo) if we are requesting
> Juergen> the contents of the toc browser. Since we cannot just
> Juergen> "translate back", the only alternative to compare aga
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> I had a look at this again. The problem is that we only have
Juergen> the translated names (from the combo) if we are requesting
Juergen> the contents of the toc browser. Since we cannot just
Juergen> "translate back", th
Juergen Spitzmueller wrote:
> Angus Leeming wrote:
>> Haven't looked at the patch, but this is something that we do elsewhere.
>> The clean and elegant solution, IMO, would be to have a LyXComboBox that
>> derives from (or stores internally --- probably better) QComboBox which
>> would store the "
Angus Leeming wrote:
> Haven't looked at the patch, but this is something that we do elsewhere.
> The clean and elegant solution, IMO, would be to have a LyXComboBox that
> derives from (or stores internally --- probably better) QComboBox which
> would store the "identifier" string. QComboBox would
Juergen Spitzmueller wrote:
> I had a look at this again. The problem is that we only have the
> translated names (from the combo) if we are requesting the contents of
> the toc browser. Since we cannot just "translate back", the only
> alternative to compare against translated strings is, AFAICS,
Jean-Marc Lasgouttes wrote:
> I do not like this much:
>
> + FloatList::const_iterator it = floats.begin();
> + FloatList::const_iterator end = floats.end();
> + if (guiname == _("Table of Contents"))
> + return "TOC";
> + for (; it != end; ++it) {
> +
Jean-Marc Lasgouttes wrote:
> Juergen> You are probably right. I think about it a soon as I find
> Juergen> time. What about the patch for 1.3.6?
>
> Yes, it is OK.
I committed that, so that 1.3.6 can be released :-)
I'm a bit busy with real work at the moment, but I will come back to the
1.4-pat
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> You are probably right. I think about it a soon as I find
Juergen> time. What about the patch for 1.3.6?
Yes, it is OK.
JMarc
Jean-Marc Lasgouttes wrote:
> You should never have to compare against a translated value. I think
> GUIName should be untranslated, and all translation should happen in
> the frontends.
>
> So basically, I'd try to avoid using gettext at all in toc.C.
You are probably right. I think about it a so
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> I would really like to see a patch where only the type of float is
>> used internally, and the GUI name is only for displaying.
Juergen> I decided to do this properly now (use no translatab
Jean-Marc Lasgouttes wrote:
> I would really like to see a patch where only the type of float is
> used internally, and the GUI name is only for displaying.
I decided to do this properly now (use no translatable strings internally).
Some new funtions were needed. See attached patch.
For 1.3.6, I
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote: Yes. See my second patch.
>> I saw that after sending my message. I prefer this version for
>> 1.3.6cvs.
Juergen> Which? The second?
Juergen> Does that mean the (second) patch can be committ
Jean-Marc Lasgouttes wrote:
> Juergen> Yes. See my second patch.
>
> I saw that after sending my message. I prefer this version for
> 1.3.6cvs.
Which? The second?
Does that mean the (second) patch can be committed?
Jürgen
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> What about floats().getType(type).name() where floats is a member
>> of the textclass?
Juergen> Yes. See my second patch.
I saw that after sending my message. I prefer this version for
1
Jean-Marc Lasgouttes wrote:
> What about
> floats().getType(type).name()
> where floats is a member of the textclass?
Yes. See my second patch.
> Juergen> Jean-Marc, this could also be a candidate for 1.3.6.
>
> I would really like to see a patch where only the type of float is
> used internall
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> http://bugzilla.lyx.org/show_bug.cgi?id=1870 The problem was
Juergen> that we compared two different string types (GuiName and
Juergen> type), one of which is translatable, moreover.
Juergen> The attached patch fixes it.
Juergen Spitzmueller wrote:
> The attached patch fixes it. It would be cleaner if there was a method to
> get the GuiName from the type, but I have found no such method.
Attached is a more general, IMO better solution. For 1.3.6, maybe the first
patch would do.
Jürgen
Index: toc.C
==
http://bugzilla.lyx.org/show_bug.cgi?id=1870
The problem was that we compared two different string types (GuiName and
type), one of which is translatable, moreover.
The attached patch fixes it. It would be cleaner if there was a method to get
the GuiName from the type, but I have found no such
On Sun, Oct 06, 2002 at 12:53:27PM +0200, I Wayan Warmada wrote:
>
> Dear LyX-users,
> I have a problem with the list of figures in LyX-1.3.0cvs. The long title
> of the figures is not wrapped correctly (over the page boundary). Could
> you please explain me how to solve the
x
Sven> (attached) and select view dvi. Look at the figure-description
Sven> in chapter 1 (page 4 or so). There's a "\dot m"-formula, which
Sven> is all right in the .dvi file. Look now at the list of figures
Sven> (page 3 or so) of the .dvi file, there's a strange
a "\dot
m"-formula, which is all right in the .dvi file.
Look now at the list of figures (page 3 or so) of the .dvi file, there's a strange
combination of characters, but no "\dot m" at all.
Any ideas ? Problem of LyX or a problem of TeX ?
best regards and go on with you
61 matches
Mail list logo
