Abdelrazak Younes wrote:
>> But my understanding is that git is current unix (even linux) only so
>> this feature will only benefit a few users.
>>
> No, I used the msysgit port and it works dwell.
one more question - are you able to run qgit (2.1) on win?
pavel
On Tuesday 13 May 2008 23:30:05 Pavel Sanda wrote:
> Jose, when you wrote this have you actually tried to compile it? i just got
> next report that 1.5.5 fails to compile with --disable-pch
> --without-included-boost on 4.3.
I remember to have tested --disable-pch but I don't remember if it was at
On Sun, May 11, 2008 at 12:11:06PM +0200, Jürgen Spitzmüller wrote:
> Public release of LyX version 1.5.5
>
Congrats, Jürgen!
I have placed a cygwin binary here:
http://www.lyx.org/~forenr/lyx-1.5.5-cygwin.tar.gz
--
Enrico
José Matos wrote:
> On Saturday 29 March 2008 01:54:17 Pavel Sanda wrote:
> > if we just add will it work with 4.3?
>
> Yes. :-)
Jose, when you wrote this have you actually tried to compile it? i just got next
report that 1.5.5 fails to compile with --disable-pch --without-included-boost
on 4
> Well, if that's the idea, then I'm with Edwin (was it?) who proposed just
> using a python script for this kind of purpose.
It was Enrico's idea.
If you have read my response to Enrico's proposal, you should have
known that I would support his proposal, if only my goal is to provide
a way to w
Bo Peng wrote:
"auto-update" would be interesting.
I have heard the 'URL' idea, and now the auto-update idea. I am
interested to know how these can make the bundled mode work better.
Please note that my approach needs no change of how users work with
external files. Also, these will make
Bo Peng wrote:
Well, maybe you're mirroring the original directory structure, in a way
like chroot. But you're not "recreating" it. And I don't see the advantage
of doing that myself.
This is Enrico's idea. The lyx file may be put several levels under
the new directory so that the original
Bo Peng wrote:
I've thought many time about this too. That would be very, very nice.
But my understanding is that git is current unix (even linux) only so
this feature will only benefit a few users.
No, I used the msysgit port and it works dwell.
Abdel.
On Tue, May 13, 2008 at 3:14 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> > visual diff between two versions of the same LyX file. I guess the
> > difficult part is to create this visual diff part.
>
> this is a different story, which has only little to do with RCS.
Indeed, that is another featu
> visual diff between two versions of the same LyX file. I guess the
> difficult part is to create this visual diff part.
this is a different story, which has only little to do with RCS.
pavel
Pavel Sanda wrote:
>
> what do you think about integrating this support to lyx?
>
I think it is a great idea to add a generic RCS framework with a git plugin
for LyX.
I have never used a RCS with LyX because there is no easy way to have a
visual diff between two versions of the same LyX file.
Bo Peng wrote:
> Using an external program is also more flexible.
you will be of course able to use it externaly.
one thing which i have dreamt of - and this wont give you external program - is
to have some kind of gui window or toolbar which only by mouse click show you
the other revision direct
Bo Peng wrote:
> > I've thought many time about this too. That would be very, very nice.
>
> But my understanding is that git is current unix (even linux) only so
> this feature will only benefit a few users.
git is officially supported on cygwin and native install is on its way too
( http://cod
> More on topic, though, I've never used the Version Control options from
> within LyX, nor have I ever really had the urge to; if I want to version
> control a document, I do it externally, and prefer it that way.
This is my feeling about this feature as well. There are so many
version control s
Bo Peng wrote:
I've thought many time about this too. That would be very, very nice.
But my understanding is that git is current unix (even linux) only so
this feature will only benefit a few users.
Bo
There's also mercurial, which I find very very nice, and which is
cross-platform (python
> I'm not able to create a .deb package with checkinstall,
> on Ubuntu Hardy amd64.
>
> Here is the tail of 'make check':
>
> PASS: test_convert
> FAIL: test_filetools
> PASS: test_lstrings
>
> 1 of 3 tests failed
> Please report to lyx-devel@lists.lyx.org
>
Hello
I'm not able to create a .deb package with checkinstall,
on Ubuntu Hardy amd64.
Here is the tail of 'make check':
PASS: test_convert
FAIL: test_filetools
PASS: test_lstrings
1 of 3 tests failed
Please report to lyx-devel@lists.lyx.org
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I found I could create an RCS archive from a file, but could not
check-in changes. Simple as that...
Matt
Pavel Sanda wrote:
|> I have tried to use it in 1.5.2, but found it, apparently, a bit broken.
|
| could you be more verbose which bugs you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OpenAFS is moving to git from CVS--and we have very strong Windows
contingent. The git port is Cygwin based, so there are some
line-termination issues, but they seem to be manageable with
git-provided hooks.
Matt
Bo Peng wrote:
|> I've thought m
> I have tried to use it in 1.5.2, but found it, apparently, a bit broken.
could you be more verbose which bugs you encountered?
pavel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Pavel Sanda wrote:
| hi,
|
| following the last discussions about embedding and lyx usage via RCS
| i would like to ask if there anyone still usgin our integrated RCS in lyx.
| its seems as some archelogical stuff, but maybe i'm wrong.
I have tried
> I've thought many time about this too. That would be very, very nice.
But my understanding is that git is current unix (even linux) only so
this feature will only benefit a few users.
Bo
Pavel Sanda wrote:
hi,
following the last discussions about embedding and lyx usage via RCS
i would like to ask if there anyone still usgin our integrated RCS in lyx.
its seems as some archelogical stuff, but maybe i'm wrong.
i'm playing now with git/qgit and just read our code of lyx VCS and t
Pavel Sanda wrote:
Abdelrazak Younes wrote:
That would give us an indication at least. Plus the situation is exactly
the same for Win and Mac corporate users who don't install LyX themselves.
no, its not symmetrical :)
- these installs in organizations are the same for all archs (eg m
Bo Peng wrote:
> > what do you think about integrating this support to lyx?
>
> I do not use the rcs feature of lyx at all, but I am using git for
> local embedding development. Uwe has suggested me to open a branch for
> this purpose but subversion branch is a pain to work with.
nono, thats com
> what do you think about integrating this support to lyx?
I do not use the rcs feature of lyx at all, but I am using git for
local embedding development. Uwe has suggested me to open a branch for
this purpose but subversion branch is a pain to work with.
Cheers,
Bo
hi,
following the last discussions about embedding and lyx usage via RCS
i would like to ask if there anyone still usgin our integrated RCS in lyx.
its seems as some archelogical stuff, but maybe i'm wrong.
i'm playing now with git/qgit and just read our code of lyx VCS and think
it wouldn't be s
On Tue, May 13, 2008 at 12:23 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> > "auto-update" would be interesting.
By the way, the 'auto-update' idea was mine. :-) I proposed it before
and was convinced by Jose (and JMarc?) that it is too confusing to
users.
Bo
> Well, maybe you're mirroring the original directory structure, in a way
> like chroot. But you're not "recreating" it. And I don't see the advantage
> of doing that myself.
This is Enrico's idea. The lyx file may be put several levels under
the new directory so that the original '../../figures/
> "auto-update" would be interesting.
>
I have heard the 'URL' idea, and now the auto-update idea. I am
interested to know how these can make the bundled mode work better.
Please note that my approach needs no change of how users work with
external files. Also, these will make the 'simple' idea o
Abdelrazak Younes wrote:
> That would give us an indication at least. Plus the situation is exactly
> the same for Win and Mac corporate users who don't install LyX themselves.
no, its not symmetrical :)
- these installs in organizations are the same for all archs (eg my university
have it his
Richard Heck wrote:
Abdelrazak Younes wrote:
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents
end up
being in base64, all the interested of svn
Abdelrazak Younes wrote:
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
> Well, then you don't have "full reversibility". OK.
Depending on how you define it. As I have said, my approach does not
have the reversibility problem because there is no bundled mode. If
you really want to 'bundle all' and 'unbundled all', a feature I might
not even offer, my approach allows
Bo Peng wrote:
My solution achieves full reversibility without security problem.
This is impossible. If LyX can write arbitrary embedded files to arbitrary
locations in the file system, then that is a massive security problem. If
that isn't clear, then, well, that's unfortunate, but
Pavel Sanda wrote:
Abdelrazak Younes wrote:
But not on Unix. And having a long tradition on Unix, I'm not sure who and
where "most users" of LyX are.
Here is an interesting subject for a poll! :-)
considering the fact that linux users don't need to see lyx homepage ever to g
> > My solution achieves full reversibility without security problem.
> This is impossible. If LyX can write arbitrary embedded files to arbitrary
> locations in the file system, then that is a massive security problem. If
> that isn't clear, then, well, that's unfortunate, but I have already was
Bo Peng wrote:
"File->Export->LyX with extracted files". A Python script will be
called to extract a .lyx file to a new directory (e.g.
filename.extracted under the document directory), and arrange files in
their original layout.
By "full reversibility", I take it you mean that you can
Bo Peng wrote:
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
This is non issue IMHO. I really don't think users that use svn should be
interested in this bundle/embedded business. It's rather the
Bo Peng wrote:
My solution achieves full reversibility without security problem.
This is impossible. If LyX can write arbitrary embedded files to
arbitrary locations in the file system, then that is a massive security
problem. If that isn't clear, then, well, that's unfortunate, but I have
> Bo's embedding proposal:
> 1) This is about embedding files directly in the '.lyx' file encoded with
> base64.
> 2) Each and every external file can be embedded individually.
Right. Note that 3, 4 and 5 are not part of the proposal at this
stage. 1 and 2 are enough to achieve my goal, and 3,
> > Base64 may seem nice because it is text, but if child documents end up
> > being in base64, all the interested of svn is lost, for example.
> >
> >
> This is non issue IMHO. I really don't think users that use svn should be
> interested in this bundle/embedded business. It's rather the opposit
Konrad Hofbauer wrote:
Would it not make more sense to announce new stable/rc releases to the
users and announcement lists AFTER the major binary installers are
available (and the website updated)?
I think it would be a good idea to announce the release on the devel
list first and to wait abo
Jean-Marc Lasgouttes wrote:
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
This is non issue IMHO. I really don't think users that use svn should
be interested in this bundle/embedded business. It's rathe
Abdelrazak Younes wrote:
>> But not on Unix. And having a long tradition on Unix, I'm not sure who and
>> where "most users" of LyX are.
>>
> Here is an interesting subject for a poll! :-)
considering the fact that linux users don't need to see lyx homepage ever to get
lyx inside their distro
Bo Peng wrote:
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I know which one is easier to tinker with.
Base64 may seem nice because it is text, but if child documents end up
being in base64, all the interested of svn is lost, for example.
We should choose a
Jürgen Spitzmüller wrote:
Konrad Hofbauer wrote:
Understood. Still, the source code release as is is of little use for most
_users_ (at least on Windows & Mac).
But not on Unix. And having a long tradition on Unix, I'm not sure who and
where "most users" of LyX are.
Here is an int
Jürgen Spitzmüller schrieb:
Herbert Voss wrote:
And TLC2 doesn't say that it should be used only with \DeclareOption.
It should be used in any case, where a document class and a user may
load the same package with different options.
Both clsguide and TLC2 are at least ambigouous in their state
Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
>
> > fyi this is the working code, when status check is put inside
> > LyXFunc::getStatus in LyXFunc.cpp
> >
> > when i put equivalent code inside Text::getStatus in text3.cpp
> > then flag settings are ignored.
>
> Could you
Herbert Voss wrote:
> And TLC2 doesn't say that it should be used only with \DeclareOption.
> It should be used in any case, where a document class and a user may
> load the same package with different options.
Both clsguide and TLC2 are at least ambigouous in their statements:
http://tex.loria.fr
> If I think of openoffice zip file versus ms office
> filesystem-in-a-file, I know which one is easier to tinker with.
> Base64 may seem nice because it is text, but if child documents end up
> being in base64, all the interested of svn is lost, for example.
We should choose a file format tha
Konrad Hofbauer wrote:
> Understood. Still, the source code release as is is of little use for most
> _users_ (at least on Windows & Mac).
But not on Unix. And having a long tradition on Unix, I'm not sure who and
where "most users" of LyX are.
> Should the binaries really just be an "addition"
Jean-Marc Lasgouttes wrote:
> [EMAIL PROTECTED] writes:
>
> > Author: sanda
> > Date: Tue May 13 16:26:47 2008
> > New Revision: 24751
> >
> > URL: http://www.lyx.org/trac/changeset/24751
> > Log:
> > getStatus for LFUN_SET_GRAPHICS_GROUP so context menu looks nicer.
>
> What is a graphics group?
Bo Peng wrote:
> On the other hand, the file format in my proposal is still plain text.
> For many other operations such as search and replace, you do not have
> to unzip. I consider this as an advantage.
You have got a point. But the mix of text and base64 which is what is done
in rtf, if I'm ri
[EMAIL PROTECTED] writes:
> Author: sanda
> Date: Tue May 13 16:26:47 2008
> New Revision: 24751
>
> URL: http://www.lyx.org/trac/changeset/24751
> Log:
> getStatus for LFUN_SET_GRAPHICS_GROUP so context menu looks nicer.
What is a graphics group? How is this supposed to work?
JMarc
Konrad Hofbauer wrote:
Would it not make more sense to announce new stable/rc releases to the
users and announcement lists AFTER the major binary installers are
available (and the website updated)?
A fair proportion of the LyX users don't use Windows and are
sufficiently technically orientate
Sven Hoexter wrote:
> Hi Julien, hi Cengiz,
> ok you might wonder why I'm mailing you so here's the story:
> Cengiz Gunay modified your bash_completion file for inkscape to work with
> LyX and submitted it for inclusion in the Debian package.[1]
>
> I picked it up and added it to the Debian LyX pa
Pavel Sanda <[EMAIL PROTECTED]> writes:
> fyi this is the working code, when status check is put inside
> LyXFunc::getStatus in LyXFunc.cpp
>
> when i put equivalent code inside Text::getStatus in text3.cpp
> then flag settings are ignored.
Could you show us this code? The lfun is already handled
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Sure, 'may become unpleasant' when you try to handle .lyx file without
> lyx, but the problems I have mentioned may make everyday lyx usage
> unpleasant. Which one is more important?
If I think of openoffice zip file versus ms office
filesystem-in-a-file, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
It does sound like an advantage. It seems more in accord with the way
Lyx has traditionally worked, to me.
Bo Peng wrote:
| On the other hand, the file format in my proposal is still plain text.
| For many other operations such as search and repla
> I like Richard's solution better. Having a zip based solution means that you
> can 'unbundle' from the command line even without LyX, the base64 solution
> is more complex.
On the other hand, the file format in my proposal is still plain text.
For many other operations such as search and repl
On Mon, 12 May 2008, Jürgen Spitzmüller wrote:
The drawback is that the old, still accessible site at
http://www.lyx.org/news.php
I've added some manual redirections for these pages:
donations.php, feedback.php, mailing.php and news.php.
The redirections are simple HTML redirect. We can add
> Yes, a file that can be read/handled without LyX is more powerful. We
> could try to use MIME format for LyX files, but it may become
> unpleasant to handle.
Sure, 'may become unpleasant' when you try to handle .lyx file without
lyx, but the problems I have mentioned may make everyday lyx usa
> Many users already maintain their own directory underneath the document
> directory. They can of course continue to do so.
They cannot. Once the document is turned to the 'bundled mode', users
have to depend on 'update from external' to make their changes to
these files available to lyx. What m
> Yes, I think so.
done
p
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> For example http://www.lyx.org/Download suggests that they are released from
>> you, "the LyX project", and not from some dubious third party.
>
> looking at the download page i see somebody changed the order. originally
> the source code was the first se
Konrad Hofbauer <[EMAIL PROTECTED]> writes:
> Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>> I don't think so. This is an open source project. We, as the LyX project,
>> release the source code.
>
> Understood. Still, the source code release as is is of little use for most
> _users_ (at least
Konrad Hofbauer wrote:
> Understood. Still, the source code release as is is of little use for most
> _users_ (at least on Windows & Mac).
note that this is not necessary situtation on linux (and i'm still talking
about the users).
> > The binaries are additions contributed by some team
> > mem
Jürgen Spitzmüller schrieb:
Uwe Stöhr wrote:
\PassOptionsToPackage{}{
Thanks for thehint. I implemented this now using this:
http://www.lyx.org/trac/changeset/24746
Are you sure this works?
- PassOptionsToPackage must be called before the package is loaded.
- According to clsguide and TLC2,
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> I don't think so. This is an open source project. We, as the LyX project,
> release the source code.
Understood. Still, the source code release as is is of little use for most
_users_ (at least on Windows & Mac).
> The binaries are additions con
>> http://www.lyx.org/trac/changeset/24746
>
> Are you sure this works?
Yes, I tested this.
> - PassOptionsToPackage must be called before the package is loaded.
I was not sure about the loading order and both orders do work. I'll change
this as you suggested.
> - According to clsguide and TL
Konrad Hofbauer wrote:
> Would it not make more sense to announce new stable/rc releases to the
> users and announcement lists AFTER the major binary installers are
> available (and the website updated)?
I don't think so. This is an open source project. We, as the LyX project,
release the source
Bo Peng wrote:
Working like OOo does not mean it is a good way for latex because we
routinely work with external files. If you do not want users to mess
around the filename.lyxdir directory, I would suggest that you always
put this directory under the temporary directory. If you do allow
users to
Dear all,
I would want to suggest a (what I would think) small improvement to the
release procedure.
Would it not make more sense to announce new stable/rc releases to the
users and announcement lists AFTER the major binary installers are
available (and the website updated)?
I think this w
Jean-Marc Lasgouttes schrieb:
caption is one of the most popular LaTeX-packages, so we can expect
that many users load it in the preamble.
Where do you get such information? How do we measure 'popular'? I
would be surprised to learn that people are more excited about
customizing captions than
"Bo Peng" <[EMAIL PROTECTED]> writes:
> and no response from Edwin and JMarc.
Yes, I intend to remain out of this discussion, which looks like it is
going to be tough (again!). That said, I planned to answer your
message ("nothing to declare") and then forgot. Sorry.
JMarc
Charles de Miramon <[EMAIL PROTECTED]> writes:
> I like Richard's solution better. Having a zip based solution means that you
> can 'unbundle' from the command line even without LyX, the base64 solution
> is more complex.
Yes, a file that can be read/handled without LyX is more powerful. We
could
On Tuesday 13 May 2008 10:05:08 Jean-Marc Lasgouttes wrote:
> >> Doxy for word-level cursor movement lfuns.
> >
> > cool :)
>
> BTW, pavel, did I congratulate you already for your persistence at
> writing these documentation strings?
+1 :-)
> JMarc
--
José Abílio
"Rex C. Eastbourne" <[EMAIL PROTECTED]> writes:
> Here's the new version of the home page picture, with a "download"
> button added in. As per Andre's comment, I had the pixelation fixed.
>
> http://www.lyx.org/HomeNewGraphic
I'd prefer a more sexy download button that stands out better. I
though
>> Doxy for word-level cursor movement lfuns.
>
> cool :)
BTW, pavel, did I congratulate you already for your persistence at
writing these documentation strings?
JMarc
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Pavel Sanda wrote:
>> btw this is the second bug report i'm responding today about 1.5.5, Juergen
>> can you hurry up?
>
> I will release when I am ready. I will not hurry up.
Very wise man.
JMarc
I like Richard's solution better. Having a zip based solution means that you
can 'unbundle' from the command line even without LyX, the base64 solution
is more complex.
I would favour a simple bundling / unbundling where everything is bundled
and everything is unbundled but add the possibility to
José Matos <[EMAIL PROTECTED]> writes:
> On Friday 09 May 2008 10:35:00 Abdelrazak Younes wrote:
>> We (I think I can speak for everybody) certainly want you to be the
>> 1.6.x stable release manager. You made a pretty good job at managing 1.5.x.
>
> +1
me too!
Andre Poenitz <[EMAIL PROTECTED]> writes:
> PS: As a bold but reasonably educated guess: We could get rid of 90% of
> the code in support/* _and_ reduce compile and link times by a third (on
> top of that what we gained lately _and_ get a decent socket _and_ get
> a decent concurrency framework if
Uwe Stöhr <[EMAIL PROTECTED]> writes:
> caption is one of the most popular LaTeX-packages, so we can expect
> that many users load it in the preamble.
Where do you get such information? How do we measure 'popular'? I
would be surprised to learn that people are more excited about
customizing capt
Bo Peng wrote:
On Mon, May 12, 2008 at 6:43 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
In that sense, the
> > reversibility problem is yours, not mine.
> >
> I'm perplexed about this, since I don't have any such problem.
Let me try it the last time.
Let me try to summari
86 matches
Mail list logo
