On Fri, Jan 19, 2007 at 08:55:06PM +, José Matos wrote:
> On Friday 19 January 2007 4:02:43 pm Jean-Marc Lasgouttes wrote:
> > OK, I'll apply it and tell Jose' that you made me do it if he
> > complains.
>
> Abdel... hum. How were you capable of such thing? ;-)
It's his pretty face. Who can
Great, thanks!
- Martin
On Fri, 19 Jan 2007, Jean-Marc Lasgouttes wrote:
"Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> OK, the trivial version is what I propose for 1.4.x:
Jean-Marc> besides implementing InsetBranch::textString, it fixes an
Jean-Marc> output ord
On Friday 19 January 2007 4:24:55 pm Jean-Marc Lasgouttes wrote:
> I applied both.
Thanks.
> JMarc
--
José Abílio
On Friday 19 January 2007 4:02:43 pm Jean-Marc Lasgouttes wrote:
> OK, I'll apply it and tell Jose' that you made me do it if he
> complains.
Abdel... hum. How were you capable of such thing? ;-)
> JMarc
--
José Abílio
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> OK, the trivial version is what I propose for 1.4.x:
Jean-Marc> besides implementing InsetBranch::textString, it fixes an
Jean-Marc> output order bug in writePlaintextParagraph.
Jean-Marc> The 1.5 version is more com
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> The 1.5 version is more complicated because I took the liberty to
>> cleanup Paragraph::asString (remove two useless versions) and to
>> simplify the InsetBase::textString method.
Abdelrazak> Whaou! Breaking news! JMarc is tak
Jean-Marc Lasgouttes wrote:
"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Jean-Marc, could you do this, as it is near-trivial? I'm again
Martin> having access problems (i.e., its near-complete absence) over
Martin> the extended weekend :-(
OK, the trivial version is what I pro
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Jean-Marc, could you do this, as it is near-trivial? I'm again
Martin> having access problems (i.e., its near-complete absence) over
Martin> the extended weekend :-(
OK, the trivial version is what I propose for 1.4.x: besides
i
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> This is _much_ better. BTW did you notice
Martin> InsetBranch::plaintext()? The infrastructure is there, waiting
Martin> to be used...
My problem was to know whether we should restrict ourselves to the
first paragraph.
Martin>
On Fri, 2007-01-19 at 10:03 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> My original patch is still needed and fixes a useability bug.
> Martin> As I wrote earlier,a ToC containing only numbers is unuseable
> Martin> for navigation o
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> My original patch is still needed and fixes a useability bug.
Martin> As I wrote earlier,a ToC containing only numbers is unuseable
Martin> for navigation or outlining. I verified that it does the job.
I know see what the bug yo
On Thu, 2007-01-18 at 21:09 +0200, Martin Vermeer wrote:
> On Thu, Jan 18, 2007 at 06:59:10PM +0200, Martin Vermeer wrote:
> > On Thu, Jan 18, 2007 at 05:02:20PM +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> > >
> > > >> If you want to take
On Thu, Jan 18, 2007 at 06:59:10PM +0200, Martin Vermeer wrote:
> On Thu, Jan 18, 2007 at 05:02:20PM +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > >> If you want to take in account branches (or more generally nested
> > >> textinset), y
On Thu, Jan 18, 2007 at 05:02:20PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> If you want to take in account branches (or more generally nested
> >> textinset), you should do it completely, I can't believe it is so
> >> difficult.
>
>
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> If you want to take in account branches (or more generally nested
>> textinset), you should do it completely, I can't believe it is so
>> difficult.
Martin> I think branches are the main problem. We don't really need to
Martin> see f
On Thu, Jan 18, 2007 at 03:46:22PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> When I translate the section headers using branches, nothing
> Martin> appears in the ToC, just the number. Text inside a branch
> Martin> inset does not
On Thu, Jan 18, 2007 at 03:46:22PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> When I translate the section headers using branches, nothing
> Martin> appears in the ToC, just the number. Text inside a branch
> Martin> inset does not
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> When I translate the section headers using branches, nothing
Martin> appears in the ToC, just the number. Text inside a branch
Martin> inset does not make it to the ToC or nav menu.
Martin> Attached a fix. With this, the active/
When I translate the section headers using branches, nothing appears in the
ToC, just
the number. Text inside a branch inset does not make it to the ToC or nav menu.
Attached a fix. With this, the active/selected branch(es) will be used to
create the
ToC entry.
- Martin
Index: TocBackend.C
==
InsetBranch is now working fully.
I've minimized the BranchList and LColor APIs.
I've overhauled the Branches code in both frontends.
Result: much cleaner code with 120 lines biting the dust.
Patch attached FYI.
--
Angus
branches.diff.bz2
Description: BZip2 compressed data
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I think you should investigate André's InsetEnv. I believe that
Angus> your "branches" concept is actually a generalisation of it.
Angus> Presumably in one case, you'd want to srap the contents of the
Angus> inset with \begin{commen
On Tuesday 17 June 2003 9:21 am, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I think you should investigate André's InsetEnv. I believe that
> Angus> your "branches" concept is actually a generalisation of it.
> Angus> Presumably in one case,
On Tue, Jun 17, 2003 at 11:21:21AM +0200, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I think you should investigate André's InsetEnv. I believe that
> Angus> your "branches" concept is actually a generalisation of it.
> Angus> Presumably in
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Then, in the Documents dialog, allow the entry of a single
Martin> string, e.g., "Danish, Norwegian". Whenever this string is
Martin> modified, a callback is executed that opens every Note inset
Martin> whose label is a substring
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I think you should investigate André's InsetEnv. I believe that
Angus> your "branches" concept is actually a generalisation of it.
Angus> Presumably in one case, you'd want to srap the contents of the
Angus> inset with \begin{commen
Yann COLLETTE wrote:
Angus Leeming wrote:
Many, many users have requested that we provide better support for
commentary. That is, that we provide the ability to "tune" the output
from InsetNote.
Could we not provide the inset dialog with a check box
[] export to LaTeX
and provide the ab
Angus Leeming wrote:
Many, many users have requested that we provide better support for
commentary. That is, that we provide the ability to "tune" the output
from InsetNote.
Could we not provide the inset dialog with a check box
[] export to LaTeX
and provide the ability to "wrap" this
On Monday 16 June 2003 18:27, John Levon wrote:
>
> > Which, of course, somehow mean we have to get char style working...
>
> *cough* LDM *cough*
You should go to the doctor Jonh, you are coughing too much. ;-)
Are you sure you aren't ill? :-)
> regards
> john
--
José Abílio
Martin Vermeer wrote:
>
> Idea: provide a facility for setting the label of a Note inset. Then
> set it to such a string as "French", "English", "Solutions", "Model
> T" or whatever.
>
> Then, in the Documents dialog, allow the entry of a single string,
> e.g., "Danish, Norwegian". Whenever this
On Mon, Jun 16, 2003 at 03:23:53PM +0200, Michael Schmitt wrote:
> What if you want to introduce a whole table in a particular branch?
Not a problem, the style tag "branch: answers" is inherited.
> Remember the already existing problems that are caused by the fact that
> it makes a difference
On Mon, Jun 16, 2003 at 02:52:05PM +0200, Andre Poenitz wrote:
> I think the implementation should go on top of character styles.
>
> [I don't really care much for the dialog or the UI part, but I do care for
> the innards. And somehow I've not yet seen a compelling reason why
> 'branches' and 'c
Martin Vermeer wrote:
> No, paragraph level is not enough. It should be
> character/pseudo-character level. (If it were only paragraph level,
> it would be a lot simpler...). In my understanding a Note inset can
> be part of a paragraph (?)
Correct.
--
Angus
On Mon, Jun 16, 2003 at 05:45:35PM +0100, Jose' Matos spake thusly:
> On Monday 16 June 2003 16:37, Angus Leeming wrote:
> >
> > I wonder...
> >
> > Many, many users have requested that we provide better support for
> > commentary. That is, that we provide the ability to "tune" the output
> > fro
On Monday 16 June 2003 16:37, Angus Leeming wrote:
>
> I wonder...
>
> Many, many users have requested that we provide better support for
> commentary. That is, that we provide the ability to "tune" the output
> from InsetNote.
>
> Could we not provide the inset dialog with a check box
> []
Andre Poenitz wrote:
> On Mon, Jun 16, 2003 at 04:37:09PM +0100, Angus Leeming wrote:
>> > No. do not overload InsetNote, create a InsetBranch instead.
>>
>> I wonder...
>>
>> Many, many users have requested that we provide better support for
>> commentary. That is, that we provide the ability t
On Mon, Jun 16, 2003 at 04:37:09PM +0100, Angus Leeming wrote:
> > No. do not overload InsetNote, create a InsetBranch instead.
>
> I wonder...
>
> Many, many users have requested that we provide better support for
> commentary. That is, that we provide the ability to "tune" the output
> from I
Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Mon, Jun 16, 2003 at 05:06:53PM +0300, Martin Vermeer wrote:
> | > 3) Can you think of any reason why this (adapting the Note inset
> | > to this as Michael proposes) would be a bad idea? I'm starting
> | > to like it
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Jun 16, 2003 at 05:06:53PM +0300, Martin Vermeer wrote:
| > 3) Can you think of any reason why this (adapting the Note inset
| > to this as Michael proposes) would be a bad idea? I'm starting to like
| > it :-)
|
| No.
|
| Actually just adding
Martin Vermeer wrote:
> Questions:
>
> 1) Can text inside a note have character attributes like size,
> family, series, color, ... which are visually formatted? [sorry, I'm
> behind a text line here, cannot start up CVS LyX]
Yes. A note inset preserves all environment info. It just outputs
nothi
On Mon, Jun 16, 2003 at 03:47:02PM +0200, Andre Poenitz spake thusly:
>
> On Mon, Jun 16, 2003 at 05:06:53PM +0300, Martin Vermeer wrote:
> > 3) Can you think of any reason why this (adapting the Note inset
> > to this as Michael proposes) would be a bad idea? I'm starting to like
> > it :-)
>
>
Martin Vermeer wrote:
1) Can text inside a note have character attributes like size, family,
series, color, ... which are visually formatted? [sorry, I'm behind a
text line here, cannot start up CVS LyX]
Yes! I think you are allowed to put everything inside a note inset. It's
just a kind of con
On Mon, Jun 16, 2003 at 05:06:53PM +0300, Martin Vermeer wrote:
> 3) Can you think of any reason why this (adapting the Note inset
> to this as Michael proposes) would be a bad idea? I'm starting to like
> it :-)
No.
Actually just adding a few flags to InsetNote might be enough.
But Angus propos
On Mon, Jun 16, 2003 at 03:41:02PM +0200, Andre Poenitz spake thusly:
>
> On Mon, Jun 16, 2003 at 05:02:52PM +0300, Martin Vermeer wrote:
> > 1) Can text inside a note have character attributes like size, family,
> > series, color, ... which are visually formatted? [sorry, I'm behind a
> > text l
On Mon, Jun 16, 2003 at 05:02:52PM +0300, Martin Vermeer wrote:
> 1) Can text inside a note have character attributes like size, family,
> series, color, ... which are visually formatted? [sorry, I'm behind a
> text line here, cannot start up CVS LyX]
Yes.
> 2) Can you insert a figure or a table
On Mon, Jun 16, 2003 at 03:23:53PM +0200, Michael Schmitt spake thusly:
...
> >>
> >>
> >I think the implementation should go on top of character styles.
> >Which, of course, somehow mean we have to get char style working...
> >
> Veto! (Last time I used this word, Lars told me I am not allow
Andre Poenitz wrote:
1) A user interface (in document->extra) to define a "branch list",
which contains pairs of branch names (English, Finnish, ...) and
"representation colours" (red, green, magenta, ...). The branch names
are editable and represent the semantics (Michael's proposal). The
represe
On Mon, Jun 16, 2003 at 02:52:05PM +0200, Andre Poenitz spake thusly:
>
> On Mon, Jun 16, 2003 at 04:06:33PM +0300, Martin Vermeer wrote:
> > No. They should be implemented in their own right for the use
> > described in Steve Litt's article. No need to complicate the issue by
> > bringing in cond
On Mon, Jun 16, 2003 at 04:06:33PM +0300, Martin Vermeer wrote:
> No. They should be implemented in their own right for the use
> described in Steve Litt's article. No need to complicate the issue by
> bringing in conditional output, even if you could do that (you would
> have to provide an easy UI
On Mon, Jun 16, 2003 at 12:53:00PM +0200, Andre Poenitz spake thusly:
>
> On Mon, Jun 16, 2003 at 12:39:24PM +0200, Michael Schmitt wrote:
> > Andre Poenitz wrote:
> >
> > >>So now we have three different alternatives:
> > >>
> > >>1. Branching a la Martin
> > >>2. Branching by deactivatable/supp
On Mon, Jun 16, 2003 at 12:39:24PM +0200, Michael Schmitt wrote:
> Andre Poenitz wrote:
>
> >>So now we have three different alternatives:
> >>
> >>1. Branching a la Martin
> >>2. Branching by deactivatable/suppressable insets
> >>3, Branching as change tracking
> >>
> >>
> >4. Branching as cha
Angus Leeming wrote:
> This one is just the "note" inset with some small additional
> mechanism to control when the contents are exported to LaTeX, no?
Or merge the comment environment (which should become an inset anyway) with
the note inset. There could be two or three states of the new inset:
Andre Poenitz wrote:
So now we have three different alternatives:
1. Branching a la Martin
2. Branching by deactivatable/suppressable insets
3, Branching as change tracking
4. Branching as character style.
Or do I miss something?
"Character style" = "Martin's style"
Michael
Michael Schmitt wrote:
> Jean-Marc Lasgouttes wrote:
>
>>SPeaking about change-tracking, is there a reason why the concept of
>>branches is not merged into change-tracking? I would think that the
>>later is a particular type of branches (one branch per user). There
>>is probably some thought invo
On Mon, Jun 16, 2003 at 12:10:50PM +0200, Michael Schmitt wrote:
> Jean-Marc Lasgouttes wrote:
>
> >SPeaking about change-tracking, is there a reason why the concept of
> >branches is not merged into change-tracking? I would think that the
> >later is a particular type of branches (one branch per
Jean-Marc Lasgouttes wrote:
SPeaking about change-tracking, is there a reason why the concept of
branches is not merged into change-tracking? I would think that the
later is a particular type of branches (one branch per user). There is
probably some thought involved, but it seems more reasonable t
On Mon, Jun 16, 2003 at 11:19:30AM +0200, Jean-Marc Lasgouttes spake thusly:
>
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> So you would like to see a possibility to assign a user
> Martin> defined name (like "English") to a branch, and then separately
> Martin> link
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> So you would like to see a possibility to assign a user
Martin> defined name (like "English") to a branch, and then separately
Martin> link a colour to that name? Certainly possible; one step extra
Martin> for the user. And you h
Martin Vermeer wrote:
Ok... if you write the code!
Ha! I expected something like this :-) But no, I won't do it.
I was just musing over the best solution. I agree with Lars that your
approach looks a bit hackish although it might be well-implemented.
Michael
On Fri, Jun 13, 2003 at 12:56:05PM +0200, Michael Schmitt spake thusly:
>
> Martin Vermeer wrote:
>
> >On Fri, Jun 13, 2003 at 10:18:24AM +0200, Michael Schmitt spake thusly:
> >
> >
> >So you would like to see a possibility to assign a user defined name
> >(like "English") to a branch, and the
Martin Vermeer wrote:
On Fri, Jun 13, 2003 at 10:18:24AM +0200, Michael Schmitt spake thusly:
So you would like to see a possibility to assign a user defined name
(like "English") to a branch, and then separately link a colour to
that name? Certainly possible; one step extra for the user. And y
On Fri, Jun 13, 2003 at 10:18:24AM +0200, Michael Schmitt spake thusly:
> >
> >
> >Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> >| So, the implementation is complete now including GUI. I don't find it
> >| particularly elegant though; but it works and is clean, i.e., no dirty
> >| tricks.
> >
Martin Vermeer <[EMAIL PROTECTED]> writes:
| So, the implementation is complete now including GUI. I don't find it
| particularly elegant though; but it works and is clean, i.e., no dirty
| tricks.
Perhaps the implementation is not using dirty tricks, but I must admit
that the whole solution fee
On Thu, Jun 12, 2003 at 08:43:34PM +0100, John Levon spake thusly:
>
> On Thu, Jun 12, 2003 at 11:06:51PM +0300, Martin Vermeer wrote:
>
> > So, the implementation is complete now including GUI. I don't find it
>
> screenshots please
>
> thanks
> john
http://www.hut.fi/~mvermeer/branch
On Thu, Jun 12, 2003 at 09:55:25PM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | So, the implementation is complete now including GUI. I don't find it
> | particularly elegant though; but it works and is clean, i.e., no dirty
> | tricks.
>
> Perhap
Martin Vermeer <[EMAIL PROTECTED]> writes:
| So, the implementation is complete now including GUI. I don't find it
| particularly elegant though; but it works and is clean, i.e., no dirty
| tricks.
Perhaps the implementation is not using dirty tricks, but I must admit
that the whole solution feel
On Thu, Jun 12, 2003 at 11:06:51PM +0300, Martin Vermeer wrote:
> So, the implementation is complete now including GUI. I don't find it
screenshots please
thanks
john
On Thu, Jun 12, 2003 at 09:55:01AM +0300, Martin Vermeer spake thusly:
>
> On Wed, Jun 11, 2003 at 03:29:14PM +0200, Michael Schmitt spake thusly:
> > - ... anything else? ...
>
> - "branches"? Working but lacking a GUI for set-up.
Attached a completed "branches" implementation. Now you can n
67 matches
Mail list logo
