. Clearly, that's not the case if we
were to store a binary image format like PNG.
However, in these days of a PNG-aware frontend, it does seem strange
that we still ship these XPM files to our consumers. Here's a thought:
why don't we make the XPM -> PNG transformation part of
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Because that is not needed either. We can just the frontend's
Andre> resource system and would not need to ship individual files at
Andre> all.
>> I do not think this gains anything.
Andre> Slightly quicker loading of individual p
e tiny storing full diffs would not
> Andre> even be expensive either.
>
> Probably.
>
> >> However, in these days of a PNG-aware frontend, it does seem
> >> strange that we still ship these XPM files to our consumers. Here's
> >> a thought: why don
in these days of a PNG-aware frontend, it does seem
>> strange that we still ship these XPM files to our consumers. Here's
>> a thought: why don't we make the XPM -> PNG transformation part of
>> the build process and ship the resulting PNGs?
Andre> Because that i
On Sat, Jun 16, 2007 at 11:43:13PM -0700, Angus Leeming wrote:
> Andre Poenitz wrote:
> >>However, in these days of a PNG-aware frontend, it does seem strange
> >>that we still ship these XPM files to our consumers. Here's a thought:
> >>why don't we ma
Andre Poenitz wrote:
However, in these days of a PNG-aware frontend, it does seem strange
that we still ship these XPM files to our consumers. Here's a thought:
why don't we make the XPM -> PNG transformation part of the build
process and ship the resulting PNGs?
Because that
these XPM files to our consumers. Here's a thought:
> why don't we make the XPM -> PNG transformation part of the build
> process and ship the resulting PNGs?
Because that is not needed either. We can just the frontend's resource
system and would not need to ship individual files at all.
Andre'
a PNG-aware frontend, it does seem strange
that we still ship these XPM files to our consumers. Here's a thought:
why don't we make the XPM -> PNG transformation part of the build
process and ship the resulting PNGs?
Angus (just musing)
On Sun, Mar 17, 2002 at 08:37:49PM +0100, Asger K. Alstrup Nielsen wrote:
> of some kind, and how many insets cheat by using the current_view,
glad to say: none :)
The bad guys left are CutAndPaste, bufferlist, GraphicsCacheItem,
trans_mgr and bits of paragraph.
of course this doesn't mean we'
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'
On 15-Mar-2002 John Levon wrote:
> Um, we've seen several obscure bugs due to doing this inside insettext,
> just in the 1.2.0 era. Now insettext isn't exactly the simplest
> of insets, but maybe that's the point ...
Did you ask yourself why we have this problems? IMO we have the problems
becau
On Fri, Mar 15, 2002 at 06:09:11PM +, John Levon wrote:
> > How often do you resize your window?
>
> Have you seen how awful LyX is at re-breaking ? It takes /seconds/
I know. I believe this is related to the overly complex stucture.
> I'll be happy if you fix this at the same time !
Looks
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
On Friday 16 May 1997 10:35 pm, Duncan Simpson wrote:
> Asger writes
>
> >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.
>
> Why? I fail to see the need, unless some
Asger writes
>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.
Why? I fail to see the need, unless somewhere wants a list of references
refered to in the buffer. I can n
On Fri, Mar 15, 2002 at 02:27:20PM +0100, Andre Poenitz wrote:
> Sure, why not? I'd even check after each key press for rebreak. What's
> wrong with shuffling around a few kByte as reaction of _user input_?
>
> How often do you resize your window?
Have you seen how awful LyX is at re-breaking ?
On Fri, Mar 15, 2002 at 01:39:27PM +0100, Asger K. Alstrup Nielsen wrote:
> The discussion is a discussion about whether it is hard
> to keep back links alive in a tree. Come on, it is not.
> This is stuff from the first page in the data structure
> book.
Um, we've seen several obscure bugs due
On Fri, Mar 15, 2002 at 04:42:28PM +0100, Asger K. Alstrup Nielsen wrote:
> This is a case for math insets to be composed of the same stuff
> as the other insets.
Or the other way round...
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
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 b
> "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?
Andre> After all, the entry might live in a \mbox{} or \text{} within
Andre> a math inset
On Fri, Mar 15, 2002 at 04:17:24PM +0100, Jean-Marc Lasgouttes wrote:
> Andre> I don't understand you. Maybe one should tell me what "a
> Andre> bibliographic entry" is. Something that translates to
> Andre> "\cite{FooBar1998}"?
>
> In order to draw itself, this inset needs to query the buffer to
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I don't understand you. Maybe one should tell me what "a
Andre> bibliographic entry" is. Something that translates to
Andre> "\cite{FooBar1998}"?
In order to draw itself, this inset needs to query the buffer to show
itself in semi
On 15-Mar-2002 Jean-Marc Lasgouttes wrote:
> I'd prefer to have this implemented correctly in terms of an augmented
> cursor, than an abstract struct where everybody will want to add
> exotic members (current moon phase?) just in case it is needed.
Well as much as I know cursors only work if we
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Fri, Mar 15, 2002 at 03:05:28PM +0100, Asger K. Alstrup
Andre> Nielsen wrote:
>> Maybe the set of operations that need to have this back-link in the
>> parameters is limited. However, such a structure *will* stiffle
>> change: T
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Maybe at some point where you want to call an inset method, you do
>> not known the Buffer.
Andre> I always start at LyXFunc::dispatch or something similar. How
Andre> can I not know the buffer there?
So you propoagate this informati
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Fri, Mar 15, 2002 at 01:59:14PM +0100, Jean-Marc Lasgouttes
Andre> wrote:
>> Since we will likely have a paragraphcontainer, the inset should
>> now about the container it is in. Then the container will know
>> about the documen
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Sure, why not? I'd even check after each key press for rebreak.
Andre> What's wrong with shuffling around a few kByte as reaction of
Andre> _user input_?
It is just that you do not represent internally data, but it's
representatio
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 is that this
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 is that this happens less often than
one would expect.
> Your a
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, th
On Fri, Mar 15, 2002 at 03:05:28PM +0100, Asger K. Alstrup Nielsen wrote:
> Maybe the set of operations that need to have this back-link
> in the parameters is limited. However, such a structure *will*
> stiffle change: The day that you discover that the foo-method
> could really use a back-link,
On Fri, Mar 15, 2002 at 02:54:18PM +0100, Jean-Marc Lasgouttes wrote:
> And then you have to make sure that all the fileds of the structures
> are correctly initialized whenever a method want to use one of them.
Sure. That's what constructors are for... but I guess I do not get your
point ;-}
>
On Fri, Mar 15, 2002 at 02:40:35PM +0100, Asger K. Alstrup Nielsen 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.
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 ar
On 15-Mar-2002 Asger K. Alstrup Nielsen wrote:
> 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
On Fri, Mar 15, 2002 at 01:46:57PM +0100, Asger K. Alstrup Nielsen wrote:
> The reason is simply that in many cases the problem
> is better solved by encapsulating the information in
> an object that all the stakeholders have access to.
> This is more maintainable over the long run.
I forgot to m
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> If you have functions requiring a lot of parameters or if you
Andre> are not sure whether you need to change the signature soon you
Andre> simply put all (or at least the 'instable' args) in a structure
Andre> and pass down a (poss
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
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 presum
On Fri, Mar 15, 2002 at 02:03:58PM +0100, Jean-Marc Lasgouttes wrote:
> The trick is to avoid storing references to objects with which you do
> not have direct relations. This way, you can update the backref from
> an object to its parent at the time where you insert/delete it in the
> parent.
Ma
On Fri, Mar 15, 2002 at 02:01:25PM +0100, Jean-Marc Lasgouttes wrote:
> What a line?? A physical line on screen?
Yes.
> Do you want to change the whole data structure every times the window
> is resized.
Sure, why not? I'd even check after each key press for rebreak. What's
wrong with shuffling
On Fri, Mar 15, 2002 at 01:59:14PM +0100, Jean-Marc Lasgouttes wrote:
> Since we will likely have a paragraphcontainer, the inset should now
> about the container it is in. Then the container will know about the
> document/inset it is in. I think this information is very easy to
> update (change t
On Fri, Mar 15, 2002 at 01:57:32PM +0100, Lars Gullik Bjønnes wrote:
> Yes... but we also want to avoid to have a Buffer, Paragraph or
> whatever parametere to every function all over.
Of course.
And I still argue that you will see in the end that this won't be necessary
in general for 'every fu
On Fri, Mar 15, 2002 at 01:46:57PM +0100, Asger K. Alstrup Nielsen wrote:
> This stiffles change, because to introduce a new
> parameter requires changes all over the place.
> Therefore, most functional programming languages are
> introducing object orientation into their type systems.
If you hav
On Fri, Mar 15, 2002 at 01:39:27PM +0100, Asger K. Alstrup Nielsen wrote:
> Some insets need access to this information, primarily because
> they reference it.
The necessary information can be passed down as function argument to those
functions that need it. The inset does not have to store it pe
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Sure one needs to hand down stuff _somehow_. My point is that
Andre> storing "permanent" pointers to "authorities" and keeping them
Andre> up-to-date is painful compared to passing around the required
Andre> information when it is
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I could imagine a paragraph being an inset containing "lines".
Andre> A line in turn keeps "pieces" i.e either a sequence of chars
Andre> with the same attributes or another inset.
What a line?? A physical line on screen? Do you w
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>
Lars> | Lars> IMHO an inset should know nothing about buffers, what
Lars> they need | Lars> to know about is
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Mar 15, 2002 at 01:10:29PM +0100, Lars Gullik Bjønnes wrote:
>> | _Why_ does an inset need to know about its surrounding paragraph?
>>
>> somethings needs to know, whether it is a visitor function or a
>> function in the class it self.
>
| But
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 programmi
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 kn
On Fri, Mar 15, 2002 at 01:10:29PM +0100, Lars Gullik Bjønnes wrote:
> | _Why_ does an inset need to know about its surrounding paragraph?
>
> somethings needs to know, whether it is a visitor function or a
> function in the class it self.
But it does not have to _store_ the information, does it
On Fri, Mar 15, 2002 at 01:01:19PM +0100, Lars Gullik Bjønnes wrote:
> But of course a problem arises when paragraphs resides inside insets,
> what should the paragraph then know about? the buffer _or_ the
> surrounding inset?
No inset should permanently store data about its surroundings (apart f
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Mar 15, 2002 at 12:34:32PM +0100, Lars Gullik Bjønnes wrote:
>> | Yes!
>>
>> Should it also be paragraph agnostic?
>
| Actually, I think yes. But I am not completely sure.
>
| I could imagine a paragraph being an inset containing "lines". A lin
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> IMHO an inset should know nothing about buffers, what they need
| Lars> to know about is paragraphs. Paragraphs on the other hand needs
| Lars> to know about buffers.
>
| Th
On Fri, Mar 15, 2002 at 12:34:32PM +0100, Lars Gullik Bjønnes wrote:
> | Yes!
>
> Should it also be paragraph agnostic?
Actually, I think yes. But I am not completely sure.
I could imagine a paragraph being an inset containing "lines". A line in
turn keeps "pieces" i.e either a sequence of char
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> IMHO an inset should know nothing about buffers, what they need
Lars> to know about is paragraphs. Paragraphs on the other hand needs
Lars> to know about buffers.
This would certainly be a good compromise. And inset already kn
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Mar 15, 2002 at 09:32:42AM +, Angus Leeming wrote:
>> Some initial points:
>> * it would be nice if insets were buffer agnostic
>
| Yes!
Should it also be paragraph agnostic?
IMHO an inset should know nothing about buffers, what they need
On Fri, Mar 15, 2002 at 11:12:51AM +0100, Jean-Marc Lasgouttes wrote:
> Andre> Neither. Insets should be completely buffer agnostic. Buffer
> Andre> specific information should be handed down by arguments to any
> Andre> function that need to access it. In general, this should not be
> Andre> the
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Neither. Insets should be completely buffer agnostic. Buffer
Andre> specific information should be handed down by arguments to any
Andre> function that need to access it. In general, this should not be
Andre> the buffer pointer, bu
On Fri, Mar 15, 2002 at 09:32:42AM +, Angus Leeming wrote:
> Some initial points:
> * it would be nice if insets were buffer agnostic
Yes!
> * we have tried not to store a Buffer ptr in the insets and have largely
> succeeded, but not quite. That biggie insettabular stores the buffer.
We s
... and a question.
Some initial points:
* it would be nice if insets were buffer agnostic
* we have tried not to store a Buffer ptr in the insets and have largely
succeeded, but not quite. That biggie insettabular stores the buffer.
* cut and paste still makes use of current_view.
It seems to
At 10:45 PM 1/14/02 +0100, Asger K. Alstrup Nielsen wrote:
>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.
I also remember that Baruch Even worked for a while on embedd
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
> "Steve" == Steve Herrick <[EMAIL PROTECTED]> writes:
Steve> But what I'm writing to talk about is not the GUI. In fact, it
Steve> may be incompatible with it. I was noticing that LyX written
Steve> largely in C++, but Kathryn's site made it appear that Python
Steve> also plays a role.
Pyt
Hello! I'm a long-time Mac user who is gradually trying to shift over to
open-source software. The biggest reason I haven't shifted farther and faster
than I have is that a big part of what I do is DTP. After a prolonged study,
I've concluded that LyX is the closest thing on the "market." I am cur
66 matches
Mail list logo
