"Bo Peng" <[EMAIL PROTECTED]> writes:
> Could you elaborate? Is that a pure-text tar-like format? I think you
> are suggesting a tar-like format that is not compressed so that it can
> be svned. I do not know how binary files such as jpg would be
> represented in such a file.
No, a mac osx bundle
On Wed, Apr 02, 2008 at 04:54:32AM +0200, Enrico Forestieri wrote:
> On Tue, Apr 01, 2008 at 01:00:25PM +0200, Jean-Marc Lasgouttes wrote:
>
> > I have no idea whether this works on windows/mingw or windows/cygwin,
> > but I'd be interested to learn about it.
>
> Seemingly, it doesn't work. I fir
On Tue, Apr 01, 2008 at 07:05:41PM -0400, rgheck wrote:
>
>> There's are 400 lines of "general" read/write infrastructure plus three
>> extra static methods per inset that in the end achieve something pretty
>> similar to
>>
>> void InsetMathSqrt::write(WriteStream & os) const
>> {
On Wed, Apr 02, 2008 at 12:54:21AM +0200, Pavel Sanda wrote:
> > Since the code seems stable I think that we can proceed directly to a
> > beta
> > release 3 to 4 weeks after the first release.
> >
> > So I am proposing two dates:
> > alpha 1 - 19 March
> > beta 1 - 2 April
> >
On Tue, Apr 01, 2008 at 06:49:25PM -0400, rgheck wrote:
> Andre Poenitz wrote:
>> > We won't know this until we look at fixing that. I'm inclined, actually,
>> to > do something more general, namely, to try to bring InsetGraphic into
>> the > InsetCommand hierarchy. I think this was intended all
Hi,
There was some discussion on lyx-users a few years ago about patching Qt
to swap the Command and Control keys on the Mac for people who use Emacs
key bindings:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg49883.html.
Since then, Jens Noeckel and I have occasionally compiled binaries with
On Tue, Apr 01, 2008 at 01:00:25PM +0200, Jean-Marc Lasgouttes wrote:
> I have no idea whether this works on windows/mingw or windows/cygwin,
> but I'd be interested to learn about it.
Seemingly, it doesn't work. I firstly ran configure using the switch
--with-qt='/usr/local/qt/4.3.4' and got:
c
Joost Verburg wrote:
[EMAIL PROTECTED] wrote:
I've talked to Andrei, Rex etc and from a design point of view, we're
ready to go live. So what else is missing before a release?
When the dynamic content is ready we can go live. Of course we'll
still continue to improve the content when the site
>> I've talked to Andrei, Rex etc and from a design point of view, we're
>> ready to go live. So what else is missing before a release?
>
> When the dynamic content is ready we can go live. Of course we'll still
> continue to improve the content when the site is on-line, but what we have
> right
> > whem i use e.g ToC window separately i find two annoyances - firstly
> > moving/resizing main window moves the widget too, secondly it is
> > not possible to put ToC window into the background.
>
> You mean the ToC can't be put behind the main app?
yes.
>That's a feature.
ok, i'll change i
There's are 400 lines of "general" read/write infrastructure plus three
extra static methods per inset that in the end achieve something pretty
similar to
void InsetMathSqrt::write(WriteStream & os) const
{
os << "\\sqrt{" << cell(0) << '}';
}
vo
> Pavel Sanda wrote:
>>> I've talked to Andrei, Rex etc and from a design point of view, we're
>>> ready to go live. So what else is missing before a release?
>> Christian, would it be possible to have 'All recent changes' as we have in
>> wiki so one have quick review what is happening on the pag
> Since the code seems stable I think that we can proceed directly to a
> beta
> release 3 to 4 weeks after the first release.
>
> So I am proposing two dates:
> alpha 1 - 19 March
> beta 1 - 2 April
>
> Comments and suggestions are welcome...
~ $ date
Wed Apr 2
[EMAIL PROTECTED] wrote:
I've talked to Andrei, Rex etc and from a design point of view, we're
ready to go live. So what else is missing before a release?
When the dynamic content is ready we can go live. Of course we'll still
continue to improve the content when the site is on-line, but what
Andre Poenitz wrote:
What is, btw, LATEX_KV_REQUIRED and LATEX_KV_OPTIONAL good for?
LyX compiles fine without those?
They're not currently used. I introduced them and then got sidetracked.
The intention is to use them to represent keyval-type parameters.
rh
Andre Poenitz wrote:
> We won't know this until we look at fixing that. I'm inclined, actually, to
> do something more general, namely, to try to bring InsetGraphic into the
> InsetCommand hierarchy. I think this was intended all along as part of a
> more general transition that was never finis
On Tue, Apr 01, 2008 at 09:18:04AM -, [EMAIL PROTECTED] wrote:
> Author: lasgouttes
> Date: Tue Apr 1 11:18:03 2008
> New Revision: 24083
>
> URL: http://www.lyx.org/trac/changeset/24083
> Log:
> do not use #ifdef in main code; use the lyxrc.dist mechanism to provide
> defaults for mac osx
Looking a bit closer at it I start to dislike it. It's exactly the
same kind of "horizontal" structure like the controllers that forces
us to consider things equally that aren't equal by nature.
There's are 400 lines of "general" read/write infrastructure plus three
extra static methods per inse
On Wed, Apr 02, 2008 at 12:05:12AM +0200, Joost Verburg wrote:
> Andre Poenitz wrote:
>> On Mon, Mar 31, 2008 at 10:26:37PM +0200, Joost Verburg wrote:
>>> Andre Poenitz wrote:
I mean the gradient from 'half-grey' to 'dark-grey' left of the
'navigaion column'. This is present but useless/
Andre Poenitz wrote:
On Mon, Mar 31, 2008 at 10:26:37PM +0200, Joost Verburg wrote:
Andre Poenitz wrote:
I mean the gradient from 'half-grey' to 'dark-grey' left of the
'navigaion column'. This is present but useless/troublesome for small
widths.
I understand what you mean. It's just about 20 p
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Tue, Apr 01, 2008 at 03:39:11PM +0200, Leuven, E. wrote:
atm selections are drawn as follows:
http://leuven.economists.nl/lyx/sel1.png
as you can see, the selection margins sometimes extend too much to
the left/right.
the attached patch remo
On Tue, Apr 01, 2008 at 05:36:20PM -0400, rgheck wrote:
> Bo Peng wrote:
>>> > What is the key to this map? If it is biblio, not /path/to/biblio.bib,
>>> > then you can make bibfiles_ a map, and the meta_ patch is no longer
>>> > needed.
>>> >
>>> Yes. This is what I've been trying to say, mor
Andre Poenitz wrote:
On Tue, Apr 01, 2008 at 03:39:11PM +0200, Leuven, E. wrote:
atm selections are drawn as follows:
http://leuven.economists.nl/lyx/sel1.png
as you can see, the selection margins sometimes extend too much to the
left/right.
the attached patch removes some drawing code, with
On Tue, Apr 01, 2008 at 05:36:13PM -0400, rgheck wrote:
>
> Just a quick check: Suppose I have a map map1 and use map::insert to insert
> some stuff from another map, map2. Suppose there are items in map2 with
> the same key as the items in map1. Then the map2 items will over-write the
> map1 i
> > There are then some minor problems left, such as 1. In functions such
> > as addDatabase, should we update params first and update
> > EmbeddedFileList/Map; or another way around?
> >
> or encapsulate it in overridden setParam methods, so you can't forget to
> do it.
I disliked your impl
Bo Peng wrote:
> What is the key to this map? If it is biblio, not /path/to/biblio.bib,
> then you can make bibfiles_ a map, and the meta_ patch is no longer
> needed.
>
Yes. This is what I've been trying to say, more or less. But note that,
when we output latex, we iterate not over bibfile
Just a quick check: Suppose I have a map map1 and use map::insert to
insert some stuff from another map, map2. Suppose there are items in
map2 with the same key as the items in map1. Then the map2 items will
over-write the map1 items. Right?
rh
--
---
Richard G Heck Jr
Pavel Sanda wrote:
I've talked to Andrei, Rex etc and from a design point of view, we're ready
to go live. So what else is missing before a release?
Christian, would it be possible to have 'All recent changes' as we have in
wiki so one have quick review what is happening on the pages?
http://
> I've talked to Andrei, Rex etc and from a design point of view, we're ready
> to go live. So what else is missing before a release?
Christian, would it be possible to have 'All recent changes' as we have in
wiki so one have quick review what is happening on the pages?
pavel
> > What is the key to this map? If it is biblio, not /path/to/biblio.bib,
> > then you can make bibfiles_ a map, and the meta_ patch is no longer
> > needed.
> >
> Yes. This is what I've been trying to say, more or less. But note that,
> when we output latex, we iterate not over bibfiles_ bu
On Tue, Apr 01, 2008 at 10:15:16PM +0200, Pavel Sanda wrote:
> hi,
>
> whem i use e.g ToC window separately i find two annoyances - firstly
> moving/resizing main window moves the widget too, secondly it is
> not possible to put ToC window into the background.
You mean the ToC can't be put behind
I've talked to Andrei, Rex etc and from a design point of view, we're
ready to go live. So what else is missing before a release?
I've modified
http://www.lyx.org/test/NewWebsiteDevelopment
(btw, it's easier to work with the wiki version, i.e.
http://www.lyx.org/test/wiki/inde
Bo Peng wrote:
Look, I want to make bibfilesCache_ a map. I have very good reasons to
want to do this. I therefore want InsetBibtex::getBibFilesCache() to
return such a map. (I suppose it could return something else, and then I
could do some conversion, but why?) Back in InsetBibtex, I can
hi,
whem i use e.g ToC window separately i find two annoyances - firstly
moving/resizing main window moves the widget too, secondly it is
not possible to put ToC window into the background.
these are intended behaviour or bug? or not easy to implement?
pavel
> You STILL don't understand the point. This isn't about
> Buffer::embeddedFile(), which is what is used to save the zip file. It's
> about the bibfilesCache_, which is a totally separate thing.
I though that you are changing EmbeddedFileList from
vector to map. This will of
course change buffe
Bo Peng wrote:
I wasn't trying to argue. I was trying to collaborate. But you are so
protective of your code that you won't even let me fix the bugs YOU created.
protective?? right. Note that your patch came before you understood
how embedding works.
That was several patches ago. God
Jean-Marc Lasgouttes wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
It is lucky that you are not supposed to svn an embedded .lyx file.
Actually, it is rather a shortcoming of the implementation.
As I say elsewhere, the current implementation can guarantee that the
order of the em
> Bo one question, out of curiosity, do you know of any other program that does
> what you are proposing (working with external files)?
No. :-)
The embedding feature is unique in its bunble/unbundle reversibility.
In the word/ooffice world, embedded objects are embedded, and there
are limited o
José Matos wrote:
On Tuesday 01 April 2008 19:36:39 Joost Verburg wrote:
Hi,
The attached patch fixes the file selection dialog on Windows. To
display all files *.* should be used, otherwise shortcuts won't work. Is
this OK for branch and trunk?
Regards,
Joost
Is this the only instance wher
On Tuesday 01 April 2008 19:36:39 Joost Verburg wrote:
> Hi,
>
> The attached patch fixes the file selection dialog on Windows. To
> display all files *.* should be used, otherwise shortcuts won't work. Is
> this OK for branch and trunk?
>
> Regards,
>
> Joost
Is this the only instance where this
On Tuesday 01 April 2008 19:10:13 Bo Peng wrote:
> Given that a lot of work has been done to make it work, I propose that
> we add an option ([ ] bundle files not in or under the document
> directory) that is by default disabled. In this way, we at least allow
> power users to emded such files.
Bo
Hi,
The attached patch fixes the file selection dialog on Windows. To
display all files *.* should be used, otherwise shortcuts won't work. Is
this OK for branch and trunk?
Regards,
Joost
Index: src/support/FileFilterList.cpp
==
On Tue, Apr 01, 2008 at 03:39:11PM +0200, Leuven, E. wrote:
>
> atm selections are drawn as follows:
>
> http://leuven.economists.nl/lyx/sel1.png
>
> as you can see, the selection margins sometimes extend too much to the
> left/right.
>
> the attached patch removes some drawing code, with this
> > Please provide your answer to all questions raised on that thread if
> > you are going to endorse Richard's proposal.
>
> You mean I am not allowing to chime in at all, then? The thread is
> quite extensive...
I apologize. I had the impression that you were endorsing Richard's
proposal bec
> Actually, it is rather a shortcoming of the implementation. If we
> allowed for a osx bundle-like representation (which would just have to
> be zipped to be a proper embedded file), this could go seemlessly into
> an svn archive. I understand this may not be doable immediately, but
> it is s
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> > This is not how it is in my work. There are no "main authors" in the
>> > collaborative work I do.
>>
>> +1
>>
>> We shall not restrict the implementation in terms of one particular
>> use case. The two authors could be me (at home and work), for exa
On Tue, Apr 01, 2008 at 08:35:03AM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > What about "Enspace (kern 0.5 em)", maybe placed after QQuad, such that
> > the casual user would choose "Enskip (0.5 em)", which comes first?
> > The expert user would be informed that this is a ker
"Bo Peng" <[EMAIL PROTECTED]> writes:
> It is lucky that you are not supposed to svn an embedded .lyx file.
Actually, it is rather a shortcoming of the implementation. If we
allowed for a osx bundle-like representation (which would just have to
be zipped to be a proper embedded file), this could
On Tue, Apr 01, 2008 at 08:35:03AM +0200, Jürgen Spitzmüller wrote:
> Enrico Forestieri wrote:
> > What about "Enspace (kern 0.5 em)", maybe placed after QQuad, such that
> > the casual user would choose "Enskip (0.5 em)", which comes first?
> > The expert user would be informed that this is a kern
> They do not *now*. If a lyx file uses a file with absolute path. It
> only works on a system with exactly that file. Now, with embedding, it
> works on all systems.
Note that Richard's approach does not say how to handle the case when
a user would like to make use of such a file. I mean, in b
> I thought the crucial line was:
>
> >> We want our documents to behave the same way regardless of where they are.
> >>
> >>
> They don't.
They do not *now*. If a lyx file uses a file with absolute path. It
only works on a system with exactly that file. Now, with embedding, it
works on all sy
> I wasn't trying to argue. I was trying to collaborate. But you are so
> protective of your code that you won't even let me fix the bugs YOU created.
protective?? right. Note that your patch came before you understood
how embedding works.
> The example wasn't idle. Using a map in InsetBibtex
Bo Peng wrote:
I thought the crucial line was:
We want our documents to behave the same way regardless of where they are.
They don't.
rh
> Embedding files with absolute paths should imply to copy them to a temporary
> directory. We want our documents to behave the same way regardless of where
> they are.
>
> To me this problem has some similarities with the cursor saving. We don't
> save the document position in the document
Jurgen wrote:
> Your second patch is all that I was asking for.
perhaps, but the ignorance of insets about being selected is illustrated these
two screenshots:
http://leuven.economists.nl/lyx/sel2.png
http://leuven.economists.nl/lyx/sel3.png
José Matos wrote:
On Tuesday 01 April 2008 16:04:06 Bo Peng wrote:
I have stated in another
thread that embedding files with absolute-path has many benefits, and
the current solution is almost good enough, and getting rid of the
embedding editing mode altogether because of this problem is har
Bo Peng wrote:
Yes, I understand that we need to look up that information. But what I'm
saying is that I want to use the EmbeddedFileList, which we're keeping
in sync with the params, ONLY to look that information up if and when
it's needed, and not use it in other ways. Yes, this is a minor
Leuven, E. wrote:
> not atm i think. i have the impression that insets don't take into account
> whether they are selected or not when they paint themselves...
Your second patch is all that I was asking for.
Jürgen
On Tuesday 01 April 2008 16:43:29 Leuven, E. wrote:
> Since you asked. :-)
>
> 2nd iteration.
To be coherent the only possible answer is that I like it. :-)
--
José Abílio
On Saturday 29 March 2008 19:54:49 Paul Johnson wrote:
> I am sorry if you are getting it twice. I tried to send this into
> lyx-devel 3 days ago right after I subscribed, but it never showed up
> in my inbox.
>
> There's an old bug
>
> http://bugzilla.lyx.org/show_bug.cgi?id=48
>
> and last week I
On Tuesday 01 April 2008 16:04:06 Bo Peng wrote:
> I have stated in another
> thread that embedding files with absolute-path has many benefits, and
> the current solution is almost good enough, and getting rid of the
> embedding editing mode altogether because of this problem is hard to
> justify.
> As I said, I just don't care for this attitude. These are our problems,
> not the users'. and simply declaring that there's no other way is just,
> well, not productive.
This is *not* our problem. Users want to use the *same* file on
different systems, but this file can not be presented as th
> can you get the section/enumerate numbers to be highlighted as well?
not atm i think. i have the impression that insets don't take into account
whether they are selected or not when they paint themselves...
> Since you asked. :-)
2nd iteration.
this is the current situation:
http://leuven.economists.nl/lyx/sel1.png
the attached patch gives this:
http://leuven.economists.nl/lyx/sel2.png
Index: src/TextMetrics.cpp
===
--- src/TextMet
Bo Peng wrote:
> You are talking about the worst scenario
>
No, this is the normal scenario, at least on any system other than
Windows: Absolute paths to files in my user tree will not be writable on
(almost) any other system. And writing the file somewhere else breaks
the LyX file.
On Tue, 1 Apr 2008, Pavel Sanda wrote:
on a different note: what about this header?
http://195.113.31.123/~sanda/junk/header.gif
If it's for wiki.lyx.org,
no i meant it for www.lyx.org
Ok, I'll bounce that ball to Joost... Joost?
/C
--
Christian Ridderström, +46-8-768 39 44
hi,
i'm new to LyX and am hoping someone can assist on a problem I'm having.
On a fairly regular basis when I select the "dvi" button or the "div update"
button Yap crashes and gives the message:
"MiKTeX Problem Report:
Permission denied: C:\TEMP\lyx_tmpdir280a01160\lyx_tmpbuf1\my_file.dvi"
I re
> > This is not how it is in my work. There are no "main authors" in the
> > collaborative work I do.
>
> +1
>
> We shall not restrict the implementation in terms of one particular
> use case. The two authors could be me (at home and work), for example.
Please provide your answer to all quest
Leuven, E. wrote:
> opinions/suggestions?
can you get the section/enumerate numbers to be highlighted as well?
Jürgen
On Tuesday 01 April 2008 14:39:11 Leuven, E. wrote:
> which i think is much nicer
>
> opinions/suggestions?
Since you asked. :-)
Aesthetically I don't like it. It would prefer maybe a compromise where only
the text region (that is all the document with the exception of the margins)
is selected,
atm selections are drawn as follows:
http://leuven.economists.nl/lyx/sel1.png
as you can see, the selection margins sometimes extend too much to the
left/right.
the attached patch removes some drawing code, with this as a result:
http://leuven.economists.nl/lyx/sel2.png
which i think is much
The following experimental patch is a work in progress to see whether
it is feasble to get rid of our current solutions (1/ try pkg-config
2/ try linking with X11) to detect Qt. This uses a heavily butchered
version of the autotroll set of m4 macros found somewhere on the net.
The situation now i
>> on a different note: what about this header?
>> http://195.113.31.123/~sanda/junk/header.gif
>
> If it's for wiki.lyx.org,
no i meant it for www.lyx.org
pavel
Richard Heck <[EMAIL PROTECTED]> writes:
>> While I will not take my words back, I would like to point out that
>> usually, only the main author needs to edit auxillary files, and use
>> version control system to back up the text version of the lyx file.
>> When you send your embedded version to y
On Tue, 1 Apr 2008, Pavel Sanda wrote:
on a different note: what about this header?
http://195.113.31.123/~sanda/junk/header.gif
If it's for wiki.lyx.org, I'd like to wait with messing around with it
until we've sorted out a released www.lyx.org.
After that, the room for improving wiki.lyx.
75 matches
Mail list logo
