Alfredo Braunstein wrote:
I'm not sure about that. Specially since there's no difference in the
scrollbar size in a mid-sized document vs a big document like UG, because
most toolkits have a minimum size for the widget.
Small documents are important too.
It shouldn't jump at all (otherwise is just
Alfredo Braunstein wrote:
Small documents are important too.
Sure, I am only noting that it is a feature that only *exists* in small
documents. Thus, it cannot be so fundamentally important.
It serves as important feedback on the size of the document.
Well, we could just keep (maybe outdated)
Alfredo Braunstein wrote:
I think you didn't understand what I suggested.
I suggested to do a fullrebreak on start (foreground or background) and then
keep outer paragraphs sizes. Only update sizes when drawing paragraphs
on-screen, and live with outdated sizes for out-of-screen outer
I believe that a fixed sized scroll bar is a significant regression in
terms of usability.
Also, I think that a very unreliable scroll bar is a problem. The scroll
bar can change a few pixels, but if it jumps much more than that, it is
confusing.
I did not test the new scrollbar, but if you
The tradition about displaying nice paths on windows does not exist: Either
you do the complicated:
C:\Documents and settings\alstrup\My documents\My file.lyx
C:\Documents and settings\alstrup\Desktop\My second file.lyx
C:\My third file.lyx
or you ignore the path and just do (like all the
John Levon wrote:
To improve further, consider the insets in the paragraph by having a
default size for each type and take that into account. Now, we are linear
There's no such thing as a linear size for figures, so this is
guaranteed to go wrong in the worst possible cases (very large figures).
Angus Leeming wrote:
Asger Alstrup wrote:
The tradition about displaying nice paths on windows does not exist:
So you think that having such functionality is a bad thing for LyX/Win?
The only real problem here seems to be the ~ abbreviation.
Well, it is not necessarily a bad thing
Alfredo Braunstein wrote:
I'm not sure about that. Specially since there's no difference in the
scrollbar size in a mid-sized document vs a big document like UG, because
most toolkits have a minimum size for the widget.
Small documents are important too.
It shouldn't jump at all (otherwise is just
Alfredo Braunstein wrote:
Small documents are important too.
Sure, I am only noting that it is a feature that only *exists* in small
documents. Thus, it cannot be so fundamentally important.
It serves as important feedback on the size of the document.
Well, we could just keep (maybe outdated)
Alfredo Braunstein wrote:
I think you didn't understand what I suggested.
I suggested to do a fullrebreak on start (foreground or background) and then
keep outer paragraphs sizes. Only update sizes when drawing paragraphs
on-screen, and live with outdated sizes for out-of-screen outer
I liked it better with the TOC, and then all the details in one big page,
without any need for clicking hundreds of small checkboxes and all that.
Regards,
Asger
I liked it better with the TOC, and then all the details in one big page,
without any need for clicking hundreds of small checkboxes and all that.
Regards,
Asger
I grant permission to license any and all contributions I've made to LyX
under any open source license.
Regards,
Asger
John Levon wrote:
On Mon, Feb 21, 2005 at 03:33:23PM +0100, Asger Alstrup wrote:
I grant permission to license any and all contributions I've made to LyX
under any open source license.
I think you shouuld be a bit more specific (at least, any current and
future licenses accepted as open source
I grant permission to license any and all contributions I've made to LyX
under any open source license.
Regards,
Asger
John Levon wrote:
On Mon, Feb 21, 2005 at 03:33:23PM +0100, Asger Alstrup wrote:
I grant permission to license any and all contributions I've made to LyX
under any open source license.
I think you shouuld be a bit more specific (at least, "any current and
future licenses accepted as open s
Here are patches representing the above; it would be helpful if these
could be committed if approved. I've built fresh successfully with these
patches applied.
Maybe you could get karma to commit yourself to the
lyx-devel\development\win32 directory?
Regards,
Asger
Here are patches representing the above; it would be helpful if these
could be committed if approved. I've built fresh successfully with these
patches applied.
Maybe you could get karma to commit yourself to the
lyx-devel\development\win32 directory?
Regards,
Asger
Andre Poenitz wrote:
On Mon, Feb 14, 2005 at 05:17:49PM +0100, Jean-Marc Lasgouttes wrote:
If there is interest and if things evolve positively, I may be able to
propose Paris
Both sound nice. [And in case it matters: I am a bit biased towards
France outside Paris...]
Paris sounds great!
Regards,
Angus Leeming wrote:
That will require an MSVC user (Asger) to check his
std::map::const_iterator implementation.
I'm not sure this is what you are looking for, but here is some of the code
for the map::const_iterator in MSVC 7.1:
class const_iterator
: public
Angus Leeming wrote:
I read that as saying that the code in the mail at the start of this thread
is perfectly safe, don't you?
Well, we also have:
templateclass _Traits
class _Tree
{
const_iterator find(const key_type _Keyval) const
{ // find an element in
Angus wrote:
I wonder if the attached patch will make MSVC happy. Could you test it
for me?
The result is below.
Regards,
Asger
Compiling...
ExternalTransforms.C
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239:
nonstandard extension used : 'argument' : conversion from
A fixed VS lyxserver.C is attached. When I find the time, I'll update the
patch.
Regards,
Asger
/**
* \file lyxserver.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Lars Gullik Bjønnes
* \author Jean-Marc Lasgouttes
*
Andre Poenitz wrote:
On Mon, Feb 14, 2005 at 05:17:49PM +0100, Jean-Marc Lasgouttes wrote:
If there is interest and if things evolve positively, I may be able to
propose Paris
Both sound nice. [And in case it matters: I am a bit biased towards
France outside Paris...]
Paris sounds great!
Regards,
Angus Leeming wrote:
That will require an MSVC user (Asger) to check his
std::map::const_iterator implementation.
I'm not sure this is what you are looking for, but here is some of the code
for the map::const_iterator in MSVC 7.1:
class const_iterator
: public
Angus Leeming wrote:
I read that as saying that the code in the mail at the start of this thread
is perfectly safe, don't you?
Well, we also have:
template
class _Tree
{
const_iterator find(const key_type& _Keyval) const
{ // find an element in nonmutable
Angus wrote:
> I wonder if the attached patch will make MSVC happy. Could you test it
> for me?
The result is below.
Regards,
Asger
Compiling...
ExternalTransforms.C
\lyx\lyx-devel\src\insets\ExternalTransforms.C(345) : warning C4239:
nonstandard extension used : 'argument' : conversion from
A fixed VS lyxserver.C is attached. When I find the time, I'll update the
patch.
Regards,
Asger
/**
* \file lyxserver.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Lars Gullik Bjønnes
* \author Jean-Marc Lasgouttes
*
Martin Vermeer wrote:
See attached patch, which has been on the list for a few days.
Technically, you posted the first version of this before the freeze was
announced, so I think it's fair to put it in, also considering the number
of revisions you have made.
Regards,
Asger
Martin Vermeer wrote:
See attached patch, which has been on the list for a few days.
Technically, you posted the first version of this before the freeze was
announced, so I think it's fair to put it in, also considering the number
of revisions you have made.
Regards,
Asger
Lars Gullik Bjønnes wrote:
This patch changes dociterator to not inherit from vector, the vector
is now a private member instead.
I agree, this is a step forward.
Regards,
Asger
Lars Gullik Bjønnes wrote:
This patch changes dociterator to not inherit from vector, the vector
is now a private member instead.
I agree, this is a step forward.
Regards,
Asger
Hi,
I ran BoundsChecker on the LyX executable loading the user guide and then
exiting.
There are many problems in Qt free, but also some in LyX itself.
Qt free has thousands of GDI problems, but since I did not compile Qt with
debugging info, I do not have any call stacks for those.
Regarding
Hi,
I ran BoundsChecker on the LyX executable loading the user guide and then
exiting.
There are many problems in Qt free, but also some in LyX itself.
Qt free has thousands of GDI problems, but since I did not compile Qt with
debugging info, I do not have any call stacks for those.
Regarding
Andreas Vox wrote:
MacAqua crashes without user intervention when I open a file
with math previews. Appearently BufferView::pimpl::update()
calls itself indirectly between startUpdating() and doneUpdating().
Which propagates the imageReady()-events to RenderPreview
which in turn calls
Andreas Vox wrote:
MacAqua crashes without user intervention when I open a file
with math previews. Appearently BufferView::pimpl::update()
calls itself indirectly between startUpdating() and doneUpdating().
Which propagates the imageReady()-events to RenderPreview
which in turn calls
Andre Poenitz wrote:
I the long run I think the coord cache should really be cache. It isn't
right now as we sometimes depend on certain values being present.
I have added some logic so it is easier to detect such errors. I see that
during update, we rely on some coordinates to be there, when
Andre Poenitz wrote:
I the long run I think the coord cache should really be cache. It isn't
right now as we sometimes depend on certain values being present.
I have added some logic so it is easier to detect such errors. I see that
during update, we rely on some coordinates to be there, when
dear sir,
what must I do that upgrade my LyX 1.0.3 to LyX 1.1.5Pre1?
FreeBSD 3.3 Stable
I've unpacked and begun "make install",it was writenn "don't how make"
I 've begun "./configure",I've got next
that libXpm and libxforms(libforms) is not on this operating system.
I check and find taht
dear sir,
what must I do that upgrade my LyX 1.0.3 to LyX 1.1.5Pre1?
FreeBSD 3.3 Stable
I've unpacked and begun "make install",it was writenn "don't how make"
I 've begun "./configure",I've got next
that libXpm and libxforms(libforms) is not on this operating system.
I check and find taht
Hi,
My attention was brought to the fact that the README in 1.1.4 is
out-of-date. It says that even version numbers are stable, and odd
numbers are development versions.
That causes some confusing, so maybe somebody will mend that when they
do a maintaince commit anyway.
Greets,
Asger
Hi,
My attention was brought to the fact that the README in 1.1.4 is
out-of-date. It says that even version numbers are stable, and odd
numbers are development versions.
That causes some confusing, so maybe somebody will mend that when they
do a maintaince commit anyway.
Greets,
Asger
hey,
somebody told you, that the links to the 1.1.4-patches on the
lyx-homepage are wrong??
they are pointing to .../pub/lyx/devel/..., but i found the patches on
.../pub/lyx/stable/...
just an info
greetings
Jörg
hey,
somebody told you, that the links to the 1.1.4-patches on the
lyx-homepage are wrong??
they are pointing to .../pub/lyx/devel/..., but i found the patches on
.../pub/lyx/stable/...
just an info
greetings
Jörg
hello,
I' m an italian user of lyx. During lyx 1.1.4 configuration onto
linux Red Hat 6.1 i discovered that may system doesn' t have the
- libforms or libxforms
- forms.h
If you have understand my problem please send me the complete web
address where I can take them from...
In the Install
hello,
I' m an italian user of lyx. During lyx 1.1.4 configuration onto
linux Red Hat 6.1 i discovered that may system doesn' t have the
- libforms or libxforms
- forms.h
If you have understand my problem please send me the complete web
address where I can take them from...
In the Install
Hi,
I used LyX on RedHat without problems, but on Debian it works as well, but can't use
Latex.
It says while compiling that latex was found (it is there) but it is not usable.
Do you know that as common problem ?
Every thing is installed fine regarding my Debian system.
Marko
Hi,
I used LyX on RedHat without problems, but on Debian it works as well, but can't use
Latex.
It says while compiling that latex was found (it is there) but it is not usable.
Do you know that as common problem ?
Every thing is installed fine regarding my Debian system.
Marko
Original Message
Subject: LyX customisation
Date: Tue, 16 Nov 1999 14:09:31 +0200
From: Akos Maroy [EMAIL PROTECTED]
Organization: Innovative Ideas Oy
To: [EMAIL PROTECTED]
Hi,
I'm using LyX for a variaty of purposes. So far, the document types
included have been enough for
Original Message
Subject: LyX customisation
Date: Tue, 16 Nov 1999 14:09:31 +0200
From: Akos Maroy <[EMAIL PROTECTED]>
Organization: Innovative Ideas Oy
To: [EMAIL PROTECTED]
Hi,
I'm using LyX for a variaty of purposes. So far, the document types
included have been enough
Dear Sir , I was trying to compile the lyx from sources; downloading the
xforms, too, from the official site. Here there are two .tar files for
the 0.88 version, one for the libc, and the other for the libc2,
libraries. So, in a linux/debian/slink, and with the first xforms
version the
Dear Sir , I was trying to compile the lyx from sources; downloading the
xforms, too, from the official site. Here there are two .tar files for
the 0.88 version, one for the libc, and the other for the libc2,
libraries. So, in a linux/debian/slink, and with the first xforms
version the
Dear Sir/Madam
Is it possible to have fanyboxes in LyX? Like what one can get with the
style file fancybox.sty? Actually I tried, and got it as long as there
is no power or fraction inside the box, but as soon as one of them is
included, it doesn't work.
Sincerely,
Amir M. Abolghasem
Dear Sir/Madam
Is it possible to have fanyboxes in LyX? Like what one can get with the
style file fancybox.sty? Actually I tried, and got it as long as there
is no power or fraction inside the box, but as soon as one of them is
included, it doesn't work.
Sincerely,
Amir M. Abolghasem
I checked out the latest cvs version.
After a cd config the readme tells me not to try
to run it manually, though the makefile it
talks about is not distributed via cvs.
In the INSTALL file, it tells to run the "autogen.sh" script when you
use the lyx-devel cvs checkout.
In order for this
> I checked out the latest cvs version.
> After a cd config the readme tells me not to try
> to run it manually, though the makefile it
> talks about is not distributed via cvs.
In the INSTALL file, it tells to run the "autogen.sh" script when you
use the lyx-devel cvs checkout.
In order for
All good reasons but make sure you give consideration to _why_ you
need to identify insets. And then think long and hard about what
happens when you add a new inset. How will that affect the code? If
you find you are using dynamic_cast as a sort of switch statement or
if..else if..else
> All good reasons but make sure you give consideration to _why_ you
> need to identify insets. And then think long and hard about what
> happens when you add a new inset. How will that affect the code? If
> you find you are using dynamic_cast<> as a sort of switch statement or
> if..else
mathed's lexer has some really stupid hacks in it. Following TeX on what is a
macro makes the code *much* simpler and would eliminate even more if I could
rebuild math_hash.C (the CVS sources seem to lack to input to gperf). All the
change required is to put the first character after the \
I am working on a LyX client, and I have suggested a small change in the
LyX server in order to make client implementation easier.
If you think it's worth it, I will submit the following to this list:
[Lots of great stuff]
Of course it is worth it! The earlier you send this, the better
> mathed's lexer has some really stupid hacks in it. Following TeX on what is a
> macro makes the code *much* simpler and would eliminate even more if I could
> rebuild math_hash.C (the CVS sources seem to lack to input to gperf). All the
> change required is to put the first character after
> I am working on a LyX client, and I have suggested a small change in the
> LyX server in order to make client implementation easier.
> If you think it's worth it, I will submit the following to this list:
[Lots of great stuff]
Of course it is worth it! The earlier you send this, the better
When you say "We..." are you talking to the lyx-devel team or are you
including me in that pronoun?
I'm talking everybody. If you are ready to audit LyX, go ahead and tell us the
result.
If not, maybe one of the team will do it at some point. It will take a few
hours, and we have more than
> When you say "We..." are you talking to the lyx-devel team or are you
> including me in that pronoun?
I'm talking everybody. If you are ready to audit LyX, go ahead and tell us the
result.
If not, maybe one of the team will do it at some point. It will take a few
hours, and we have more
Only any it inherits from the underlying OS :)
In theory, LyX could implement Y2K problems of it's own. That's not hard to do
;-)
We should do an audit on all date/time handling in the source. It's a small
job to do, because LyX does not use dates for much. I think the only potential
places
Jochen "../src/lyx_main.C", line 148: Warning (Anachronism): Formal
Jochen argument 2 of type extern "C" void(*)(int) in call to
Jochen signal(int, extern "C" void(*)(int)) is being passed
Jochen void(*)(int). [...] "lyxvc.C", line 337: Warning
Jochen (Anachronism): Formal argument 2 of
> Only any it inherits from the underlying OS :)
In theory, LyX could implement Y2K problems of it's own. That's not hard to do
;-)
We should do an audit on all date/time handling in the source. It's a small
job to do, because LyX does not use dates for much. I think the only potential
places
> Jochen> "../src/lyx_main.C", line 148: Warning (Anachronism): Formal
> Jochen> argument 2 of type extern "C" void(*)(int) in call to
> Jochen> signal(int, extern "C" void(*)(int)) is being passed
> Jochen> void(*)(int). [...] "lyxvc.C", line 337: Warning
> Jochen> (Anachronism): Formal
On the other hand, the LString class could try to test when this count
becomes too large and create a new string instance.
Fixing the bug will add a little run-time overhead, but string assignment will
still be constant time, so I think it's safe to fix this. I don't have time
these days.
For
On a 640x480 pixel display running at a virtual size 1024x900, the lyx
screen is too large, so the right margin is not visible. I can resize
the screen, losing a few buttons after start-up, but can't find a way to
get it to start up at that size. No help from INSTALL or Customization,
Could this be of some help for the encoding business? In particular,
reocde can emit header files which may be useful.
Yes, this looks good. I'll look into it when I get the time.
Greets,
Asger
> On the other hand, the LString class could try to test when this count
> becomes too large and create a new string instance.
Fixing the bug will add a little run-time overhead, but string assignment will
still be constant time, so I think it's safe to fix this. I don't have time
these days.
> On a 640x480 pixel display running at a virtual size 1024x900, the lyx
> screen is too large, so the right margin is not visible. I can resize
> the screen, losing a few buttons after start-up, but can't find a way to
> get it to start up at that size. No help from INSTALL or Customization,
>
> Could this be of some help for the encoding business? In particular,
> reocde can emit header files which may be useful.
Yes, this looks good. I'll look into it when I get the time.
Greets,
Asger
This would be perfectly ok for me. BTW, since you speak of backward
compatibility, I assume that people have written other lyx clients (apart
from servermonitor.c in the lyx sources). I would like very much to see
the code of some of them so I can improve my code, e.g. when it comes to
error
What I gathered upon first reading of the Lyx Server chapter in the
customization docs was indeed that a message was always issued to notify
clients. From that document:
"The answer from LyX will arrive in the output pipe and be
bla bla safe change bla bla... how many times have we said that made
the fix and then we discovers bugs because of it?
Many times.
Also, many times, good things have come. We make mistakes from time to time.
But that should not stop us from making changes, IMO. If we are too afraid to
We should be very restrictive on what we call a bug at this point, the
'\n' that Jean-Marc added is obvious, changing _any_ part of the
protocol is not.
Well, I consider the change a bug-fix. The protocol is after all broken, and
should be fixed.
Also, it is a safe change. The two main
> This same message greets me when I say "lyx -Mono"
The Mono switch is not of any use here. The switch is -depth or -visual,
AFAIR.
Or, as I wrote, try the "vncserver -depth 16" trick.
Greets,
Asger
> This would be perfectly ok for me. BTW, since you speak of backward
> compatibility, I assume that people have written other lyx clients (apart
> from servermonitor.c in the lyx sources). I would like very much to see
> the code of some of them so I can improve my code, e.g. when it comes to
>
> What I gathered upon first reading of the Lyx Server chapter in the
> customization docs was indeed that a message was always issued to notify
> clients. From that document:
>
>
> "The answer from LyX will arrive in the output pipe
> bla bla safe change bla bla... how many times have we said that made
> the fix and then we discovers bugs because of it?
Many times.
Also, many times, good things have come. We make mistakes from time to time.
But that should not stop us from making changes, IMO. If we are too afraid to
> We should be very restrictive on what we call a bug at this point, the
> '\n' that Jean-Marc added is obvious, changing _any_ part of the
> protocol is not.
Well, I consider the change a bug-fix. The protocol is after all broken, and
should be fixed.
Also, it is a safe change. The two main
Concerning the thought part below, I just reproduced it so that others
can comment on it. Personnally, I agree that some message should be
returned on success, but there may be some applications which rely on
the fact that nothing is returned.
So, fellow developpers, any idea?
In order to
I think we should not keep backwards compatibility for the lyxserver.
We need to think out a decent protocol with commands _and_ responses.
Also we should switch to using sockets instead of namedpipes.
Agreed, but only for 1.1.x. And therefore, for 1.0.x, I think we should just
do a hack to
Hi,is it possible to create plugins for LyX?
Unfortunately, there is no fixed architechture for this kind of thing, yet.
I was thinking along the lines of adding a plugin that interfaces
with the CAS I am currently making (http://www.xs4all.nl/~apinkus/yacas.html)
and can then be loaded
LyX uses another paradighm I call "MF-OD-OB"
it means: "More File for One Document in One Buffer"
For example Mico$oft Xord and others traditional WYSIWYG editors
use "One File for One Document in One Buffer"
Actually, it's possible to do more file for one document with Microsoft Word as
> Concerning the thought part below, I just reproduced it so that others
> can comment on it. Personnally, I agree that some message should be
> returned on success, but there may be some applications which rely on
> the fact that nothing is returned.
>
> So, fellow developpers, any idea?
In
> I think we should not keep backwards compatibility for the lyxserver.
> We need to think out a decent protocol with commands _and_ responses.
> Also we should switch to using sockets instead of namedpipes.
Agreed, but only for 1.1.x. And therefore, for 1.0.x, I think we should just
do a hack
> Hi,is it possible to create plugins for LyX?
Unfortunately, there is no fixed architechture for this kind of thing, yet.
> I was thinking along the lines of adding a plugin that interfaces
> with the CAS I am currently making (http://www.xs4all.nl/~apinkus/yacas.html)
> and can then be
> LyX uses another paradighm I call "MF-OD-OB"
> it means: "More File for One Document in One Buffer"
> For example Mico$oft Xord and others traditional WYSIWYG editors
> use "One File for One Document in One Buffer"
Actually, it's possible to do more file for one document with Microsoft Word as
karger You provide a link to the Japanese patch at
http://cgi.din.or.jp/~kawakami/.
I think good thing My web site is mentioned on the LyX home page.
To use Japanese on LyX, I do not use XFontStruct but XFontSet.
I change char *text into wchar_t on class LyXParagraph, and so on.
I added
> karger> You provide a link to the Japanese patch at
http://cgi.din.or.jp/~kawakami/.
>
> I think good thing My web site is mentioned on the LyX home page.
> To use Japanese on LyX, I do not use XFontStruct but XFontSet.
> I change char *text into wchar_t on class LyXParagraph, and so on.
I
Hi!
Kernel 0.6 is attached. The segfault has been fixed properly, and insert and
erase is done. I only need to implement "clone" and test/debug everything in
order to reach milestone 1: Design, implementation and documentation of the
data structure layer.
This will surely be done before ~M.
Hi!
Kernel 0.6 is attached. The segfault has been fixed properly, and insert and
erase is done. I only need to implement "clone" and test/debug everything in
order to reach milestone 1: Design, implementation and documentation of the
data structure layer.
This will surely be done before ~M.
[Requests for RTL text]
Hey, if I request it too, does that help? I didn't think so. I suspect that
what you mean is "requests for this from people who will actually work on
the coding have been very few, so it won't get done until someone has lots
of free time."
It does help if more people
[Requests for RTL text]
> Hey, if I request it too, does that help? I didn't think so. I suspect that
> what you mean is "requests for this from people who will actually work on
> the coding have been very few, so it won't get done until someone has lots
> of free time."
It does help if more
Hi!
The editor in Mozilla is getting math capabilities. Check out:
http://www.mozilla.org/projects/mathml/
Greets,
Asger
The Third International LyX Developer Meeting in Italy 1999!
So this is the invitation let me know!!!
I'll be there!
Greets,
Asger
Hi!
The editor in Mozilla is getting math capabilities. Check out:
http://www.mozilla.org/projects/mathml/
Greets,
Asger
101 - 200 of 392 matches
Mail list logo
