Re: Python help needed ;-)
Jose' Matos wrote: > On Wednesday 04 June 2003 13:45, Angus Leeming wrote: >> >> Not quite. If the second ExternalInset is of Template "Date" (no >> filename) then the result is >> \begin_inset External >> template Date >> filename taulogo.png >> >> where taulogo.png is filename from the first ExternalInset. >> >> Is there a filename.erase() or something? > > Now if the filename is empty that field doesn't appear, ok? Correct. I think that the increment of 'i' should differ in the two cases though. The snippet below works perfectly. Many thanks for your help. def convert_external(lines): external_rexp = re.compile(r'\\begin_inset External ([^,]*),"([^"]*)",') top = "\\begin_inset External" i = 0 while 1: i = find_token(lines, top, i) if i == -1: break look = external_rexp.search(lines[i]) args = ['',''] if look: args[0] = look.group(1) args[1] = look.group(2) #FIXME: if the previous search fails then warn template = "\ttemplate " + args[0] if args[1]: filename = "\tfilename " + args[1] lines[i:i+1] = [top, template, filename] i=i+2 else: lines[i:i+1] = [top, template] i = i + 1 -- Angus
Re: preamble
On Wed, Jun 04, 2003 at 12:01:39PM +0200, Jean-Marc Lasgouttes wrote: > Of course. But if we decide to put the preamble in the document > itself, then forcing it to be in some place will really be a hack > (additional ugly code for no use), whereas allowing several preamble And think about the first paragraph being "Title". I don't think the inset stuff will sit well. Also, fixing the ERT editing would be a preerequisite imho - that is, a newline in ERT is literal instead of a paragraph break, and we allow completely free spacing in ERT ,which we don't right now regards john
Re: [patch] undo/redo
On Wed, Jun 04, 2003 at 01:55:01PM +0200, Lars Gullik Bjønnes wrote: > No... (well yes... but) > > I'd like all the NO_STD_LIST stuff to be removed in a patch of its own > first. I'll do that if you like. Would be kind. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] undo/redo
Andre Poenitz <[EMAIL PROTECTED]> writes: | This brings back undo (and redo...) to a somewhat working state. | | The most prominent flaw is that the cursor is placed at the beginning | of the first paragraph touched by the undo in the main paragraph list. | | This means undo currently leaves all minipages/tabulars/whatever | [Pretty much the same situation as we had with math all the time, so | I know this is annyoing...] | | Internally I had to change the ParIterator container from stack to vector | as I needed access to the 'bottom' as well. | | This can be reverted as soon as we have 'per inset undo' back. | | Ok? No... (well yes... but) I'd like all the NO_STD_LIST stuff to be removed in a patch of its own first. I'll do that if you like. -- Lgb
Re: Python help needed ;-)
On Wednesday 04 June 2003 13:45, Angus Leeming wrote: > > Not quite. If the second ExternalInset is of Template "Date" (no filename) > then the result is > \begin_inset External > template Date > filename taulogo.png > > where taulogo.png is filename from the first ExternalInset. > > Is there a filename.erase() or something? Now if the filename is empty that field doesn't appear, ok? def convert_external(lines): external_rexp = re.compile(r'\\begin_inset External (.*),"(.*)",') i = 0 while 1: i = find_token(lines, "\\begin_inset External", i) if i == -1: break look = external_rexp.search(lines[i]) top = "\\begin_inset External" args = ['',''] if look: args[0] = look.group(1) args[1] = look.group(2) #FIXME: if the previous search fails then warn template = "\ttemplate " + args[0] if args[1]: filename = "\tfilename " + args[1] lines[i:i+1] = [top, template, filename] else: lines[i:i+1] = [top, template] i = i + 1 -- José Abílio
Re: Python help needed ;-)
Jose' Matos wrote: > On Wednesday 04 June 2003 13:29, Angus Leeming wrote: >> [snip...] >> >> Thanks José. Thanks Dekel. >> >> I amalgamated your suggestions. Attached. >> >> It works fine, but I have a couple of (three) questions: > > def convert_external(lines): > external_rexp = re.compile(r'\\begin_inset External (.*),"(.*)",') > i = 0 > while 1: > i = find_token(lines, "\\begin_inset External", i) > if i == -1: > break > look = external_rexp.search(lines[i]) > top = "\\begin_inset External" > args = ['',''] > if look: > args[0] = look.group(1) > args[1] = look.group(2) > #FIXME: if the previous search fails then warn > template = "\ttemplate " + args[0] > if args[1]: > filename = "\tfilename " + args[1] > lines[i:i+1] = [top, template, filename] > i = i + 1 Not quite. If the second ExternalInset is of Template "Date" (no filename) then the result is \begin_inset External template Date filename taulogo.png where taulogo.png is filename from the first ExternalInset. Is there a filename.erase() or something? -- Angus
Re: Python help needed ;-)
On Wednesday 04 June 2003 13:29, Angus Leeming wrote: > [snip...] > > Thanks José. Thanks Dekel. > > I amalgamated your suggestions. Attached. > > It works fine, but I have a couple of (three) questions: def convert_external(lines): external_rexp = re.compile(r'\\begin_inset External (.*),"(.*)",') i = 0 while 1: i = find_token(lines, "\\begin_inset External", i) if i == -1: break look = external_rexp.search(lines[i]) top = "\\begin_inset External" args = ['',''] if look: args[0] = look.group(1) args[1] = look.group(2) #FIXME: if the previous search fails then warn template = "\ttemplate " + args[0] if args[1]: filename = "\tfilename " + args[1] lines[i:i+1] = [top, template, filename] i = i + 1 > 1. Can I add the header variable into the expression searched by the regex > engine? Rather than write it out again. Would be more elegant. Look bellow. > 2. In sed I would write "(.*)" as "\([^"]*\)". Ie include everthing that is > not a '"' rather than include everything. > > It is much more efficient in sed. Is the same not true in python? If so, > what is the syntax? Honestly I don't even think about efficiency here, but yes I can do the same. > 3. Ideally I would not output the filename if it is empty (as occurs with > the Date template. How to do that? I did that also above, the test will suceed only if the string is not empty. Notice that in python " and ' are indentical for string containers (this is different from Perl). So if you don't want to escape those quotes use '. -- José Abílio
Re: A File class
Andre Poenitz wrote: > On Wed, Jun 04, 2003 at 01:20:27PM +0200, Lars Gullik Bjønnes wrote: >> Hmm the bag says: "Blended & Packed by R. Twinning & Company Limited, >> London, England." >> >> So I guess it you who export all the stuff "not worthy of the name". > > Guess why they export it ;-) ;-) No, Twinings is good. It's Lipton's Yellow Label that makes hairs grow on my tongue. English name but found only outside England. Foul stuff. -- Angus
Re: Python help needed ;-)
Jose' Matos wrote: >> Could someone write the 5 lines of code? Plase? > > def convert_external(lines): [snip...] Thanks José. Thanks Dekel. I amalgamated your suggestions. Attached. It works fine, but I have a couple of (three) questions: 1. Can I add the header variable into the expression searched by the regex engine? Rather than write it out again. Would be more elegant. 2. In sed I would write "(.*)" as "\([^"]*\)". Ie include everthing that is not a '"' rather than include everything. It is much more efficient in sed. Is the same not true in python? If so, what is the syntax? 3. Ideally I would not output the filename if it is empty (as occurs with the Date template. How to do that? def convert_external(lines): header="\\begin_inset External" i = 0 while 1: i = find_token(lines, header, i) if i == -1: break mo = re.search(r'\\begin_inset External (.*),"(.*)",', lines[i]) if mo: template = "\ttemplate " + mo.group(1) filename = "\tfilename \"" + mo.group(2) + "\"" lines[i:i+1] = [header, template, filename] i = i + 1 -- Angus? lib/reLyX-safe Index: lib/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/ChangeLog,v retrieving revision 1.447 diff -u -p -r1.447 ChangeLog --- lib/ChangeLog 4 Jun 2003 09:16:28 - 1.447 +++ lib/ChangeLog 4 Jun 2003 11:21:04 - @@ -1,3 +1,9 @@ +2003-06-04 Angus Leeming <[EMAIL PROTECTED]> + + * lyx2lyx/lyx2lyx: bump the output format to 224. + * lyx2lyx/lyxconvert_221.py (convert_external): new function. + An amalgamation of suggestions from José Matos and Dekel Tsur. + 2003-06-03 Angus Leeming <[EMAIL PROTECTED]> * external_templates: modify the templates to use the converter" mechanism. Index: lib/lyx2lyx/lyx2lyx === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyx2lyx,v retrieving revision 1.8 diff -u -p -r1.8 lyx2lyx --- lib/lyx2lyx/lyx2lyx 14 Mar 2003 13:37:34 - 1.8 +++ lib/lyx2lyx/lyx2lyx 4 Jun 2003 11:21:06 - @@ -37,7 +37,7 @@ opt.quiet = 0 format = re.compile(r"(\d)[\.,]?(\d\d)") fileformat = re.compile(r"\\lyxformat\s*(\S*)") -lst_ft = ["210", "215", "216", "217", "218", "220", "221", "223"] +lst_ft = ["210", "215", "216", "217", "218", "220", "221", "224"] def usage(): print """Usage: lyx2lyx [options] file1 Index: lib/lyx2lyx/lyxconvert_221.py === RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/lyx2lyx/lyxconvert_221.py,v retrieving revision 1.5 diff -u -p -r1.5 lyxconvert_221.py --- lib/lyx2lyx/lyxconvert_221.py 2 Jun 2003 14:16:17 - 1.5 +++ lib/lyx2lyx/lyxconvert_221.py 4 Jun 2003 11:21:06 - @@ -16,6 +16,7 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. import string +import re from parser_tools import find_token def add_end(header): @@ -38,11 +39,26 @@ def remove_insetparent(lines): break del lines[i:i+3] +def convert_external(lines): +header="\\begin_inset External" +i = 0 +while 1: +i = find_token(lines, header, i) +if i == -1: +break +mo = re.search(r'\\begin_inset External (.*),"(.*)",', lines[i]) +if mo: +template = "\ttemplate " + mo.group(1) +filename = "\tfilename \"" + mo.group(2) + "\"" +lines[i:i+1] = [header, template, filename] +i = i + 1 + def convert(header, body): add_end(header) convert_spaces(body) convert_bibtex(body) remove_insetparent(body) +convert_external(body) if __name__ == "__main__": pass
Re: A File class
On Wed, Jun 04, 2003 at 01:20:27PM +0200, Lars Gullik Bjønnes wrote: > Hmm the bag says: "Blended & Packed by R. Twinning & Company Limited, > London, England." > > So I guess it you who export all the stuff "not worthy of the name". Guess why they export it ;-) Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
[patch] undo/redo
This brings back undo (and redo...) to a somewhat working state. The most prominent flaw is that the cursor is placed at the beginning of the first paragraph touched by the undo in the main paragraph list. This means undo currently leaves all minipages/tabulars/whatever [Pretty much the same situation as we had with math all the time, so I know this is annyoing...] Internally I had to change the ParIterator container from stack to vector as I needed access to the 'bottom' as well. This can be reverted as soon as we have 'per inset undo' back. Ok? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...) Index: Makefile.am === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/Makefile.am,v retrieving revision 1.176 diff -u -p -r1.176 Makefile.am --- Makefile.am 29 May 2003 11:19:50 - 1.176 +++ Makefile.am 4 Jun 2003 11:14:05 - @@ -79,6 +79,7 @@ lyx_SOURCES = \ MenuBackend.h \ paragraph_funcs.C \ paragraph_funcs.h \ + ParagraphList.C \ ParagraphList.h \ ParagraphParameters.C \ ParagraphParameters.h \ Index: ParagraphList.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ParagraphList.h,v retrieving revision 1.19 diff -u -p -r1.19 ParagraphList.h --- ParagraphList.h 28 May 2003 06:47:14 - 1.19 +++ ParagraphList.h 4 Jun 2003 11:14:05 - @@ -3,165 +3,24 @@ #ifndef PARAGRAPH_LIST_H #define PARAGRAPH_LIST_H -//#define NO_STD_LIST 1 - -#ifndef NO_STD_LIST - #include "paragraph.h" #include -struct ParagraphList : public std::list -{ -}; - -typedef std::pair PitPosPair; - -#else - -class Paragraph; - -#include -#include - -/// -class ParagraphList { -public: - /// - class iterator { - public: - friend class ParagraphList; - /// - typedef std::bidirectional_iterator_tag iterator_category; - /// - typedef Paragraph * value_type; - /// - typedef ptrdiff_t difference_type; - /// - typedef Paragraph * pointer; - /// - typedef Paragraph & reference; - /// - iterator(); - /// - reference operator*(); - /// - pointer operator->(); - /// - iterator & operator++(); - /// - iterator operator++(int); - /// - iterator & operator--(); - /// - iterator operator--(int); - private: - /// - iterator(value_type); - /// - Paragraph * ptr; - }; - /// - class const_iterator { - public: - friend class ParagraphList; - /// - typedef std::bidirectional_iterator_tag iterator_category; - /// - typedef Paragraph * value_type; - /// - typedef ptrdiff_t difference_type; - /// - typedef Paragraph const * const_pointer; - /// - typedef Paragraph const & const_reference; - /// - const_iterator(); - /// - const_reference operator*(); - /// - const_pointer operator->(); - /// - const_iterator & operator++(); - /// - const_iterator operator++(int); - /// - const_iterator & operator--(); - /// - const_iterator operator--(int); - private: - /// - const_iterator(value_type); - /// - Paragraph * ptr; - }; - /// +struct ParagraphList : public std::list { + /// clear id_ ParagraphList(); - /// - ParagraphList(ParagraphList const &); - /// - ParagraphList & operator=(ParagraphList const &); - /// - iterator insert(iterator it, Paragraph const & par); - /// - void insert(iterator pos, iterator beg, iterator end); - /// - void assign(iterator beg, iterator end); - /// - void splice(iterator pos, ParagraphList & pl); - /// - void clear(); - /// - iterator erase(iterator it); - /// - iterator erase(iterator first, iterator last); - /// - iterator begin(); - /// - const_iterator begin() const; - /// - iterator end(); - /// - const_iterator end() const; - /// - void push_back(Paragraph const &); - /// - Paragraph const & front() const; - /// - Paragraph & front()
Re: A File class
Angus Leeming <[EMAIL PROTECTED]> writes: | Calm! The English drink tea for this reason. Of course, you foreigners have | nothing worthy of the name so I suggest you go "Om" instead ;-) Hmm the bag says: "Blended & Packed by R. Twinning & Company Limited, London, England." So I guess it you who export all the stuff "not worthy of the name". But I drink it anyway! -- Lgb
Re: 45443-343556
Please see the attached file.
Re: A File class
Lars Gullik Bjønnes wrote: > | I am talking about how LyX stores/outputs references to external > | files. That is the only interaction I am interested in here. > | > | Actually, what other interest does LyX have in files? > > We read them, we write them, we check if they are there, we iterate > over directories, we search for files, we delete files, we delete > directories. we move from relative to absolute paths and back again... Then we are talking about another class entirely. I think that the two can co-exist quite happily but that this "class to interact with files" is entirely orthogonal to my suggested "class to store how LyX should output a filename having stored it internally with an absolute path". > | If you want to implement the FileName class using boost::filesystem, > | fine. But IMO that is an implementation detail. > > And I asked you to have a look... not more... it was dismissed as > bloat... No. I said that it would be bloat to use such a thing in this instance. For reasons that I hope are now clear. > I am just getting tired of such comments... it does not matter that > you only do it once, when everybody else does it once (or twice) as > well... Calm! The English drink tea for this reason. Of course, you foreigners have nothing worthy of the name so I suggest you go "Om" instead ;-) -- Angus
Re: A File class
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | | > Angus Leeming <[EMAIL PROTECTED]> writes: | > | > | Lars Gullik Bjønnes wrote: | > | | > | > Andre Poenitz <[EMAIL PROTECTED]> writes: | > | > | > | > | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote: | > | > | > Opinions? | > | > | | > | > | Good. | > | > | > | > I think you should have a look at boost::filesystem and see how that | > | > fits. | > | | > | I _knew_ you would say that. Angus buys himself a beer. | > | | > | My entire point was that our requirements here are _very_ simple. Is the | > | filename input as relative to the buffer path? | > | > This is graphics/external only, please obtain a broader picture. | | I am talking about how LyX stores/outputs references to external files. | That is the only interaction I am interested in here. | | Actually, what other interest does LyX have in files? We read them, we write them, we check if they are there, we iterate over directories, we search for files, we delete files, we delete directories. we move from relative to absolute paths and back again... | > | If so output it relative to | > | that path. Always storing it internally as an absolute path guarantees | > | that we won't screw up as we move an inset between buffers. | > | | > | That's it. No need for a pile more bloat. | > | > a nice function there and new function and class there, let's add | > another function... oh we need this as well all solved at the same | > time with a nice lib. | | If you want to implement the FileName class using boost::filesystem, fine. | But IMO that is an implementation detail. And I asked you to have a look... not more... it was dismissed as bloat... | Personally, I thnk that a "string | abs_name, bool output_relative_to_buffer_path" is all it needs. | | And I don't think I am talking total crap since _most_ of my dealings with | LyX appear focussed on how the kernel interacts with the world around it. | | > And just drop the comment about bloat. I am beginning to take almost | > all such comments as insults now... | | Then you should be more robust. I think I have been robust enough. | There was no intent to abuse; I made what I | feel is a valid comment. Anyway, I'm the least abusive guy I know. I am just getting tired of such comments... it does not matter that you only do it once, when everybody else does it once (or twice) as well... -- Lgb
Re: Python help needed ;-)
On Wed, Jun 04, 2003 at 11:18:09AM +0100, Jose' Matos wrote: > > I point the answer, use split. > > > Could someone write the 5 lines of code? Plase? > > def convert_external(lines): > i = 0 > while 1: > i = find_token(lines, "\\begin_inset External", i) > if i == -1: > break > top = "\\begin_inset External" > args = string.split(lines[i][len(top)+1:],',') > template = "\ttemplate " + args[0] > filename = "\tfilename " + args[1] > lines[i:i+1] = [top, template, filename] > i = i + 1 This will fail if the filename contains ','. It is probably better to use regular expressions (see my other mail).
Re: A File class
Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Lars Gullik Bjønnes wrote: > | > | > Andre Poenitz <[EMAIL PROTECTED]> writes: > | > > | > | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote: > | > | > Opinions? > | > | > | > | Good. > | > > | > I think you should have a look at boost::filesystem and see how that > | > fits. > | > | I _knew_ you would say that. Angus buys himself a beer. > | > | My entire point was that our requirements here are _very_ simple. Is the > | filename input as relative to the buffer path? > > This is graphics/external only, please obtain a broader picture. I am talking about how LyX stores/outputs references to external files. That is the only interaction I am interested in here. Actually, what other interest does LyX have in files? > | If so output it relative to > | that path. Always storing it internally as an absolute path guarantees > | that we won't screw up as we move an inset between buffers. > | > | That's it. No need for a pile more bloat. > > a nice function there and new function and class there, let's add > another function... oh we need this as well all solved at the same > time with a nice lib. If you want to implement the FileName class using boost::filesystem, fine. But IMO that is an implementation detail. Personally, I thnk that a "string abs_name, bool output_relative_to_buffer_path" is all it needs. And I don't think I am talking total crap since _most_ of my dealings with LyX appear focussed on how the kernel interacts with the world around it. > And just drop the comment about bloat. I am beginning to take almost > all such comments as insults now... Then you should be more robust. There was no intent to abuse; I made what I feel is a valid comment. Anyway, I'm the least abusive guy I know. Ok, ok have a smiley ;-) -- Angus
Re: Python help needed ;-)
On Wednesday 04 June 2003 11:33, Angus Leeming wrote: > I want to add a module to lyxconvert_221.py to change this: > > \begin_inset External RasterImage,"taulogo.png","" > > \end_inset > > to this > > \begin_inset External > template RasterImage > filename taulogo.png > > \end_inset > > throwing away the final arg (here "", more generally "") that holds > the parameters variable. I guess that we could retain the filename within > quotes as LyXLeX will handle that. > > Trouble is, I don't know how to split the line into its constituent parts. I point the answer, use split. > Could someone write the 5 lines of code? Plase? def convert_external(lines): i = 0 while 1: i = find_token(lines, "\\begin_inset External", i) if i == -1: break top = "\\begin_inset External" args = string.split(lines[i][len(top)+1:],',') template = "\ttemplate " + args[0] filename = "\tfilename " + args[1] lines[i:i+1] = [top, template, filename] i = i + 1 I'm not even sure this runs, if you send me a file I will teste this code for you. :-) -- José Abílio
Re: Python help needed ;-)
On Wed, Jun 04, 2003 at 10:33:02AM +, Angus Leeming wrote: > I want to add a module to lyxconvert_221.py to change this: > > \begin_inset External RasterImage,"taulogo.png","" > > \end_inset > > to this > > \begin_inset External > template RasterImage > filename taulogo.png > > \end_inset > > throwing away the final arg (here "", more generally "") that holds > the parameters variable. I guess that we could retain the filename within > quotes as LyXLeX will handle that. > > Trouble is, I don't know how to split the line into its constituent parts. import re mo = re.search(r'\\begin_inset External (.*),"(.*)",', a) if mo: print "template", mo.group(1) print "filename", mo.group(2) This code will fail if the filename contains the char '"' (how does the lyx file look in that case ? )
Re: preamble
On Wed, Jun 04, 2003 at 12:01:39PM +0200, Jean-Marc Lasgouttes wrote: > Of course. But if we decide to put the preamble in the document > itself, then forcing it to be in some place will really be a hack > (additional ugly code for no use), whereas allowing several preamble > snippets could prove powerful (as our Rules say: ``Declaration of > variables should wait as long as possible. The rule is: "Don't declare > it until you need it."''). Moreover, if you hide some part of the doc in a note, you can hide the corresponding ERT as well. That's nice... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: preamble
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> "redefinition if 'barcmd' not allowed" what? where? me? I guess our error tracking code could be able to take care of that and put the error at the right place. Lars> What I really think is that preamble and ert hacking should not Lars> be needed and that we should not do to much to accomodate such Lars> uses. Of course. But if we decide to put the preamble in the document itself, then forcing it to be in some place will really be a hack (additional ugly code for no use), whereas allowing several preamble snippets could prove powerful (as our Rules say: ``Declaration of variables should wait as long as possible. The rule is: "Don't declare it until you need it."''). JMarc
Re: preamble
On Wed, Jun 04, 2003 at 11:47:14AM +0200, Lars Gullik Bjønnes wrote: > So my take on this is that we should provide features so that ERT and > preamble hacking is only needed in "obscure" cases. No problem with that. [Even if my usage has 100% "obscure" cases by this definition...] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: A File class
Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | | > Andre Poenitz <[EMAIL PROTECTED]> writes: | > | > | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote: | > | > Opinions? | > | | > | Good. | > | > I think you should have a look at boost::filesystem and see how that | > fits. | | I _knew_ you would say that. Angus buys himself a beer. | | My entire point was that our requirements here are _very_ simple. Is the | filename input as relative to the buffer path? This is graphics/external only, please obtain a broader picture. | If so output it relative to | that path. Always storing it internally as an absolute path guarantees that | we won't screw up as we move an inset between buffers. | | That's it. No need for a pile more bloat. a nice function there and new function and class there, let's add another function... oh we need this as well all solved at the same time with a nice lib. And just drop the comment about bloat. I am beginning to take almost all such comments as insults now... -- Lgb
Re: preamble
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Wed, Jun 04, 2003 at 10:58:55AM +0200, Lars Gullik Bjønnes wrote: | > | I think that enforcing the number and placement of preamble insets is | > | both clunky and not really necessary. | > | > What I really think is that preamble and ert hacking should not be | > needed and that we should not do to much to accomodate such uses. | | It won't go away. It will allways be needed. | | We can't natively support everything possible with plain LaTeX/TeX. Perhaps not... but we can try. So my take on this is that we should provide features so that ERT and preamble hacking is only needed in "obscure" cases. -- Lgb
Re: Python help needed ;-)
On Wed, Jun 04, 2003 at 10:33:02AM +, Angus Leeming wrote: > throwing away the final arg (here "", more generally "") that holds > the parameters variable. I guess that we could retain the filename within > quotes as LyXLeX will handle that. We should, as this may contain spaces, shouldn't we? > Could someone write the 5 lines of code? Plase? I don't speak Python... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Python help needed ;-)
I want to add a module to lyxconvert_221.py to change this: \begin_inset External RasterImage,"taulogo.png","" \end_inset to this \begin_inset External template RasterImage filename taulogo.png \end_inset throwing away the final arg (here "", more generally "") that holds the parameters variable. I guess that we could retain the filename within quotes as LyXLeX will handle that. Trouble is, I don't know how to split the line into its constituent parts. Could someone write the 5 lines of code? Plase? -- Angus
Re: preamble
Andre Poenitz wrote: > I was thinking about doing something similar for the math macro > definitions anyway, so everything would be more consistent this way, > too... For the math macros, I think a dialog is a better solution. It can be accessed from anywhere in the document and one could insert a macro by chosing from a browser. Not that I care much about math macros, but I still hope that they will be enhanced to a general macro feature. (but I like the idea of a collapsable preamble) Jürgen.
Re: A File class
Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote: > | > Opinions? > | > | Good. > > I think you should have a look at boost::filesystem and see how that > fits. I _knew_ you would say that. Angus buys himself a beer. My entire point was that our requirements here are _very_ simple. Is the filename input as relative to the buffer path? If so output it relative to that path. Always storing it internally as an absolute path guarantees that we won't screw up as we move an inset between buffers. That's it. No need for a pile more bloat. -- Angus
Re: preamble
On Wed, Jun 04, 2003 at 10:58:55AM +0200, Lars Gullik Bjønnes wrote: > | I think that enforcing the number and placement of preamble insets is > | both clunky and not really necessary. > > What I really think is that preamble and ert hacking should not be > needed and that we should not do to much to accomodate such uses. It won't go away. It will allways be needed. We can't natively support everything possible with plain LaTeX/TeX. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch]: the external inset reworking.
Alfredo Braunstein wrote: > Angus Leeming wrote: > >> These last two will be output only if different from the default 100 and >> NoDisplay respectively. > > Maybe it may make sense to keep the default value for NoDisplay > somewhere... like on the template (then it should be output in any case, > though)? No, I don't think so. Once they have saved a file with "Show in LyX" enabled then all will be fine. -- Angus
Re: preamble
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> But I do not think that this inset should be allowed anywhere... | Lars> IMHO only at the _very_ beginning of the document. And only one | Lars> of them. | | Why? It would be a nice feature to be able to add preamble insets | where you need them (a newcommand, for example) and have LyX place | collect all the preamble snippets in the .tex. Actually, the ERT inset | could basically get a new flag saying 'place me in the preamble'. "redefinition if 'barcmd' not allowed" what? where? me? | I think that enforcing the number and placement of preamble insets is | both clunky and not really necessary. What I really think is that preamble and ert hacking should not be needed and that we should not do to much to accomodate such uses. -- Lgb
Re: A File class
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote: | > Opinions? | | Good. I think you should have a look at boost::filesystem and see how that fits. -- Lgb
Re: A File class
On Wed, Jun 04, 2003 at 09:34:44AM +, Angus Leeming wrote: > Opinions? Good. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: preamble
On Wed, Jun 04, 2003 at 10:34:46AM +0200, Jean-Marc Lasgouttes wrote: > Why? It would be a nice feature to be able to add preamble insets > where you need them (a newcommand, for example) and have LyX place > collect all the preamble snippets in the .tex. Actually, the ERT inset > could basically get a new flag saying 'place me in the preamble'. Pretty good idea. > I think that enforcing the number and placement of preamble insets is > both clunky and not really necessary. actually... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: preamble
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> But I do not think that this inset should be allowed anywhere... Lars> IMHO only at the _very_ beginning of the document. And only one Lars> of them. Why? It would be a nice feature to be able to add preamble insets where you need them (a newcommand, for example) and have LyX place collect all the preamble snippets in the .tex. Actually, the ERT inset could basically get a new flag saying 'place me in the preamble'. I think that enforcing the number and placement of preamble insets is both clunky and not really necessary. JMarc
A File class
It strikes me that we bend ourselves into all sorts of contortions when it comes up file names because we store a single string and then try and guess how to use it in different places. I think that are requirements are no more complex than this: class FileName { FileName(string const & abs_filename, bool output_relative) : absolute_filename_(abs_filename), output_relative_to_buffer_path_(output_relative) { if (!absolute_filename_.empty()) lyx::Assert(AbsolutePath(absolute_filename_)); } /** Signals intent. The file name was stored in the LyX file with a relative path. It should be output in the same way. */ bool outputRelative() const { return output_relative_to_buffer_path_; } string const & absFilename() const { return absolute_filename_; } string const relFilename(string const & base_path) { lyx::Assert(AbsolutePath(AbsolutePath)); return MakeRelPath(absolute_filename_, base_path); } private: string absolute_filename_; bool output_relative_to_buffer_path_; }; Opinions? -- Angus
Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all
On Wed, Jun 04, 2003 at 09:17:19AM +, Angus Leeming wrote: > Ok, the question becomes: > can dim_.asc change between it being set in GraphicInset::metrics and it > being used in GraphicInset::draw? I don't think so. > That is what this piece of code is testing for. I think not but I don't > know whether there is a gap between the metrics call and the draw call > (ie does control passes through the underlying gui "process event" loop > or do we have code like metrics(...); draw(...); ?) The code is like metrics(...); draw(...) . Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all
Angus Leeming wrote: > Andre Poenitz wrote: > >> On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote: >>> This cleans up InsetGraphics::Cache and renames it as GraphicsInset so >>> that the external inset can use it too. >> >> What do you need old_ascent_ for? >> >> + old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() : >> 50; + >> + dim.asc = old_ascent_; >> + dim.des = 0; >> + [...] >> + dim_ = dim; >> >> You could use dim_.asc instead... > > This is what I call "Juergen magic". I didn't really understand it then. I > still don't. If you tell me that it is "premature optimization" then I > will remove it. Ok, the question becomes: can dim_.asc change between it being set in GraphicInset::metrics and it being used in GraphicInset::draw? That is what this piece of code is testing for. I think not but I don't know whether there is a gap between the metrics call and the draw call (ie does control passes through the underlying gui "process event" loop or do we have code like metrics(...); draw(...); ?) Can you provide some insight? I do remember that Juergen thought it important that the loading process is asynchronous, but I'm hazy as to why. -- Angus
Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all
On Wed, Jun 04, 2003 at 08:49:55AM +, Angus Leeming wrote: > Andre Poenitz wrote: > > > On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote: > >> This cleans up InsetGraphics::Cache and renames it as GraphicsInset so > >> that the external inset can use it too. > > > > What do you need old_ascent_ for? > > > > + old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() : 50; > > + > > + dim.asc = old_ascent_; > > + dim.des = 0; > > + [...] > > + dim_ = dim; > > > > You could use dim_.asc instead... > > This is what I call "Juergen magic". I didn't really understand it then. I > still don't. If you tell me that it is "premature optimization" then I will > remove it. No, I tell you that we nowadays cache all parts of the metrics in dim_, so there is no need to cache the ascent twice (once in dim_, and once in old_ascent_). Partially my doing, in fact... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: preamble
Andre Poenitz wrote: > The preamble dialog is not nice to use (not just the size, but the > editing is very limited at least under xforms). > So what about using a InsetPreamble (some collapsable inset, perhaps on > top of InsertERT) instead of the separate preamble dialog? > Opinions? Even more entertaining would be to create xforms and Qt WorkArea widgets and use it in place of these multiline input widgets. If you want to do it in-place, then we really want an InsetEdit that would be used here to input the preamble. (Incidentally, didn't someone mail the list sometime ago with a suggestion to use the ExternalInset mechanisms to enable syntax highlighting using some external python module? I didn't understand the details and I note that nothing came of it. Ah well.) -- Angus
Re: preamble
On Wed, Jun 04, 2003 at 09:44:09AM +0200, Lars Gullik Bjønnes wrote: > | It would be just a few lines to prevent the insertion of a second 'preamble > | inset' in the doc, it would be a bit more difficult to fix the position of > | the inset at the beginning of the doc > > Would it? > > LFUN_INSERT_PREAMBLE would only insert at paragraphs.begin()[0] and > only allow one. That's an option... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all
Andre Poenitz wrote: > On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote: >> This cleans up InsetGraphics::Cache and renames it as GraphicsInset so >> that the external inset can use it too. > > What do you need old_ascent_ for? > > + old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() : 50; > + > + dim.asc = old_ascent_; > + dim.des = 0; > + [...] > + dim_ = dim; > > You could use dim_.asc instead... This is what I call "Juergen magic". I didn't really understand it then. I still don't. If you tell me that it is "premature optimization" then I will remove it. -- Angus
Re: preamble
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Wed, Jun 04, 2003 at 08:56:30AM +0200, Lars Gullik Bjønnes wrote: | > But I do not think that this inset should be allowed anywhere... IMHO | > only at the _very_ beginning of the document. And only one of them. | | This would be naturally enforced when reading a .lyx file. Not all documents are read... some are created from scratch... | It would be just a few lines to prevent the insertion of a second 'preamble | inset' in the doc, it would be a bit more difficult to fix the position of | the inset at the beginning of the doc Would it? LFUN_INSERT_PREAMBLE would only insert at paragraphs.begin()[0] and only allow one. -- Lgb
Re: [patch]: the external inset reworking.
Angus Leeming wrote: > These last two will be output only if different from the default 100 and > NoDisplay respectively. Maybe it may make sense to keep the default value for NoDisplay somewhere... like on the template (then it should be output in any case, though)? > If nobody says otherwise, I'll probably apply what I have sometime > tomorrow... I say something: cool. Regards, Alfredo
Re: preamble
On Wed, Jun 04, 2003 at 08:56:30AM +0200, Lars Gullik Bjønnes wrote: > But I do not think that this inset should be allowed anywhere... IMHO > only at the _very_ beginning of the document. And only one of them. This would be naturally enforced when reading a .lyx file. It would be just a few lines to prevent the insertion of a second 'preamble inset' in the doc, it would be a bit more difficult to fix the position of the inset at the beginning of the doc Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: preamble
Andre Poenitz <[EMAIL PROTECTED]> writes: | The preamble dialog is not nice to use (not just the size, but the | editing is very limited at least under xforms). | | So what about using a InsetPreamble (some collapsable inset, perhaps on top | of InsertERT) instead of the separate preamble dialog? Have I said this about hundred times now?: We need an InsetEditor | Technically there is no problem: It simply adds its contents to the written | preamble in validate(), it gets added a the begin of a doc when read from | the .lyx. | | For editing we could use all the 'main LyX editing features' and are not | limited to what xforms provides. | | I was thinking about doing something similar for the math macro definitions | anyway, so everything would be more consistent this way, too... | | Opinions? I am not alian to this idea. But I do not think that this inset should be allowed anywhere... IMHO only at the _very_ beginning of the document. And only one of them. -- Lgb
Re: [patch] undo (partial...)
Andre Poenitz <[EMAIL PROTECTED]> writes: | This makes undo partially work. It crashes always when used in the last | par and after "complicated" operations, but it works if used in the middle | of the text for simple insertions/deletions, sometimes even multi-par | stuff. | | In any case, this is somewhat beter than what we have now. Good... and long as it gets better we should push on. | Note that I had to implement Paragraph::operator=() (Lars, you are a | naughty boy...). I had it implemented (with swap), but that was before the clone fixes... so it did not really compile :-/ | Replace it with something closer to your taste if you | want. The swap idiom is a bit more work here because the inset owners | need to be set.. Not if a proper operator= is implemented for InsetList. (a setOwner will still be needed though). | Next change i the return type of limited_stack::top(). It's (a) used this | way and (b) consistent with std::stack<> now. ok. | The rest is undo specific stuff, some simplification of the logic and some | code to 'make it work'. | | Ok? Yes. -- Lgb
preamble
The preamble dialog is not nice to use (not just the size, but the editing is very limited at least under xforms). So what about using a InsetPreamble (some collapsable inset, perhaps on top of InsertERT) instead of the separate preamble dialog? Technically there is no problem: It simply adds its contents to the written preamble in validate(), it gets added a the begin of a doc when read from the .lyx. For editing we could use all the 'main LyX editing features' and are not limited to what xforms provides. I was thinking about doing something similar for the math macro definitions anyway, so everything would be more consistent this way, too... Opinions? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
[patch] undo (partial...)
This makes undo partially work. It crashes always when used in the last par and after "complicated" operations, but it works if used in the middle of the text for simple insertions/deletions, sometimes even multi-par stuff. In any case, this is somewhat beter than what we have now. Note that I had to implement Paragraph::operator=() (Lars, you are a naughty boy...). Replace it with something closer to your taste if you want. The swap idiom is a bit more work here because the inset owners need to be set.. Next change i the return type of limited_stack::top(). It's (a) used this way and (b) consistent with std::stack<> now. The rest is undo specific stuff, some simplification of the logic and some code to 'make it work'. Ok? [Note that the logic might even get simpler if we would not use paragraph ids, but ParagraphList ids and use distances from plist->begin() instead of 'first_id' and from plist->end() fo 'last_id'. In that case, undo would not need Paragraph::id anymore and possibly no Inset::id, too.] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...) Index: buffer.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.h,v retrieving revision 1.143 diff -u -p -r1.143 buffer.h --- buffer.h2 Jun 2003 14:02:58 - 1.143 +++ buffer.h4 Jun 2003 06:09:49 - @@ -23,7 +23,6 @@ #include "author.h" #include "iterators.h" -#include #include class BufferView; @@ -273,10 +272,10 @@ public: bool isMultiLingual(); /// Does this mean that this is buffer local? - limited_stack > undostack; + limited_stack undostack; /// Does this mean that this is buffer local? - limited_stack > redostack; + limited_stack redostack; /// BufferParams params; Index: lyxfunc.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v retrieving revision 1.448 diff -u -p -r1.448 lyxfunc.C --- lyxfunc.C 2 Jun 2003 14:19:29 - 1.448 +++ lyxfunc.C 4 Jun 2003 06:09:49 - @@ -501,7 +501,7 @@ FuncStatus LyXFunc::getStatus(FuncReques // jump back to owner if an InsetText, so // we get back to the InsetTabular or whatever if (inset->lyxCode() == Inset::TEXT_CODE) - inset = static_cast(inset->owner()); + inset = inset->owner(); Inset::Code code = inset->lyxCode(); switch (code) { Index: paragraph.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.C,v retrieving revision 1.280 diff -u -p -r1.280 paragraph.C --- paragraph.C 3 Jun 2003 15:10:07 - 1.280 +++ paragraph.C 4 Jun 2003 06:09:49 - @@ -97,6 +97,31 @@ Paragraph::Paragraph(Paragraph const & l } +void Paragraph::operator=(Paragraph const & lp) +{ + if (&lp != this) + return; + lyxerr << "Paragraph::operator=()\n"; + delete pimpl_; + pimpl_ = new Pimpl(*lp.pimpl_, this); + + enumdepth = lp.enumdepth; + itemdepth = lp.itemdepth; + // this is because of the dummy layout of the paragraphs that + // follow footnotes + layout_ = lp.layout(); + + // copy everything behind the break-position to the new paragraph + insetlist = lp.insetlist; + InsetList::iterator it = insetlist.begin(); + InsetList::iterator end = insetlist.end(); + for (; it != end; ++it) { + it->inset = it->inset->clone(); + // tell the new inset who is the boss now + it->inset->parOwner(this); + } +} + // the destructor removes the new paragraph from the list Paragraph::~Paragraph() { @@ -1205,14 +1230,14 @@ string const Paragraph::asString(Buffer } -void Paragraph::setInsetOwner(Inset * i) +void Paragraph::setInsetOwner(UpdatableInset * inset) { - pimpl_->inset_owner = i; + pimpl_->inset_owner = inset; InsetList::iterator it = insetlist.begin(); InsetList::iterator end = insetlist.end(); for (; it != end; ++it) if (it->inset) - it->inset->setOwner(i); + it->inset->setOwner(inset); } @@ -1350,7 +1375,7 @@ void Paragraph::layout(LyXLayout_ptr con } -Inset * Paragraph::inInset() const +UpdatableInset * Paragraph::inInset() const { return pimpl_->inset_owner; } Index: paragraph.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.h,v retrieving revision 1.86 diff -u -p -r1.86 paragraph.h --- paragraph.h 3 Jun 2003 15:10:07 - 1.86 +++ paragraph.h 4 Jun 2003 06:09:49 - @@ -31,6 +31,7 @@ class LatexRu
Re: [patch] update, re-done
On Wed, Jun 04, 2003 at 12:31:17AM +0200, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On Tue, Jun 03, 2003 at 05:19:16PM +0200, Andre Poenitz wrote: > | > | > Index: rowpainter.C > | > | My experience mirrors yours: everything works fine, except tabular, > | which is significantly broken. > > Any idea why it is broken? Probably because I copied just a single line out of 47 from InsetTabular::update over to InsetTabular::metrics and some other line in there does something sensible, too. > Can it easily be fixed? There is no technical reason why it cannot work. > I am not so sure that we want to introduce known regressions at this > stage. I'll have a look again later... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch]: clean-up InsetGraphics::Cache and make it accessible to all
On Tue, Jun 03, 2003 at 06:17:10PM +, Angus Leeming wrote: > This cleans up InsetGraphics::Cache and renames it as GraphicsInset so that > the external inset can use it too. What do you need old_ascent_ for? + old_ascent_ = (type == IMAGE) ? loader_.image()->getHeight() : 50; + + dim.asc = old_ascent_; + dim.des = 0; + [...] + dim_ = dim; You could use dim_.asc instead... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [patch] update, re-done
On Wed, Jun 04, 2003 at 12:31:17AM +0200, Lars Gullik Bj?nnes wrote: > Any idea why it is broken? Not in any concrete sense. > Can it easily be fixed? I strongly doubt it. The difficult part is not construction but discovery. But that is just a guess. > I am not so sure that we want to introduce known regressions at this > stage. I agree. Let's fix undo first. regards john
Re: [patch] update, re-done
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Jun 03, 2003 at 05:19:16PM +0200, Andre Poenitz wrote: | | > Index: rowpainter.C | | My experience mirrors yours: everything works fine, except tabular, | which is significantly broken. Any idea why it is broken? Can it easily be fixed? I am not so sure that we want to introduce known regressions at this stage. -- Lgb
[lrathle@kde-france.org: lyx-1.3.2-1mdk91-qt.i586.rpm]
Can anyone answer this for Laurent? - Forwarded message from Laurent Rathle <[EMAIL PROTECTED]> - From: Laurent Rathle <[EMAIL PROTECTED]> Organization: Kde france To: [EMAIL PROTECTED] Subject: lyx-1.3.2-1mdk91-qt.i586.rpm Date: Tue, 3 Jun 2003 23:46:51 +0200 User-Agent: KMail/1.5 Hello, There is a little problem with the lix package for Mandrake 9.1. It does'nt want to install since it ask for Qt 2 and Mandrake 9.1 is Qt 3.1.1. Thank you for your work, Have a nice evening, -- [EMAIL PROTECTED] http://www.kde-france.org - End forwarded message - -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
[patch]: the external inset reworking.
I attach my changes to the external inset and dialogs. I think that it is pretty close to finished. Please feel free to try it out. Note that there is a file format change so don't save any important docs with it. Note that the default is NoDisplay meaning that you'll get a button [ Xfig: file.fig ] Click on the inset to pop up the dialog to change that. The next step will be to remove the parameters variable from the InsetExternal::Params struct. I'll take the opportunity then to rewrite the InsetExternal::Read and Write methods to be less clunky. (Ie, Read will use lyxlex properly.) At the moment the external inset is written as \begin_inset External RasterImage,"taulogo.png","" where the last field is the (effectively redundant) params variable. The patch changes this to \begin_inset External RasterImage,"taulogo.png","",, which is still clunky. After this patch is applied I'll change it to something more like the Graphics Inset: \begin_inset External template RasterImage filename taulogo.png lyxscale 80 display color These last two will be output only if different from the default 100 and NoDisplay respectively. Attached are two files. external.diff.gz contains the changes to the LyX source. external.tar.gz will expand to a directory External containing a small lyx document to test out the external inset with. If nobody says otherwise, I'll probably apply what I have sometime tomorrow... -- Angus external.diff.gz Description: GNU Zip compressed data external.tar.gz Description: GNU Zip compressed data
Re: [1.3.2] Don't assume sys/select.h exists
On Tue, Jun 03, 2003 at 10:44:15PM +0200, Jean-Marc Lasgouttes wrote: > If you don't apply it to 1.3.X, I will have to do it myself... Why, such subtlety :) done regards john
Re: [1.3.2] Don't assume sys/select.h exists
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Tue, Jun 03, 2003 at 01:31:51AM -0500, Albert Chin wrote: >> Doesn't exist on HP-UX 11.x. Patch below against >> 1.3.2. John> Applied to CVS thanks. JMarc ? If you don't apply it to 1.3.X, I will have to do it myself... JMarc
Re: Using Qt designer
On Tue, Jun 03, 2003 at 08:28:46PM +, Angus Leeming wrote: > Hmmm. I guess you don't use it much: > Any reason why not? Most of them are units dialogs. But no, no real reason for the others. (bug: qtabular doesn't take units for the col width) john
Re: Using Qt designer
John Levon wrote: > On Tue, Jun 03, 2003 at 08:02:23PM +, Angus Leeming wrote: > >> Question. xforms has input filters. In this case I have >> fl_set_input_filter(dialog_->input_lyxscale, >> fl_unsigned_int_filter); >> >> Is there any equivalent in the Qt code? > > http://doc.trolltech.com/2.3/qlineedit.html#766d94 > > john Hmmm. I guess you don't use it much: $ grep setValidator * */* */*/* QParagraphDialog.C: linespacingValue->setValidator(new QDoubleValidator(linespacingValue)); Any reason why not? -- Angus
Re: Using Qt designer
On Tue, Jun 03, 2003 at 08:02:23PM +, Angus Leeming wrote: > Question. xforms has input filters. In this case I have > fl_set_input_filter(dialog_->input_lyxscale, fl_unsigned_int_filter); > > Is there any equivalent in the Qt code? http://doc.trolltech.com/2.3/qlineedit.html#766d94 john
Re: Using Qt designer
John Levon wrote: >> You can see how I've grouped the various widgets together. Look Ok? > > I would place the template combo at the top, as it is dominant over the > other stuff. And possibly make it a grooup box so it's obvious what is > in the text area. Even better, would be to change the visual look of the > text area so it's not sunken... Well I've put the template at the top. > But don't worry too much, I can do details stuff if you like I'll continue to play willing. I've connected the signals and slots and have added code to QExternal::update_contents and QExternal::apply. Question. xforms has input filters. In this case I have fl_set_input_filter(dialog_->input_lyxscale, fl_unsigned_int_filter); Is there any equivalent in the Qt code? -- Angus
Re: Using Qt designer
On Tue, Jun 03, 2003 at 07:11:43PM +, Angus Leeming wrote: > I'm trying to get to grips with Qt's designer (I am using Qt2's designer. I > think that's correct isn't it?) Yes. > You can see how I've grouped the various widgets together. Look Ok? I would place the template combo at the top, as it is dominant over the other stuff. And possibly make it a grooup box so it's obvious what is in the text area. Even better, would be to change the visual look of the text area so it's not sunken... > My question: how do I tell them they're sitting in the "LyX Display" frame. They're probably there. If you drag the frame, do they follow ? Right click in the frame and choose the option to lay out the children as a grid, horiz or vert. > Thereafter, how do I layout this frame within the whole dialog. Seems I've > got stuck. Same thing. Generally if you lay it roughly out, then "Layout as grid" works. But don't worry too much, I can do details stuff if you like regards john
Re: Using Qt designer
Angus Leeming wrote: > I'm trying to get to grips with Qt's designer (I am using Qt2's designer. > I think that's correct isn't it?) > > Attached is a screenshot of what I've got so far for the External dialog. > I'm trying to add some widgets to control the appearence of the inset > within LyX. Basically, I'm just copying the equivalent stuff in the > Graphics dialog. > > You can see how I've grouped the various widgets together. Look Ok? > > My question: how do I tell them they're sitting in the "LyX Display" > frame. Thereafter, how do I layout this frame within the whole dialog. > Seems I've got stuck. Ahhh! Click that lil' ol' grid icon on the toolbar. Once for the frame and once for the whole dialog. Too easy for an old codger! -- Angus
Using Qt designer
I'm trying to get to grips with Qt's designer (I am using Qt2's designer. I think that's correct isn't it?) Attached is a screenshot of what I've got so far for the External dialog. I'm trying to add some widgets to control the appearence of the inset within LyX. Basically, I'm just copying the equivalent stuff in the Graphics dialog. You can see how I've grouped the various widgets together. Look Ok? My question: how do I tell them they're sitting in the "LyX Display" frame. Thereafter, how do I layout this frame within the whole dialog. Seems I've got stuck. -- Angus<>
[patch]: clean-up InsetGraphics::Cache and make it accessible to all
This cleans up InsetGraphics::Cache and renames it as GraphicsInset so that the external inset can use it too. -- AngusIndex: src/insets/graphicinset.h === RCS file: src/insets/graphicinset.h diff -N src/insets/graphicinset.h --- /dev/null 1 Jan 1970 00:00:00 - +++ src/insets/graphicinset.h 3 Jun 2003 17:13:29 - @@ -0,0 +1,90 @@ +// -*- C++ -*- +/** + * \file graphicinset.h + * This file is part of LyX, the document processor. + * Licence details can be found in the file COPYING. + * + * \author Angus Leeming + * + * Full author contact details are available in file CREDITS + */ + +#ifndef GRAPHICINSET_H +#define GRAPHICINSET_H + +#include "dimension.h" + +#include "graphics/GraphicsLoader.h" +#include "graphics/GraphicsParams.h" +#include "graphics/GraphicsTypes.h" + +#include +#include + + +class MetricsInfo; +class PainterInfo; + + +class GraphicInset +{ +public: + GraphicInset(); + GraphicInset(GraphicInset const &); + + /** Set the message that the inset will show when the + * display of the graphic is deactivated. + * The default is nothing, meaning that the inset will + * show a message descibing the state of the image + * loading process. + */ + void setNoDisplayMessage(string const & msg); + + /// Refresh the info about which file to display and how to display it. + void update(grfx::Params const & params); + /// File name, image size, rotation angle etc. + grfx::Params const & params() const; + + /// compute the size of the object returned in dim + void metrics(MetricsInfo & mi, Dimension & dim) const; + /// draw inset and update (xo, yo)-cache + void draw(PainterInfo & pi, int x, int y) const; + + /// Is the stored checksum different to that of the graphics loader? + bool hasFileChanged() const; + /// An accessor function to the cached store. + BufferView * view() const; + + /** Connect and you'll be informed when the loading status of the image + * changes. + */ + typedef boost::signal0::slot_type slot_type; + boost::signals::connection connect(slot_type const &) const; + +private: + enum DisplayType { + IMAGE, + STATUS_MESSAGE, + NODISPLAY_MESSAGE + }; + + /// Is the image ready to draw, or should we display a message instead? + DisplayType displayType() const; + + /// The message to display instead of the graphic itself. + string const statusMessage() const; + + /// The stored data. + grfx::Loader loader_; + grfx::Params params_; + string nodisplay_message_; + + /// These are all cached variables. + mutable int old_ascent_; + mutable unsigned long checksum_; + mutable boost::weak_ptr view_; + mutable Dimension dim_; +}; + + +#endif // NOT GRAPHICINSET_H Index: src/insets/graphicinset.C === RCS file: src/insets/graphicinset.C diff -N src/insets/graphicinset.C --- /dev/null 1 Jan 1970 00:00:00 - +++ src/insets/graphicinset.C 3 Jun 2003 17:13:30 - @@ -0,0 +1,287 @@ +/** + * \file graphicinset.C + * This file is part of LyX, the document processor. + * Licence details can be found in the file COPYING. + * + * \author Angus Leeming + * + * Full author contact details are available in file CREDITS + */ + +#include + +#include "insets/graphicinset.h" + +#include "buffer.h" +#include "BufferView.h" +#include "gettext.h" +#include "metricsinfo.h" + +#include "frontends/font_metrics.h" +#include "frontends/LyXView.h" +#include "frontends/Painter.h" + +#include "graphics/GraphicsImage.h" + +#include "support/filetools.h" + + +GraphicInset::GraphicInset() + : old_ascent_(0), checksum_(0) +{} + + +GraphicInset::GraphicInset(GraphicInset const & other) + : loader_(other.loader_), + params_(other.params_), + nodisplay_message_(other.nodisplay_message_), + old_ascent_(0), + checksum_(0) +{} + + +void GraphicInset::update(grfx::Params const & params) +{ + if (!params.filename.empty()) { + lyx::Assert(AbsolutePath(params.filename)); + loader_.reset(params_.filename, params_); + } + params_ = params; +} + + +grfx::Params const & GraphicInset::params() const +{ + return params_; +} + + +bool GraphicInset::hasFileChanged() const +{ + unsigned long const new_checksum = loader_.checksum(); + bool const file_has_changed = checksum_ != new_checksum; + if (file_has_changed) + checksum_ = new_checksum; + return file_has_changed; +} + + +BufferView * GraphicInset::view() const +{ + return view_.lock().get(); +} + + +boost::signals::connection GraphicInset::connect(slot_type const & slot) const +{ + return loader_.connect(slot); +} + + +void GraphicInset::setNoDisplayMessage(string const & str) +{ + nodisplay_message_ = str; +} + + +string const GraphicInset::statusMessage() const +{ + switch (loader_.status()) { + case grfx::WaitingToLoad: + return _("Not shown."); + case grfx::Loading: + return _("Loading..."); + case grfx::Converting: + return _("Converting to loadable format..."); + case grfx::Loaded: + return _("Loaded into memor
Re: Pasting the "wrong" inset.
On Tue, Jun 03, 2003 at 05:21:56PM +, Angus Leeming wrote: > Then it should also display the correct path (presumably now absolute) when > I open the dialog. And here, where I have removed the fudge I describe, it > does not. Why ? The document is saved with relative paths. The absolute path thing is basically an implementation detail. > Because the fudge I pointed out in draw still exists in your tree. InsetGraphics::draw ? Where ? I thought I'd removed it regards john
Re: [patch] update, re-done
On Tue, Jun 03, 2003 at 05:19:16PM +0200, Andre Poenitz wrote: > Index: rowpainter.C My experience mirrors yours: everything works fine, except tabular, which is significantly broken. I suspect that if we somehow force a "redo" in tabularFeature() somewhere, things will behave better. But the form of this redo ... regards john
Re: Pasting the "wrong" inset.
John Levon wrote: > On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote: > >> If the file is stored with a relative path and I either cut it or copy it >> and then paste it into a buffer with a different buffer->filePath(), then >> LyX _finds_ and displays it. Of course, no file exists at this absolute >> (new buffer) + (relative path to graphic file) location, so we should >> fail to find it and display nothing. > > If I'm understanding you correctly then I strongly disagree. The > computer shouldn't act like a moron. If it knows where the file is (and > it does), then when I paste it into another document, it should get > added there. We should handle all the relative path stuff automatically > ... and we do now. Then it should also display the correct path (presumably now absolute) when I open the dialog. And here, where I have removed the fudge I describe, it does not. > I totally don't get this sorry :/ Because the fudge I pointed out in draw still exists in your tree. -- Angus
Re: Pasting the "wrong" inset.
On Tue, Jun 03, 2003 at 05:00:35PM +, Angus Leeming wrote: > If the file is stored with a relative path and I either cut it or copy it > and then paste it into a buffer with a different buffer->filePath(), then > LyX _finds_ and displays it. Of course, no file exists at this absolute > (new buffer) + (relative path to graphic file) location, so we should fail > to find it and display nothing. If I'm understanding you correctly then I strongly disagree. The computer shouldn't act like a moron. If it knows where the file is (and it does), then when I paste it into another document, it should get added there. We should handle all the relative path stuff automatically ... and we do now. Previously (storing relative path in the params) it would break even if the user did Save As. That's obviously not too clever. Example: I have two docs /foo/a.lyx and /bar/b.lyx, and a graphics file /foo/a.eps a.lyx when loaded contains a graphics inset with a graphics path "/foo/a.eps". I cut and paste that into b.lyx. Now that contains "/foo/a.eps". All works as is. The former is *saved* as "a.eps" and the latter as "/foo/a.eps", and that's what we show the user, but that's all. The only corner case I'm aware of is if the user does mv /foo /baz Then in the current code we'll not be able to find the image unless the user reloads the document as /baz/a.lyx. But I don't see a "smart" way around that. > And yes, the bug still exists. Ie, paste is shoving in the "wrong" inset. I totally don't get this sorry :/ john
Re: Pasting the "wrong" inset.
Angus Leeming wrote: > If it were stored with a relative path in subdir/file.eps and I cut it and > pasted it into a new buffer with a different buffer->filePath(), we failed > to find the graphics file. Actually, this description is exactly wrong ;-) If the file is stored with a relative path and I either cut it or copy it and then paste it into a buffer with a different buffer->filePath(), then LyX _finds_ and displays it. Of course, no file exists at this absolute (new buffer) + (relative path to graphic file) location, so we should fail to find it and display nothing. And yes, the bug still exists. Ie, paste is shoving in the "wrong" inset. -- Angus
Re: Pasting the "wrong" inset.
Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | Sometime ago I put the following message into InsetGraphic::draw > | > | // MakeAbsPath returns filename_ unchanged if it is absolute > | // already. > | string const file_with_path = > | MakeAbsPath(params_.filename, bv->buffer()->filePath()); > | > | // A 'paste' operation creates a new inset with the correct > | filepath, // but then the 'old' inset stored in the 'copy' > | operation is actually // added to the buffer. > | // Thus, we should ensure that the filepath is correct. > | if (file_with_path != loader_.filename()) { > | params_.filename = file_with_path; > | update(params_); > | } > | > | I suspect that John's changes to store the absolute path name internally > | will have cured the symptoms of this problem, but it would be nice if > | paste used the correct inset... > > I do not quite get what you are at? Can you elaborate a bit? Sure. Sometime _last year_ I put this message into the method. Until John's clone patch, we stored the file internally sometimes with a relative path to the buffer and sometimes with an absolute path. If it were stored with a relative path in subdir/file.eps and I _cut_ it and pasted it into a new buffer with a different buffer->filePath(), we failed to find the graphics file. It turned out --- lots of digging --- that we were doing what I describe above. I don't know if this is still the case and suspect that the problem will be hidden if it is (because the absolute file path is now stored internally). Nonetheless it would appear to be a bug waiting to bite again. -- Angus
Re: [1.3.2] Don't assume sys/select.h exists
On Tue, Jun 03, 2003 at 01:31:51AM -0500, Albert Chin wrote: > Doesn't exist on HP-UX 11.x. Patch below against 1.3.2. Applied to CVS thanks. JMarc ? john
Re: boost::trackable confusion
On Tue, Jun 03, 2003 at 04:34:24PM +, Angus Leeming wrote: > There has been no attempt yet to connect a signal from the GraphicsLoader to > this->statusChanged() so there is no need for trackable to track anything > yet. > > Make sense now? > > (I'll fix it.) OK, thanks a lot Angus regards john
boost::trackable confusion
#warning I have zero idea about the trackable() InsetGraphics::InsetGraphics(InsetGraphics const & ig) : Inset(ig), - boost::signals::trackable(ig), + boost::signals::trackable(), graphic_label(uniqueID()), cache_(new Cache(*this)) { setParams(ig.params()); } Fortunately, I do ;-) trackable is tracking the existence of this instance of the class, or will do once a signal is connected to return to it. There has been no attempt yet to connect a signal from the GraphicsLoader to this->statusChanged() so there is no need for trackable to track anything yet. Make sense now? (I'll fix it.) -- Angus
Re: Pasting the "wrong" inset.
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Jun 03, 2003 at 04:21:14PM +, Angus Leeming wrote: | | > // A 'paste' operation creates a new inset with the correct filepath, | > // but then the 'old' inset stored in the 'copy' operation is actually | > // added to the buffer. | | I don't see how this can happen. We clone the inset used in cut_clone. Note that some of the implementation changed as part of the CutAndPaste work some weeks ago. -- Lgb
Re: update(), second try
On Tue, Jun 03, 2003 at 05:25:48PM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | Index: rowpainter.C > > Ok, I will try this out later tonight. (Sorry that I cannot test it > earlier.) Fine with me. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: update(), second try
Andre Poenitz <[EMAIL PROTECTED]> writes: | Index: rowpainter.C Ok, I will try this out later tonight. (Sorry that I cannot test it earlier.) -- Lgb
Re: Pasting the "wrong" inset.
Angus Leeming <[EMAIL PROTECTED]> writes: | Sometime ago I put the following message into InsetGraphic::draw | | // MakeAbsPath returns filename_ unchanged if it is absolute | // already. | string const file_with_path = | MakeAbsPath(params_.filename, bv->buffer()->filePath()); | | // A 'paste' operation creates a new inset with the correct filepath, | // but then the 'old' inset stored in the 'copy' operation is actually | // added to the buffer. | // Thus, we should ensure that the filepath is correct. | if (file_with_path != loader_.filename()) { | params_.filename = file_with_path; | update(params_); | } | | I suspect that John's changes to store the absolute path name internally | will have cured the symptoms of this problem, but it would be nice if paste | used the correct inset... I do not quite get what you are at? Can you elaborate a bit? -- Lgb
Re: update
John Levon <[EMAIL PROTECTED]> writes: | On Tue, Jun 03, 2003 at 05:10:28PM +0200, Andre Poenitz wrote: | | > Now, John, please... | | It's done it's done !! | | /me cowers Just like the one that lit up Chicago? -- Lgb
Re: Pasting the "wrong" inset.
On Tue, Jun 03, 2003 at 04:21:14PM +, Angus Leeming wrote: > // A 'paste' operation creates a new inset with the correct filepath, > // but then the 'old' inset stored in the 'copy' operation is actually > // added to the buffer. I don't see how this can happen. We clone the inset used in cut_clone. Can you explain further? regards john
Pasting the "wrong" inset.
Sometime ago I put the following message into InsetGraphic::draw // MakeAbsPath returns filename_ unchanged if it is absolute // already. string const file_with_path = MakeAbsPath(params_.filename, bv->buffer()->filePath()); // A 'paste' operation creates a new inset with the correct filepath, // but then the 'old' inset stored in the 'copy' operation is actually // added to the buffer. // Thus, we should ensure that the filepath is correct. if (file_with_path != loader_.filename()) { params_.filename = file_with_path; update(params_); } I suspect that John's changes to store the absolute path name internally will have cured the symptoms of this problem, but it would be nice if paste used the correct inset... -- Angus
[patch] update, re-done
Index: rowpainter.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v retrieving revision 1.18 diff -u -p -r1.18 rowpainter.C --- rowpainter.C30 May 2003 06:48:20 - 1.18 +++ rowpainter.C3 Jun 2003 15:17:11 - @@ -105,7 +105,12 @@ void RowPainter::paintInset(pos_type con lyx::Assert(inset); #warning inset->update FIXME - inset->update(perv(bv_), false); + //inset->update(perv(bv_), false); + MetricsInfo mi; + mi.base.bv = perv(bv_); + mi.base.font = getFont(pos); + Dimension dim; + inset->metrics(mi, dim); PainterInfo pi(perv(bv_)); pi.base.font = getFont(pos); @@ -291,8 +296,6 @@ void RowPainter::paintFromPos(pos_type & } paintForeignMark(orig_x, orig_font); - - return; } Index: text.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v retrieving revision 1.365 diff -u -p -r1.365 text.C --- text.C 28 May 2003 16:36:53 - 1.365 +++ text.C 3 Jun 2003 15:17:12 - @@ -310,7 +310,7 @@ int LyXText::singleWidth(ParagraphList:: // this IS needed otherwise on initialitation we don't get the fill // of the row right (ONLY on initialization if we read a file!) // should be changed! (Jug 20011204) - tmpinset->update(bv()); + //tmpinset->update(bv()); #endif return tmpinset->width(bv(), font); } @@ -1071,7 +1071,7 @@ void LyXText::setHeightOfRow(RowList::it if (tmpinset) { #if 1 // this is needed for deep update on initialitation #warning inset->update FIXME - tmpinset->update(bv()); + //tmpinset->update(bv()); #endif maxwidth += tmpinset->width(bv(), tmpfont); maxasc = max(maxasc, Index: insets/inset.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.h,v retrieving revision 1.99 diff -u -p -r1.99 inset.h --- insets/inset.h 3 Jun 2003 15:10:08 - 1.99 +++ insets/inset.h 3 Jun 2003 15:17:12 - @@ -160,9 +160,6 @@ public: int descent(BufferView *, LyXFont const &) const; /// int width(BufferView *, LyXFont const &) const; - /// update the inset representation - virtual void update(BufferView *, bool = false) - {} /// what appears in the minibuffer when opening virtual string const editMessage() const; /// Index: insets/insetcollapsable.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v retrieving revision 1.147 diff -u -p -r1.147 insetcollapsable.C --- insets/insetcollapsable.C 2 Jun 2003 10:03:22 - 1.147 +++ insets/insetcollapsable.C 3 Jun 2003 15:17:12 - @@ -286,23 +286,6 @@ int InsetCollapsable::docbook(Buffer con } -void InsetCollapsable::update(BufferView * bv, bool reinit) -{ - if (in_update) { - if (reinit && owner()) { - owner()->update(bv, true); - } - return; - } - in_update = true; - inset.update(bv, reinit); - if (reinit && owner()) { - owner()->update(bv, true); - } - in_update = false; -} - - Inset::RESULT InsetCollapsable::localDispatch(FuncRequest const & cmd) { //lyxerr << "InsetCollapsable::localDispatch: " << cmd.action << "\n"; Index: insets/insetcollapsable.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.h,v retrieving revision 1.109 diff -u -p -r1.109 insetcollapsable.h --- insets/insetcollapsable.h 2 Jun 2003 10:03:22 - 1.109 +++ insets/insetcollapsable.h 3 Jun 2003 15:17:12 - @@ -51,8 +51,6 @@ public: /// draw, either inlined (no button) or collapsed/open void draw(PainterInfo & pi, int x, int y, bool inlined) const; /// - void update(BufferView *, bool = false); - /// EDITABLE editable() const; /// bool insertInset(BufferView *, Inset * inset); Index: insets/insetert.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetert.C,v retrieving revision 1.129 diff -u -p -r1.129 insetert.C --- insets/insetert.C 3 Jun 2003 15:10:08 - 1.129 +++ insets/insetert.C 3 Jun 2003 15:17:12 - @@ -456,7 +456,7 @@ Inset::RESULT InsetERT::localDispatch(Fu t->need_break_row = t->rows().begin
Re: update
On Tue, Jun 03, 2003 at 05:10:28PM +0200, Andre Poenitz wrote: > Now, John, please... It's done it's done !! /me cowers john
Re: update
On Tue, Jun 03, 2003 at 05:01:18PM +0200, Lars Gullik Bjønnes wrote: > | [I doubt this touches the same code at all. It's basically 'commenting out > | all InsetFoo::update() implementations and all calls to Inset:update > | and add a call to Inset::metrics() in the rowpainter'.] > > could be a lot of fuzzy hunks. Ok. Now, John, please... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: update
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Tue, Jun 03, 2003 at 04:41:24PM +0200, Lars Gullik Bjønnes wrote: | > Andre Poenitz <[EMAIL PROTECTED]> writes: | > | > | I've played around with it a bit more and it seems to be working. | > | | > | So please have a look. Getting rid of Inset::update() seems to be a good | > | idea somehow... | > | > Let's do it like this: | > | > - Let John apply the clone patch | | No problem. The length of my right leg is unfortunately limited... | | [Is the "clone patch" the same thing he send to the list this morning | (last night?)] yes. | > - you create a new rediffed patch for us to look at/test | | [I doubt this touches the same code at all. It's basically 'commenting out | all InsetFoo::update() implementations and all calls to Inset:update | and add a call to Inset::metrics() in the rowpainter'.] could be a lot of fuzzy hunks. -- Lgb
Re: Inset::update()
On Tue, Jun 03, 2003 at 08:48:33AM +0200, Andre Poenitz wrote: > The attached patch basically disables Inset::update() and yet the sky > does not fall on our heads. > > There are some glitches in the table drawing (I've seen diagonal(!) lines > once) and somehow everything is left-aligned there but nested minipages etc > seem flawlessly. actually this sounds pretty much like the sky went into freefall ... actually fixing these bugs is probably extremely difficult. i.e. if we're going to do this I'd want it to be all working /before/ any commits. (And I can help with that wherever I can ...) john
Re: update
On Tue, Jun 03, 2003 at 04:41:24PM +0200, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | I've played around with it a bit more and it seems to be working. > | > | So please have a look. Getting rid of Inset::update() seems to be a good > | idea somehow... > > Let's do it like this: > > - Let John apply the clone patch No problem. The length of my right leg is unfortunately limited... [Is the "clone patch" the same thing he send to the list this morning (last night?)] > - you create a new rediffed patch for us to look at/test [I doubt this touches the same code at all. It's basically 'commenting out all InsetFoo::update() implementations and all calls to Inset:update and add a call to Inset::metrics() in the rowpainter'.] > - we report back > - you (do not) commit. Ok. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: update
Andre Poenitz <[EMAIL PROTECTED]> writes: | I've played around with it a bit more and it seems to be working. | | So please have a look. Getting rid of Inset::update() seems to be a good | idea somehow... Let's do it like this: - Let John apply the clone patch - you create a new rediffed patch for us to look at/test - we report back - you (do not) commit. -- Lgb
update
I've played around with it a bit more and it seems to be working. So please have a look. Getting rid of Inset::update() seems to be a good idea somehow... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)