On Fri, Jan 02, 2004 at 08:11:05PM +0100, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
> >> Have you considered changing that params2string interface to
> | ...
> >> (or when we are at it even
> >>
> >> ostream & InsetBranchMailer::operator<<(o
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | I'd prefer to leave things as they are until I have a working
>> | export_inset lfun (to post the data through the lyxserver) and a
>> | working register_dialog lfun (so that our dialog is not shown on,
>> | say, a mouse c
Lars Gullik Bjønnes wrote:
> | I'd prefer to leave things as they are until I have a working
> | export_inset lfun (to post the data through the lyxserver) and a
> | working register_dialog lfun (so that our dialog is not shown on,
> | say, a mouse click, but rather the data is posted through the
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
Pass the whole InsetParamsXXX in a boost::any to where it is used.
The sender and the receiver knows the type so now prob. Now all
the mailer code can go.
>>>
>> | You replace 20 lines of code per inset with 20
Lars Gullik Bjønnes wrote:
>>> Pass the whole InsetParamsXXX in a boost::any to where it is used.
>>> The sender and the receiver knows the type so now prob. Now all
>>> the mailer code can go.
>>
> | You replace 20 lines of code per inset with 20 lines of code per
> | inset.
>
> I do not think s
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> | Lars Gullik Bjønnes wrote:
| No it's not. If the data is passed as a string then we allow the
| outside world to receive the data, modify it and post it back
>>>
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
>>> | No it's not. If the data is passed as a string then we allow the
>>> | outside world to receive the data, modify it and post it back
>>> | with no addditional effort to us.
>>>
>>> this
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>> | No it's not. If the data is passed as a string then we allow the
>> | outside world to receive the data, modify it and post it back with
>> | no addditional effort to us.
>>
>> this is the exception (external data), for a
Lars Gullik Bjønnes wrote:
> | No it's not. If the data is passed as a string then we allow the
> | outside world to receive the data, modify it and post it back with
> | no addditional effort to us.
>
> this is the exception (external data), for all internal stuff
> serialization _and_ the mailer
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> | Andre Poenitz wrote:
Have you considered changing that params2string interface to
>> | ...
(or when we are at it even
ostream & InsetBranchMailer::ope
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
>>> Have you considered changing that params2string interface to
> | ...
>>> (or when we are at it even
>>>
>>> ostream & InsetBranchMailer::operator<<(ostream & os,
>>> InsetBranchParams const &)
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>> Have you considered changing that params2string interface to
| ...
>> (or when we are at it even
>>
>> ostream & InsetBranchMailer::operator<<(ostream & os,
>> InsetBranchParams const &)
>> {
>> os << name << ' ';
>> os << name_
On Thu, Dec 11, 2003 at 06:24:16PM +, Angus Leeming wrote:
> > I just happened to notice that M-x accent-hungarian-umluat o does
> > not work in 1.4.0cvs ;-)
>
> Depends how you define 'not working'. Here I get '\H{111}', which is
> nice ;-)
But somewhat surprising for the unsuspecting.
A
Andre Poenitz wrote:
> Not much.
> So look for another playground.
Not my playground anyway. It was you who was bothered by this,
remember. I was sufficiently respectful to take the time to look into
your ideas and sufficiently disrespectful to refute them once I'd
done so ;-)
> I just happene
On Thu, Dec 11, 2003 at 05:57:57PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> In fact, InsetBibitem could have a constructor from a string and user
> code would look like
>
> if (name == "bibitem") {
> return new InsetBibitem(cmd.argument);
>
> I'd rather that we used a free f
Andre Poenitz wrote:
In fact, InsetBibitem could have a constructor from a string and user
code would look like
if (name == "bibitem") {
return new InsetBibitem(cmd.argument);
I'd rather that we used a free function returning 0 if the data was
bogus.
InsetOld * InsetCommandMail
On Thu, Dec 11, 2003 at 09:58:44AM +, Angus Leeming wrote:
> 2. Example usage of string2params, in factory.C's createInset:
>
> case LFUN_INSET_INSERT: {
> string const name = cmd.getArg(0);
>
> if (name == "bibitem") {
> InsetCo
Andre Poenitz wrote:
> Have you considered changing that params2string interface to
...
> (or when we are at it even
>
> ostream & InsetBranchMailer::operator<<(ostream & os,
> InsetBranchParams const &)
> {
> os << name << ' ';
> os << name_ << ' ';
> params.write(os);
> // Add all_branches param
Jose' Matos wrote:
> How about
>
> def convert_note(lines):
> i = 0
> while 1:
> i = find_tokens(lines, ["\\begin_inset Note",
> "\\begin_inset Comment",
> "\\begin_inset Greyedout"], i)
> if i == -1:
> break
>
> lines[i] = lines[i][8:] + 'Note ' + lines[i][:8]
>
> Not tested
On Wednesday 10 December 2003 15:40, Angus Leeming wrote:
>
> \begin_inset Note -> \begin_inset Note Note
> \begin_inset Comment -> \begin_inset Note Comment
> \begin_inset Greyedout -> \begin_inset Note Greyedout
>
> I'll up the file format to 226 and have been thinking about
> lyxconvert_225.py
>
Andre Poenitz wrote:
> Have you considered changing that params2string interface to
> void InsetBranchMailer::params2string(InsetBranchParams const &,
> ostream & data)
> {
> data << name << ' ';
> data << name_ << ' ';
> params.write(data);
>
Jose' Matos wrote:
> On Wednesday 10 December 2003 14:49, Angus Leeming wrote:
>> No need to pass the 'name' to each instance of InsetNoteMailer,
>> InsetBranchMailer as this name is fixed for each Mailer type.
>>
>> Committing now.
>
> Is the fileformat changed?
No, but my next one does chang
On Wed, Dec 10, 2003 at 02:49:15PM +, Angus Leeming wrote:
> No need to pass the 'name' to each instance of InsetNoteMailer,
> InsetBranchMailer as this name is fixed for each Mailer type.
>
> Committing now.
Concerning
-string const InsetBranchMailer::params2string(string const & n
On Wednesday 10 December 2003 14:49, Angus Leeming wrote:
> No need to pass the 'name' to each instance of InsetNoteMailer,
> InsetBranchMailer as this name is fixed for each Mailer type.
>
> Committing now.
Is the fileformat changed?
--
José Abílio
LyX and docbook, a perfect match. :-)
24 matches
Mail list logo
