Re: [PATCH] Painter split

On Tue, 11 Jun 2002, John Levon wrote: o s/PainterBase/Painter/ as discussed before o s/Painter/XPainter/ in xforms/ o remove some unused stuff in Painter o add begin()/end() for the benefit of Qt (not used yet) Look OK ? Looks good to me. (Asger, should I put you as original author ?

Re: can't open the paragraph dialog anymore...

I have this theory that football is great to play and crap to watch. I did try and watch the England game this morning, but got bored... I can't wait till Denmark beats England this Saturday! I sure hope that some channel in Portugal tramits this moster of a fight ;-) See some of you

Re: [PATCH] Painter split

On Tue, 11 Jun 2002, John Levon wrote: > o s/PainterBase/Painter/ as discussed before > o s/Painter/XPainter/ in xforms/ > o remove some unused stuff in Painter > o add begin()/end() for the benefit of Qt (not used yet) > > Look OK ? Looks good to me. > (Asger, should I put you as original

Re: can't open the paragraph dialog anymore...

> > I have this theory that football is great to play and crap to watch. I did > > try and watch the England game this morning, but got bored... I can't wait till Denmark beats England this Saturday! I sure hope that some channel in Portugal tramits this moster of a fight ;-) See some of you

Re: [PATCH] the dreaded work area patch again

On Tue, 11 Jun 2002, John Levon wrote: I'm going to try new executive summaries in the hope that this makes the purpose AND the rationale of each patch clearer. o removes useless methods belowMouse() and active() from workarea o hides access to the work area behind workarea() Good stuff.

Re: [PATCH] split font metrics

On Tue, 11 Jun 2002, John Levon wrote: o makes font_metrics a namespace o moves X-specific metric functions into xforms/ Simple enough change I think, and allows Qt to do its own thing with the metrics OK to apply ? This looks good to me as well. Greets, Asger

Re: [PATCH] the dreaded work area patch again

On Tue, 11 Jun 2002, John Levon wrote: > I'm going to try new "executive summaries" in the hope that this makes > the purpose AND the rationale of each patch clearer. > > o removes useless methods belowMouse() and active() from workarea > o hides access to the work area behind workarea() Good

Re: [PATCH] split font metrics

On Tue, 11 Jun 2002, John Levon wrote: > o makes font_metrics a namespace > o moves X-specific metric functions into xforms/ > > Simple enough change I think, and allows Qt to do its > own thing with the metrics > > OK to apply ? This looks good to me as well. Greets, Asger

Porto - here I come

Dear All, I have received my flight ticket now. I'll arrive in Oporto 12.50 on the 13th of June. My flight back to Denmark leaves at 13.15 on the 17th of June. Jose, could you please send your mobile number, and instructions for how to get to your place? BTW, what is the abbreviation for this

SixPack

Someone in the ANSOL list (Portuguese Free Software Association) propose the simple: SixPack That's a good one. Let's use that. Greets, Asger

Porto - here I come

Dear All, I have received my flight ticket now. I'll arrive in Oporto 12.50 on the 13th of June. My flight back to Denmark leaves at 13.15 on the 17th of June. Jose, could you please send your mobile number, and instructions for how to get to your place? BTW, what is the abbreviation for this

SixPack

> Someone in the ANSOL list (Portuguese Free Software Association) propose the > simple: SixPack That's a good one. Let's use that. Greets, Asger

Re: Insert Sourcecode GUI

On Thu, 23 May 2002, Herbert Voss wrote: the attached patch gives support for the listings-package to insert Source-code. it's avilable via insert-insert file-Dourcecode formatted a view of the gui: http://www.lyx.org/~voss/listings.gif A few comments based on the screenshot only: First

Re: Developers Meeting (was: Re: wrappers for xforms cont.)

On Thu, 23 May 2002, John Levon wrote: So, fellow devvies: What is your (stupid) reason to not attend? Really, money ! Record shops are evil ... How much money do you need? Maybe we can chip together... Greets, Asger

Re: Insert Sourcecode GUI

On Thu, 23 May 2002, Herbert Voss wrote: > the attached patch gives support for the listings-package > to insert Source-code. it's avilable via > > insert->insert file->Dourcecode formatted > > a view of the gui: http://www.lyx.org/~voss/listings.gif A few comments based on the screenshot only:

Re: Developers Meeting (was: Re: wrappers for xforms cont.)

On Thu, 23 May 2002, John Levon wrote: > > So, fellow devvies: What is your (stupid) reason to not attend? > > Really, money ! Record shops are evil ... How much money do you need? Maybe we can chip together... Greets, Asger

Re: preview-LyX ?

On 12 May 2002, David Kastrup wrote: Several of you probably are already aware of the preview-latex project where I am head developer. I delivered a talk about it at the recent I propose that you stay around a bit, and when 1.3.0 opens, we can look into this. Right now, LyX is in feature

Re: preview-LyX ?

On 12 May 2002, David Kastrup wrote: > Several of you probably are already aware of the preview-latex project > where I am head developer. I delivered a talk about it at the recent I propose that you stay around a bit, and when 1.3.0 opens, we can look into this. Right now, LyX is in feature

Re: relyx bugzilla

On Wed, 1 May 2002, Kayvan A. Sylvan wrote: | So, should I mass-WONTFIX relyx bugs Lars ? if we cannot hoax anyone to at least work on one og the bugs... You can go ahead and assign a few to me. I won't get it done for a week or two, but I will get it done. We do this in our use of

Re: relyx & bugzilla

On Wed, 1 May 2002, Kayvan A. Sylvan wrote: > > | So, should I mass-WONTFIX relyx bugs Lars ? > > > > if we cannot hoax anyone to at least work on one og the bugs... > > You can go ahead and assign a few to me. I won't get it done > for a week or two, but I will get it done. We do this in our

Re: [Bug 339] Cursor up/down in nested insets

On Mon, 22 Apr 2002, John Levon wrote: On Mon, Apr 22, 2002 at 05:28:21PM +0300, Eran Tromer wrote: A naive question of Bugzilla policy -- if this is an acknowledged by all as a problematic issue, why mark it WONTFIX as opposed to setting a far-away milestone or something? Definitely not

Re: [Bug 339] Cursor up/down in nested insets

On Mon, 22 Apr 2002, John Levon wrote: > On Mon, Apr 22, 2002 at 05:28:21PM +0300, Eran Tromer wrote: > > > A naive question of Bugzilla policy -- if this is an acknowledged by all > > as a problematic issue, why mark it WONTFIX as opposed to setting a > > far-away milestone or something?

Re: so... objections

On Thu, 18 Apr 2002, Herbert Voss wrote: if we want to build up a 16bit color correct to a 8 bit one than we cannot do only a shift of 8 bit to get the high or low byte. This is a very good approximation. we had to take every second _bit_ from the original one. Or every third if it's a 24

Re: so... objections

On Fri, 19 Apr 2002, Herbert Voss wrote: I want to understand, so please give an answer to this: r/g or b has a range from to or only 6 bits for some graphic cards. converting to for example 4 bit could'nt only take the significant nibble ... Assume you have the color

Re: so... objections

On Thu, 18 Apr 2002, Herbert Voss wrote: > if we want to build up a 16bit color correct to > a 8 bit one than we cannot do only a shift of > 8 bit to get the high or low byte. This is a very good approximation. > we had to take every second _bit_ from the original one. Or > every third if it's

Re: so... objections

On Fri, 19 Apr 2002, Herbert Voss wrote: > I want to understand, so please give an answer to this: > > r/g or b has a range from to or only 6 bits > for some graphic cards. > converting to for example 4 bit could'nt only take the significant > nibble ... Assume you have the

Re: Do you want a Porto (or the next LyX meeting)

On Fri, 22 Mar 2002, Jose Abilio Oliveira Matos wrote: The next LyX meeting will be here in Porto (Portugal), from 13 to 18 of June. (2002 of course :-) All LyX users and developers are invited. Thank you, and I'll be there! I hope lots and lots of others will join us! Greets,

Re: Do you want a Porto (or the next LyX meeting)

On Fri, 22 Mar 2002, Jose Abilio Oliveira Matos wrote: > The next LyX meeting will be here in Porto (Portugal), from 13 to 18 of > June. (2002 of course :-) > > All LyX users and developers are invited. Thank you, and I'll be there! I hope lots and lots of others will join us! Greets,

Re: a thought on insets and buffers...

On Sat, 16 Mar 2002, Angus Leeming wrote: I'm thinking of a biblioManager class, an instance of which is contained in the Buffer. It is connected to signals that can be emitted by any of it's BibKey and BibTeX insets, including those in daughter Buffers. In turn it will inform each of it's

Re: guii update

On Sun, 17 Mar 2002, John Levon wrote: now with working menus ... and background color ... and keyboard ... and /really/ slow rendering http://www.movement.uklinux.net/q4.diff.bz2 This is neat. I looked at the patch, and can see that there still is a long way to go, but I'm impressed that

Re: a thought on insets and buffers...

On Sat, 16 Mar 2002, Angus Leeming wrote: > I'm thinking of a biblioManager class, an instance of which is contained in > the Buffer. It is connected to signals that can be emitted by any of it's > BibKey and BibTeX insets, including those in daughter Buffers. In turn it > will inform each of

Re: guii update

On Sun, 17 Mar 2002, John Levon wrote: > now with working menus ... and background color ... and keyboard ... > and /really/ slow rendering > > http://www.movement.uklinux.net/q4.diff.bz2 This is neat. I looked at the patch, and can see that there still is a long way to go, but I'm impressed

Re: a thought on insets and buffers...

On Fri, 16 May 1997, Duncan Simpson wrote: Why? I fail to see the need, unless somewhere wants a list of references refered to in the buffer. I can not see any application of such a list which is not infrequent enough to make scanning the document an acceptable alternative. Do not take

Re: a thought on insets and buffers...

On Fri, 16 May 1997, Duncan Simpson wrote: > Why? I fail to see the need, unless somewhere wants a list of references > refered to in the buffer. I can not see any application of such a list which > is not infrequent enough to make scanning the document an acceptable > alternative. Do not take

Re: eqascii

On Fri, 15 Mar 2002, Andre Poenitz wrote: I think I had already a look at it and did not really like the coding. You don't have to like the implementation to use the program. But implementing it similarly to what we have for 'real' drawing with some kind of ASCII painter is not really hard

Re: eqascii

On Fri, 15 Mar 2002, Andre Poenitz wrote: It does work only for a part of the kind of math LyX. Try \sqrt[3]{2} for starters. Or most of the AMS environments. I know. It will not do for people written math or physic papers. However, I think it will do for high-school students solving simple

Re: a thought on insets and buffers...

A buffer should contain a number of buffer wide data. This could be a list of bibliographic entries, or a list of labels. This information naturally belongs in the buffer. Some insets need access to this information, primarily because they reference it. Therefore, these insets logically should

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Asger K. Alstrup Nielsen wrote: Therefore, I'm inclined to think that insets *should* know about their buffer. I believe this will make many things simpler. I forgot to elaborate on this: It's comparable to the discussion about whether to use object oriented programming

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: How does the undo architecture look like? Maybe even one that does not work on the outer paragraph level only, but on smaller scopes if possible? Conceptually, you can handle undo by having a stack of documents. Now, you want smaller scope. I presume

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: In other words, you *will* have to by pointer shuffling if such an inset is moved around. Not when the inset does not contain any such pointer. You are correct that you could relieve the insets of this duty. However, the duty is just moved to a

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: Making everything into a object variable is like making it 'locally global'. Suddenly much more functions (namely the other member functions of the class) gain access to data that should be available to only to one of them. This is not what we are

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: My point is: THERE IS NO NEED TO STORE REFERENCES TO BUFFERWIDE DATA IN THE INSET. Yes, maybe the bibliographic entry is a string, and just that. However, the semantics of this string is defined by the buffer wide database, and in some cases, this

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: On Fri, Mar 15, 2002 at 03:33:39PM +0100, Asger K. Alstrup Nielsen wrote: I'm just saying once more: We have the need for leaves to acces information higher in the tree. Can we agree on that? Yes. Although one of my major points

Re: a thought on insets and buffers...

On 15 Mar 2002, Jean-Marc Lasgouttes wrote: Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre So in order to draw bib stuff correctly using 'one hop Andre back-references' I have to implement a method to go up in a Andre math inset? This is a case for math insets to be composed of

Re: eqascii

On Fri, 15 Mar 2002, Andre Poenitz wrote: > I think I had already a look at it and did not really like the coding. You don't have to like the implementation to use the program. > But implementing it similarly to what we have for 'real' drawing with some > kind of ASCII painter is not really

Re: eqascii

On Fri, 15 Mar 2002, Andre Poenitz wrote: > It does work only for a part of the kind of math LyX. Try \sqrt[3]{2} for > starters. Or most of the AMS environments. I know. It will not do for people written math or physic papers. However, I think it will do for high-school students solving simple

Re: a thought on insets and buffers...

A buffer should contain a number of buffer wide data. This could be a list of bibliographic entries, or a list of labels. This information naturally belongs in the buffer. Some insets need access to this information, primarily because they reference it. Therefore, these insets logically should

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Asger K. Alstrup Nielsen wrote: > Therefore, I'm inclined to think that insets *should* know > about their buffer. I believe this will make many things > simpler. I forgot to elaborate on this: It's comparable to the discussion about whether to use object

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: > How does the undo architecture look like? Maybe even one that does not > work on the outer paragraph level only, but on smaller scopes if possible? Conceptually, you can handle undo by having a stack of documents. Now, you want smaller scope. I

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: > > In other words, you *will* have to by pointer shuffling if such an inset > > is moved around. > > Not when the inset does not contain any such pointer. You are correct that you could relieve the insets of this duty. However, the duty is just moved

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: > Making everything into a object variable is like making it 'locally > global'. Suddenly much more functions (namely the other member functions of > the class) gain access to data that should be available to only to one > of them. This is not what we

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: > My point is: > >THERE IS NO NEED TO STORE REFERENCES TO BUFFERWIDE DATA IN THE INSET. Yes, maybe the bibliographic entry is a string, and just that. However, the semantics of this string is defined by the buffer wide database, and in some cases,

Re: a thought on insets and buffers...

On Fri, 15 Mar 2002, Andre Poenitz wrote: > On Fri, Mar 15, 2002 at 03:33:39PM +0100, Asger K. Alstrup Nielsen wrote: > > I'm just saying once more: We have the need for leaves to acces > > information higher in the tree. Can we agree on that? > > Yes. Although o

Re: a thought on insets and buffers...

On 15 Mar 2002, Jean-Marc Lasgouttes wrote: > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > > Andre> So in order to draw bib stuff correctly using 'one hop > Andre> back-references' I have to implement a method to go up in a > Andre> math inset? This is a case for math insets to

eqascii

Hi, A suggestion for Andre: Use eqascii to implement ascii output of math formulas. Use google to find it. Greets, Asger

eqascii

Hi, A suggestion for Andre: Use eqascii to implement ascii output of math formulas. Use google to find it. Greets, Asger

q1.diff.bz2

Hi, I read the patch quickly, and it looks fine to me. Of course, a ChangeLog would be nice, because it is practically impossible to see what changes you have done to files that were moved. Greets, Asger

q1.diff.bz2

Hi, I read the patch quickly, and it looks fine to me. Of course, a ChangeLog would be nice, because it is practically impossible to see what changes you have done to files that were moved. Greets, Asger

Re: lyxtextclass optimization

On Mon, 11 Mar 2002, Lars Gullik Bjønnes wrote: all lookup functions has changed from O(n) to O(log n) delete_layout is still O(n), but with a higer constant factor. + typedef std::mapstring, int LayoutMap; Please note that std::map has a terrible constant factor in practically all

Re: lyxtextclass optimization

On Mon, 11 Mar 2002, Lars Gullik Bjønnes wrote: > all lookup functions has changed from O(n) to O(log n) > delete_layout is still O(n), but with a higer constant factor. > + typedef std::map LayoutMap; Please note that std::map has a terrible constant factor in practically all

Re: [Devel] Child processes menu item

On Wed, 27 Feb 2002, John Levon wrote: On Wed, Feb 27, 2002 at 11:33:48PM +0100, Michael Schmitt wrote: I guess you have added the dialog for testing purposes only, haven't you? (Please, please say yes) I agree to a small degree I don't see the purpose of the dialog I'm the one that

Re: [Devel] Child processes menu item

On Thu, 28 Feb 2002, John Levon wrote: On Thu, Feb 28, 2002 at 11:09:33AM +0100, Asger K Alstrup Nielsen wrote: Historically, we have seen that external programs crash, stop, or so it /is/ a debugging tool You can say that if you want to I'd rather compare it with the emergency save

Re: [Devel] "Child processes" menu item

On Wed, 27 Feb 2002, John Levon wrote: > On Wed, Feb 27, 2002 at 11:33:48PM +0100, Michael Schmitt wrote: > > > I guess you have added the dialog for testing purposes only, haven't > > you? (Please, please say "yes") > > I agree to a small degree. I don't see the purpose of the dialog I'm the

Re: [Devel] "Child processes" menu item

On Thu, 28 Feb 2002, John Levon wrote: > On Thu, Feb 28, 2002 at 11:09:33AM +0100, Asger K. Alstrup Nielsen wrote: > > > Historically, we have seen that external programs crash, stop, or > > so it /is/ a debugging tool. You can say that if you want to. I'd rather compare it

Re: coding style question

On Mon, 25 Feb 2002, Angus Leeming wrote: void GImageXPM::scale(GParams const params) { if (!xpm_image_) return; } The principle behind scaling is simple: It's raytracing. So, for each destination pixel, calculate which pixel it corresponds to in the source picture.

Re: coding style question

On Mon, 25 Feb 2002, Angus Leeming wrote: > void GImageXPM::scale(GParams const & params) > { > if (!xpm_image_) > return; > > } The principle behind scaling is simple: It's raytracing. So, for each destination pixel, calculate which pixel it corresponds to in the source

Re: RGB - grayscale (was Re: Remarks about graphics in lyx1.2.0cvs)

On Thu, 21 Feb 2002, Mike Ressler wrote: Actually, the better way to do this is (xv Postscript code) gray = 0.32 * red + 0.5 * green + 0.18 * blue or perhaps (NTSC) gray = 0.30 * red + 0.59 * green + 0.11 * blue Either gives a better match to a human's RGB to luminance

Re: RGB -> grayscale (was Re: Remarks about graphics in lyx1.2.0cvs)

On Thu, 21 Feb 2002, Mike Ressler wrote: > Actually, the better way to do this is (xv Postscript code) > > gray = 0.32 * red + 0.5 * green + 0.18 * blue > > or perhaps (NTSC) > > gray = 0.30 * red + 0.59 * green + 0.11 * blue > > Either gives a better match to a human's RGB to

Re: Remarks about graphics in lyx1.2.0cvs

On Thu, 21 Feb 2002, Angus Leeming wrote: and the problem is now defining an appropriate mapping from the colour colourmap to a grayscale or monochrome one. I'm not sure what the problem is, but if you want to convert from color to grayscale, just do this: int gray = (red + blue + green) /

Re: Remarks about graphics in lyx1.2.0cvs

On Thu, 21 Feb 2002, Angus Leeming wrote: > and the problem is now defining an appropriate mapping from the colour > colourmap to a grayscale or monochrome one. I'm not sure what the problem is, but if you want to convert from color to grayscale, just do this: int gray = (red + blue + green)

Re: Scripting

On Mon, 18 Feb 2002, Andre Poenitz wrote: I'd like to have the decision on LyX's favourite scripting language first. www.lua.org. Greets, Asger

Re: Scripting

On Mon, 18 Feb 2002, Andre Poenitz wrote: > I'd like to have the decision on LyX's favourite scripting language first. www.lua.org. Greets, Asger

Re: Why Figure #: and Table #:; why not using real numbers?

On Mon, 11 Feb 2002, R. Lahaye wrote: After all, for example, sections are also numbered (and renumbered when necessary); so why not doing the same for figures and tables? I don't know. I think it might be because it's easiest to implement the # character. One argument to keep the hash is

Re: Why "Figure #:" and "Table #:"; why not using real numbers?

On Mon, 11 Feb 2002, R. Lahaye wrote: > After all, for example, sections are also numbered (and renumbered > when necessary); so why not doing the same for figures and > tables? I don't know. I think it might be because it's easiest to implement the # character. One argument to keep the hash is

Re: Chess board now a problem :(

On Thu, 7 Feb 2002, Kayvan A. Sylvan wrote: wait a minute... xboard doesn't overwrite existing files when renaming a previous game save by the looks... yes... really helpful. No warning or anything... Yeah, a pet peeve of mine. It just appends!!! The maintainer of xboard is really

Re: Chess board now a problem :(

On Thu, 7 Feb 2002, Kayvan A. Sylvan wrote: > > wait a minute... xboard doesn't overwrite existing files when > > renaming a previous game save by the looks... yes... really helpful. > > No warning or anything... > > Yeah, a pet peeve of mine. It just appends!!! The maintainer of xboard is

Re: Dreaming of plugins...

On Sat, 2 Feb 2002, Jules Bean wrote: Something which I think would really be a *killer* feature for LyX would be the ability to write plug-ins to handle custom environments. You can do what you want with the external material inset that is already there. Greets, Asger

Re: Dreaming of plugins...

On Mon, 4 Feb 2002, John Levon wrote: no you can't. the external material inset is very basic and provides no interface inside lyx, which is what he was asking for. Suppose we wanted to implement the spread-sheet functionality that Martin recently hacked up. In overall terms, which approaches

Re: Dreaming of plugins...

On Sat, 2 Feb 2002, Jules Bean wrote: > Something which I think would really be a *killer* feature for LyX > would be the ability to write plug-ins to handle custom environments. You can do what you want with the external material inset that is already there. Greets, Asger

Re: Dreaming of plugins...

On Mon, 4 Feb 2002, John Levon wrote: > no you can't. the external material inset is very basic and provides no > interface inside lyx, which is what he was asking for. Suppose we wanted to implement the spread-sheet functionality that Martin recently hacked up. In overall terms, which

Re: (Jug) [Devel] Revised bug list - tables

On Fri, 25 Jan 2002, Jürgen Vigna wrote: What I don´t know is the format of leftline without the =true part. Is this more or less valid XML code? I changed this fileformat from the compact one before to this format to have an XML like format so I surely don´t change it back to an

Re: (Jug) [Devel] Revised bug list - tables

On Fri, 25 Jan 2002, Jürgen Vigna wrote: > What I don´t know is the format of leftline without the =true part. > Is this more or less valid XML code? I changed this fileformat from > the compact one before to this format to have an XML like format so > I surely don´t change it back to an

Re: a thought

On 14 Jan 2002, Jean-Marc Lasgouttes wrote: Python does not yet play a role in LyX AFAIK. The external material inset includes a few definitions that rely on Python. Greets, Asger

Re: a thought

On 14 Jan 2002, Jean-Marc Lasgouttes wrote: > Python does not yet play a role in LyX AFAIK. The external material inset includes a few definitions that rely on Python. Greets, Asger

Re: spellchecker crash

On Tue, 8 Jan 2002, Lars Gullik Bjønnes wrote: if fl_get_browser_line can return null, then it must be char const * tmp = fl_get_browser_line(...); string blah = (tmp ? tmp : ); I think you meant string blah = tmp ? tmp : string(); Never use as a substitute for string(). It's not as

Re: spellchecker crash

On Tue, 8 Jan 2002, Lars Gullik Bjønnes wrote: > if fl_get_browser_line can return null, then it must be > > char const * tmp = fl_get_browser_line(...); > string blah = (tmp ? tmp : ""); I think you meant string blah = tmp ? tmp : string(); Never use "" as a substitute for string(). It's

Re: RFC: Sound Approach?

On Sun, 30 Dec 2001, Ben Stanley wrote: typedef vectorshared_ptrParagraph ParagraphList; Of course, your choice of vector or list depends on what iterator properties you want; vector gives you random access, whereas list only gives you bidirectional iterators (this is all we are

Re: RFC: Sound Approach?

On Sun, 30 Dec 2001, Asger K. Alstrup Nielsen wrote: typedef listshared_ptrParagraph ParagraphList; But of course this *has* to wait till after 1.2.0. Greets, Asger

Re: RFC: Sound Approach?

On Sun, 30 Dec 2001, Ben Stanley wrote: > typedef vector ParagraphList; > > Of course, your choice of vector or list depends on what iterator > properties you want; vector gives you random access, whereas list only > gives you bidirectional iterators (this is all we are currently

Re: RFC: Sound Approach?

On Sun, 30 Dec 2001, Asger K. Alstrup Nielsen wrote: > typedef list<shared_ptr > ParagraphList; But of course this *has* to wait till after 1.2.0. Greets, Asger

Re: Crash on File Menu

On 18 Dec 2001, Jean-Marc Lasgouttes wrote: Lars It is kindo a philosophical question. (where to declare global Lars objects) I would say global objects can be declared where ones expects to see them, i.e. together with their class definition, or in a given header file which contains

Re: Crash on File Menu

On 18 Dec 2001, Jean-Marc Lasgouttes wrote: > Lars> It is kindo a philosophical question. (where to declare global > Lars> objects) > > I would say global objects can be declared where ones expects to see > them, i.e. together with their class definition, or in a given header > file which

Re: Some bugs

On Fri, 14 Dec 2001, Juergen Vigna wrote: [Blah, blah, blah, blah, blah] So, when and where is the next LyX developer's meeting going to be held? It seems Juergen needs some fun to lighten up. He could sure need to drink some beer, introduce a bunch of bugs in the code, and sleep in forbidden

Re: Some bugs

On Fri, 14 Dec 2001, Juergen Vigna wrote: [Blah, blah, blah, blah, blah] So, when and where is the next LyX developer's meeting going to be held? It seems Juergen needs some fun to lighten up. He could sure need to drink some beer, introduce a bunch of bugs in the code, and sleep in forbidden

Re: new spam control?

On Thu, 13 Dec 2001, Juergen Vigna wrote: Well IMO that we could do something like that on lyx-devel as I've seen that lot's of devel list restrict the access much more. Are there really Those mailing lists are broken, IMO. Once upon a time, we needed a small feature in GTK to let it live

Re: new spam control?

On Thu, 13 Dec 2001, Juergen Vigna wrote: > Well IMO that we could do something like that on lyx-devel as I've seen > that lot's of devel list restrict the access much more. Are there really Those mailing lists are broken, IMO. Once upon a time, we needed a small feature in GTK to let it live

Re: dramantic increases in forced rodent use

On Wed, 12 Dec 2001, John Levon wrote: Richard is not talking about accessibility. He is talking about keyboard interaction, and that is an xforms bug. John, with all respect: Rule number one in usability is to listen to the users. Traditionally, LyX has gone to great lengths to work around

Re: dramantic increases in forced rodent use

On Wed, 12 Dec 2001, John Levon wrote: > Richard is not talking about accessibility. He is talking about keyboard interaction, > and that is an xforms bug. John, with all respect: Rule number one in usability is to listen to the users. Traditionally, LyX has gone to great lengths to work

Re: Bug list - Update

Hi, Just curious: That bug list is huge, and I'm lazy. How many of the bugs are showstoppers that must be fixed for 1.2.0? Greets, Asger

Re: Bug list - Update

Hi, Just curious: That bug list is huge, and I'm lazy. How many of the bugs are showstoppers that must be fixed for 1.2.0? Greets, Asger

  1   2   3   4   5   6   7   8   9   >