> > I thought kazarledbA would be unique enough. :-)
> >
> I think that 'foo.lyx.up' was enough actually...
Actually, this name can not be random, because it is used to save
files in the zip file. When a zip file is read, they need to be
recognized as "..".
I am using "LyX.Embed.Dir.Up". If some
Andre Poenitz wrote:
On Fri, Jan 04, 2008 at 09:34:37PM +0100, Abdelrazak Younes wrote:
Bo Peng wrote:
Where is this function?
FileName::tempName()
tempName actually creates a temp file.
Which you can remove afterwards... that's how we create the temp direct
On Fri, Jan 04, 2008 at 09:34:37PM +0100, Abdelrazak Younes wrote:
> Bo Peng wrote:
Where is this function?
>>> FileName::tempName()
>> tempName actually creates a temp file.
>
> Which you can remove afterwards... that's how we create the temp directory.
> Maybe we should just delete the file
Bo Peng wrote:
Where is this function?
FileName::tempName()
tempName actually creates a temp file.
Which you can remove afterwards... that's how we create the temp
directory. Maybe we should just delete the file unconditionally in
FileName::tempName().
I guess I will just use some
absur
> > Where is this function?
> FileName::tempName()
tempName actually creates a temp file. I guess I will just use some
absurd name for now.
Bo
Bo Peng wrote:
A unique identifier can be used instead, we have a method for that.
Where is this function?
FileName::tempName()
I thought kazarledbA would be unique enough. :-)
I think that 'foo.lyx.up' was enough actually...
Abdel.
> A unique identifier can be used instead, we have a method for that.
Where is this function? I thought kazarledbA would be unique enough. :-)
Bo
Bo Peng wrote:
No, 'file.lyx' should of course stay in 'temp/file.lyx'. When you insert
a figure ../figure.png the layout needs not to be changed but a new
subdirectory 'file.lyx.up' needs to be created to represent '..'
Ohmm, now I see, a "down is up" trick. :-)
Alleluia brother! :-)
> No I am talking about the directory structure inside the zip archive
> and/or the temp directory. If you open an embedded file, LyX would
> uncompress it in the temp directory using the above structure. If you
> save the opened file in non-embedded format, then bar1.fig will be moved
> to the rec
Bo Peng wrote:
tempXXX/foo.lyx
tempXXX/foo.lyx.up/fig/bar1.fig
tempXXX/foo.lyx.up/foo.lyx.up/png/bar2.png
'up' can be replaced by a unique identifier. What'd you think?
You have a document in temp/foo.lyx and you insert a figure
../../figure.png, and foo.lyx needs to related itself?
No I am
> You have a document in temp/foo.lyx and you insert a figure
> ../../figure.png, and foo.lyx needs to related itself?
I meant relocate.
Bo
>
> tempXXX/foo.lyx
> tempXXX/foo.lyx.up/fig/bar1.fig
> tempXXX/foo.lyx.up/foo.lyx.up/png/bar2.png
>
> 'up' can be replaced by a unique identifier. What'd you think?
You have a document in temp/foo.lyx and you insert a figure
../../figure.png, and foo.lyx needs to related itself?
Bo
Andre Poenitz wrote:
On Fri, Jan 04, 2008 at 07:28:10PM +0100, Abdelrazak Younes wrote:
Bo Peng wrote:
Dear all,
Embedding of files not in or under current document path leads to a
lot of hard-to-solve problems such as filename conflict, unpacking to
paths under different OS (save in c:\file, r
> Even that would not be nice. Think of
>
> ./text/*.lyx
> ./images/*.fig
> ./images/*.png
I know, and some of my documents have similar disk layout to what you
described. It is just that there is no good solution to the problems I
encountered.
Bo
On Fri, Jan 04, 2008 at 07:28:10PM +0100, Abdelrazak Younes wrote:
> Bo Peng wrote:
>> Dear all,
>> Embedding of files not in or under current document path leads to a
>> lot of hard-to-solve problems such as filename conflict, unpacking to
>> paths under different OS (save in c:\file, restore unde
> This is fine because *.fig is *under* document path
Ohmm, 'under' is not the right word, which is the same as 'in'. By
'under', I meant 'deeper depth than the current document path'.
Bo
> What if I have this directory structure:
>
> ./*.lyx
> ./img/*.fig
> ./img/*.png
This is fine because *.fig is *under* document path. ../image/*.fig
will currently not be allowed. The problem is that I can not use this
relative path under temp_path, and problems will arise if I alias the
files.
Bo Peng wrote:
Dear all,
Embedding of files not in or under current document path leads to a
lot of hard-to-solve problems such as filename conflict, unpacking to
paths under different OS (save in c:\file, restore under unix). If
there is no objection, I will disallow embedding of such files. On
On Sat, Jan 05, 2008 at 10:59:59AM +1800, Bo Peng wrote:
> Dear all,
>
> Embedding of files not in or under current document path leads to a
> lot of hard-to-solve problems such as filename conflict, unpacking to
> paths under different OS (save in c:\file, restore under unix). If
> there is no ob
Jean-Marc Lasgouttes wrote:
> Would this patch be OK?
Looks sensible.
Jürgen
Jean-Marc Lasgouttes wrote:
> Here it is. OK?
OK.
Jürgen
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Juergen, do you want this in 1.5.4svn? This is an older request from
>> Darren.
>
> Yes.
>
>> It might be a good idea to rename 'Toggle numbering' to something that
>> does not contain 'toggle'. Maybe
>> [ ] Number for
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> After that, I'll propose a patch for silencing the message itself
> (not the real fix, but a reasonable workaround).
Here it is. OK?
JMarc
svndiff src/MenuBackend.cpp
Index: src/MenuBackend.cpp
=
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Juergen, I guess it is OK in 1.5? After that, I'll propose a patch for
>> silencing the message itself (not the real fix, but a reasonable
>> workaround).
>
> Yes, certainly.
Done.
JMarc
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> And with this additional patch, there is no need to change the version
>> anymore. Juergen, OK?
>
> Yes.
Done.
JMarc
Dear all,
Embedding of files not in or under current document path leads to a
lot of hard-to-solve problems such as filename conflict, unpacking to
paths under different OS (save in c:\file, restore under unix). If
there is no objection, I will disallow embedding of such files. One
direct advantag
Jean-Marc Lasgouttes wrote:
> Juergen, I guess it is OK in 1.5? After that, I'll propose a patch for
> silencing the message itself (not the real fix, but a reasonable
> workaround).
Yes, certainly.
Jürgen
Jean-Marc Lasgouttes wrote:
> Did you regenerate lyx.pot?
No, this I forgot.
Jürgen
[EMAIL PROTECTED] writes:
> Author: lasgouttes
> Date: Fri Jan 4 17:54:56 2008
> New Revision: 22365
>
> URL: http://www.lyx.org/trac/changeset/22365
> Log:
> remove extra menu expansion which causes multiple warnings about shortcuts
I finally took a look at these multiple
Menu warning: menu en
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> And with this additional patch, there is no need to change the version
>> anymore.
>
> BTW do you generate the Web page from trunk or branch (I think branch is more
> sensible)? I wondered because the statistics diffe
Jean-Marc Lasgouttes wrote:
> And with this additional patch, there is no need to change the version
> anymore.
BTW do you generate the Web page from trunk or branch (I think branch is more
sensible)? I wondered because the statistics differ between your and my
update.
Jürgen
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Maybe yes but at least that's still a benefit for me if I am to do
> something :-).
I did not say it was a completely bad motivation :)
JMarc
Jean-Marc Lasgouttes wrote:
> And with this additional patch, there is no need to change the version
> anymore. Juergen, OK?
Yes.
Jürgen
Jean-Marc Lasgouttes wrote:
I do not say that expandToc/expandToc2 are a model of good coding. But
they are more complicated, since the number of submenus is decided
dynamically depending on their complexity (i.e. subsections are not in
a submenu if not needed). I am not sure that it is necessary
[EMAIL PROTECTED] writes:
> Author: lasgouttes
> Date: Fri Jan 4 17:17:23 2008
> New Revision: 22363
>
> URL: http://www.lyx.org/trac/changeset/22363
> Log:
> replace postats.sh with postats.py
And with this additional patch, there is no need to change the version
anymore. Juergen, OK?
JMarc
s
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Add this at the top of GuiApplication.cpp and everything should be fine:
#include
This should be done in Branch Juergern.
This include statement is already there in branch.
Weird...
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>> Why should it? I was the only user, after all :)
>
> remember the bus.
No I do not need the bus today, I have my car ;)
JMarc
PS: not documented, but not really a secret:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg126758.html
Jean-Marc Lasgouttes wrote:
> Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> > Jean-Marc Lasgouttes wrote:
> >> Go in build/po and do "make i18n.inc". Then you just have to move
> >> i18n.inc to the right place.
> >
> > Ah, that's much better. This isn't documented anywhere, is it?
>
> Why should
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Go in build/po and do "make i18n.inc". Then you just have to move
>> i18n.inc to the right place.
>
> Ah, that's much better. This isn't documented anywhere, is it?
Why should it? I was the only user, after all :)
JM
Jean-Marc Lasgouttes wrote:
> Go in build/po and do "make i18n.inc". Then you just have to move
> i18n.inc to the right place.
Ah, that's much better. This isn't documented anywhere, is it?
> BTW should I replce postats.sh by postats.py now that Jose fixed it?
Yes, please.
Jürgen
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Did you do it by hand?
>
> Yes. I don't know how to do it for all po files at once, so I did
>
> ./postats.sh ru.po > i18n.inc
>
> and pasted the result into the real i18n.inc.
Go in build/po and do "make i18n.inc". T
Jean-Marc Lasgouttes wrote:
> Did you do it by hand?
Yes. I don't know how to do it for all po files at once, so I did
./postats.sh ru.po > i18n.inc
and pasted the result into the real i18n.inc.
Jürgen
[EMAIL PROTECTED] writes:
> Author: spitz
> Date: Fri Jan 4 16:54:08 2008
> New Revision: 22360
>
> URL: http://www.lyx.org/trac/changeset/22360
> Log:
> oops.
Did you do it by hand?
JMarc
Jean-Marc Lasgouttes wrote:
> Actually it was against trunk. I applied the patch to trunk and merged
> the resulting ru.po against 1.5.x' lyx.pot.
Thanks.
Jürgen
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> I just tried to apply it but failed. Andrey, what is the version of
> 1.5.x against which it was done?
Actually it was against trunk. I applied the patch to trunk and merged
the resulting ru.po against 1.5.x' lyx.pot.
JMarc
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Juergen, I got an updated ru.po for trunk and I would like to use it
>> for branch. This means readding ru to LINGUAS (we removed it earlier).
>> OK?
>
> Yes, fine.
Done.
JMarc
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Juergen, do you want this in 1.5.4svn? This is an older request from
>> Darren.
>
> Yes.
I did it.
JMarc
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Andrey V. Panov wrote:
>> I hereby declare that, I grant permission for all my past and future
>> contributions to LyX project
>> under the Gnu General Public Licence version 2 or later.
>>
>> Here is attached a new patch for ru.po.
>
> Many thanks.
Andrey V. Panov wrote:
> I hereby declare that, I grant permission for all my past and future
> contributions to LyX project
> under the Gnu General Public Licence version 2 or later.
>
> Here is attached a new patch for ru.po.
Many thanks.
Jean-Marc, do you intend to commit this, are shall I?
>
Hi all,
I just compiled the latest 1.5 branch on Mandrake 10.1. I only had to
specify the nonstandard qt4 directory as Mandrake 10.1 doesn't ship with
it.
After successfully building and installing, I was greeted with the
following error dialogue when starting LyX:
8<8<8<
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I guess 'not bad' means good here ;-)
Yes.
> Algorithms are algorithms, why do you want to recreate them? FWIW,
> I've created the TocModel class for Navigation purpose and it uses
> approximatively the same algorithm as in expandToc()/expandToc2(
Uwe Stöhr wrote:
Josst, Abdel, could LyX compiled with MSVC 2008 be run on Windows 2000?
(I currently cannot thest this.)
Yes, it should work fine:
http://msdn2.microsoft.com/en-us/library/ms235435.aspx
Joost
Abdelrazak Younes wrote:
> Add this at the top of GuiApplication.cpp and everything should be fine:
>
> #include
>
> This should be done in Branch Juergern.
This include statement is already there in branch.
Jürgen
Jean-Marc Lasgouttes wrote:
> Juergen, do you want this in 1.5.4svn? This is an older request from
> Darren.
Yes.
> It might be a good idea to rename 'Toggle numbering' to something that
> does not contain 'toggle'. Maybe
> [ ] Number formula
> [ ] Number this line
I don't have a strong opinion,
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I thought a bit more about that. Instead of QMenu, I'd generate a list
of Actions instead. A QMenu can be automatically constructed with
that. The idea is that this would get us closer to my idea of "Action
unification" (
Jean-Marc Lasgouttes wrote:
Bennett Helm <[EMAIL PROTECTED]> writes:
And is it there?
Looks so. There are two entries I could find that seem relevant.
Thanks for doing the search. All we can do now is wait, I guess.
It is possible to cancel any key event when a window gets a focus event.
Grósz Dániel wrote:
Hello,
I use LyX 1.5.3 on openSUSE Linux 10.3. Several documents are open. In
a document, I scroll away from the cursor position. If I switch to an
other document (either using tabs or the View menu) and switch back, I
find myself at the cursor. I think this is unexpected beh
Uwe Stöhr wrote:
I've seen that Joost changed the build system to MSVC2008, but wasn't it
a bit too rush?:
I found out that I still have to install the Windows SDK separately
because I use a 64bit version.
More problematic might be that Windows 2000 is no longer supported my
MSVC2008 as I r
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I thought a bit more about that. Instead of QMenu, I'd generate a list
> of Actions instead. A QMenu can be automatically constructed with
> that. The idea is that this would get us closer to my idea of "Action
> unification" (menu and toobar actions
Bennett Helm <[EMAIL PROTECTED]> writes:
>> And is it there?
>
> Looks so. There are two entries I could find that seem relevant.
Thanks for doing the search. All we can do now is wait, I guess.
JMarc
60 matches
Mail list logo
