Bo Peng wrote:
Reading your insistance on people to answer your question about
bundling/unbundling, I guess that they don't understand why one would need
to work in "bundled" mode, simply because there is no such bundled mode if
you keep everything in one directory. They just want a "packed", po
[EMAIL PROTECTED] wrote:
On Thu, 10 Apr 2008, Bo Peng wrote:
On Thu, Apr 10, 2008 at 2:15 PM, Edwin Leuven
<[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
What is the problem here?
your fundamental unwillingess to arrive at a reasonable compromise i
suppose...
Because no *reasonable* proposal
On Thu, 10 Apr 2008, Bo Peng wrote:
On Thu, Apr 10, 2008 at 2:15 PM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
Bo Peng wrote:
What is the problem here?
your fundamental unwillingess to arrive at a reasonable compromise i
suppose...
Because no *reasonable* proposal was given. I spent a lot
> > 1. In bundled mode, do you create filename.lyz or
> > filename.lyxdir/content.lyx when you create a new file and save?
> >
> My proposal, following JMarc, was that bundled mode is separate from
> compressed mode. So it depends upon whether we're creating a compressed
> bundle or not. If it's s
Bo Peng wrote:
my concern is - in case user will not use bundling feature at all, on
what places can bubble up bugs caused by embeding code. only InsetBibtex
usage? what kind of bugs?
The bugs are related to latex output, which only show up in
InsetBibtex right now.
The bugs also a
Bob Lounsbury wrote:
Out of curiosity have you have run into this error:
TocBackend.cpp:201: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [TocBackend.lo] Erro
Bo Peng wrote:
Then, please answer *directly* the following questions:
OK, well, since it seems to matter so much to you, I will answer them.
Again.
But let me emphasize, again, that these are all questions about
implementation details, and they can be worked out. As I always tell my
studen
On Thu, Apr 10, 2008 at 8:08 PM, rgheck <[EMAIL PROTECTED]> wrote:
> Bob Lounsbury wrote:
>
> > I just tried to build the latest svn revision #24220 on Slackware and
> > got this error during make:
> >
> >
> >
> Andre forgot to svn add this new file. (We've all done it.) I'm guessing
> he'll do it
> my concern is - in case user will not use bundling feature at all, on
> what places can bubble up bugs caused by embeding code. only InsetBibtex
> usage? what kind of bugs?
The bugs are related to latex output, which only show up in
InsetBibtex right now. As I have said, the bugs themselves a
Bob Lounsbury wrote:
I just tried to build the latest svn revision #24220 on Slackware and
got this error during make:
Andre forgot to svn add this new file. (We've all done it.) I'm guessing
he'll do it tomorrow, when he's back online. Until then, you'll need to
roll back to 24209: svn up
I just tried to build the latest svn revision #24220 on Slackware and
got this error during make:
docstring.cpp:25:28: error: support/assert.h: No such file or directory
docstring.cpp: In function 'const lyx::docstring lyx::from_ascii(const char*)':
docstring.cpp:36: error: expected primary-expres
> Pavel Sanda wrote:
Abdel, what is the reason for geometry argument used only when #ifdef
Q_WS_WIN ?
>>> the -geometry argument is supposed to be handled by X11 natively so we
>>> just
>>> ignore it on this platform.
>> which is wrong in case this lfun is called directly from command bu
> >> The following patch fixes the context menus for conglomerate-like
> >> insets.
> >
> > can you be more specific what exactly are you trying to fix?
> > currently i know about more bugs about the context menu of
> > insets toggling.
>
> The 'show label' entry of conglomerate-style insets (char
> These things do not need to be discussed. They should be imposed ;-)
But our release dictator doesn't impose but tests out democracy ;-).
> Temptative schedule:
> alpha2: today :-)
> beta1: 01/06/2008
> beta2: 15/06/2008
> RC1 or beta3: 01/07/2008
> RC2 or beta4: 15/07/2008
> 1.6.0 or RC3: 01/
The attached patch for trunk fixes
http://bugzilla.lyx.org/show_bug.cgi?id=2504
http://bugzilla.lyx.org/show_bug.cgi?id=2504#c7
describes what the patch is for.
Jürgen, can this also go into branch?
regards Uwe
Index: text.cpp
===
> Reading your insistance on people to answer your question about
> bundling/unbundling, I guess that they don't understand why one would need
> to work in "bundled" mode, simply because there is no such bundled mode if
> you keep everything in one directory. They just want a "packed", portable,
>
Uwe Stöhr wrote:
> OTHO, surely I agree with you that we should start discussing the
schedule for
> the first beta and rc releases.
Ping.
These things do not need to be discussed. They should be imposed ;-)
Temptative schedule:
alpha2: today :-)
beta1: 01/06/2008
beta2: 15/06/2008
RC1 or b
Pavel Sanda wrote:
Abdel, what is the reason for geometry argument used only when #ifdef
Q_WS_WIN ?
the -geometry argument is supposed to be handled by X11 natively so we just
ignore it on this platform.
which is wrong in case this lfun is called directly from command buffer.
But this is a s
Jean-Marc Lasgouttes wrote:
Do whatever you want, I give up. tactics Guerrilla is not my preferred
form of technical discussion. Implement whatever monstrous thing you
want, I do not care any more. It is just too bad that KISS does not
apply here anymore.
OK, I've read a tiny bit of this awful
> Author: poenitz
> Date: Thu Apr 10 23:49:34 2008
> New Revision: 24216
>
> URL: http://www.lyx.org/trac/changeset/24216
> Log:
> infrastructure for 'graceful asserts'
>
> Modified:
svn add support/assert.h
svn ci -m 'forgot this'
p
"Bo Peng" <[EMAIL PROTECTED]> writes:
> What did you propose? You have not answered my 'two home directory'
> question, you have not answered my 'open a directory weirdness'
> question, yet you have not answered my 'how do you share files between
> different documents as we do now' question. Your p
Pavel Sanda wrote:
it is still the case or its better now?
do i also understand correctly that the changes pervade to larger areas of
code which is rather far away from bundling? (sorry for such novice questions,
i havent followed the threads closely, nor i read the code)
The related
> > it is still the case or its better now?
> >
> > do i also understand correctly that the changes pervade to larger areas of
> > code which is rather far away from bundling? (sorry for such novice
> > questions,
> > i havent followed the threads closely, nor i read the code)
>
> The related
> To give an example: the fact that the file
> copying that needs to happen to make the embedding stuff work happens in
> places like GuiGraphics makes me nervous.
Excuse me? We are talking about your proposal, right? My proposal was
attacked long enough and I have long admitted the code complex
rgheck wrote:
Pavel Sanda wrote:
puzzled I got about why such extensive changes had to be made and
couldn't be confined to some relatively well defined aspect of the
code.
...
the whole implementation was nearly impossible to understand.
it is still the case or its better now?
It's stil
> > Please, please, answer my questions. The problem is exactly I can not
> > think of a way to IMPLEMENT your proposal, even if I accept your
> > restrictions.
> >
> The problem seems very much to be that you don't WANT to think of a way to
> implement the proposal.
How can I raise so many quest
Bo Peng wrote:
Precisely. The discussion was supposed to be about very abstract questions
about how bundling might and should work. And Bo keeps raising questions of
the form, "Well, exactly how do you propose to implement this bit?" The most
ridiculous thing is that the answers are very often p
Pavel Sanda wrote:
puzzled I got about why such extensive changes had to be made and couldn't
be confined to some relatively well defined aspect of the code.
...
the whole implementation was nearly impossible to understand.
it is still the case or its better now?
It's stil
Rex C. Eastbourne wrote:
I like the idea of a search box. I created a Google custom search
engine for different LyX websites, including *.lyx.org and the mailing
lists here:
http://www.google.com/coop/cse?cx=008972033992887248866%3Aoarvwprmgvo
We can embed this search box and even the search
> > Then, please answer *directly* the following questions:
PLEASE, answer these questions directly!
> > 1. In bundled mode, do you create filename.lyz or
> > filename.lyxdir/content.lyx when you create a new file and save?
> >
> > 2. What is your *file* when a user chooses 'unbundle'? Contineue
> Precisely. The discussion was supposed to be about very abstract questions
> about how bundling might and should work. And Bo keeps raising questions of
> the form, "Well, exactly how do you propose to implement this bit?" The most
> ridiculous thing is that the answers are very often pretty obv
Bo Peng wrote:
Several people have now explained how it can be implemented. Perhaps the
problem isn't with us.
Then, please answer *directly* the following questions:
1. In bundled mode, do you create filename.lyz or
filename.lyxdir/content.lyx when you create a new file and save?
2. Wh
Edwin Leuven wrote:
Bo Peng wrote:
but please tell me how his proposal can possibly be implemented.
i didn't have the impression that the discussion was about
implementation details once everything is under the same directory, but
rather about how to treat out of tree files...
Precisely. The
> it is still the case or its better now?
>
> do i also understand correctly that the changes pervade to larger areas of
> code which is rather far away from bundling? (sorry for such novice
> questions,
> i havent followed the threads closely, nor i read the code)
The related code is mostly
> i didn't have the impression that the discussion was about
> implementation details once everything is under the same directory, but
> rather about how to treat out of tree files...
JMarc disallows all out of tree files and yet his proposal does not
work. I have not heard that he agreed with
> puzzled I got about why such extensive changes had to be made and couldn't
> be confined to some relatively well defined aspect of the code.
...
>the whole implementation was nearly impossible to understand.
it is still the case or its better now?
do i also understand correctly that the chan
> Several people have now explained how it can be implemented. Perhaps the
> problem isn't with us.
Then, please answer *directly* the following questions:
1. In bundled mode, do you create filename.lyz or
filename.lyxdir/content.lyx when you create a new file and save?
2. What is your *file* w
Bo Peng wrote:
but please tell me how his proposal can possibly be implemented.
i didn't have the impression that the discussion was about
implementation details once everything is under the same directory, but
rather about how to treat out of tree files...
Bo Peng wrote:
i was hoping you would prove me wrong, but alas...
A fundamental problem with JMarc's approach is that he insists on a
directory structure and requires all related files to be copied to
this directory, yet it does not allow you to work in that directory
directly. If you are
> i was hoping you would prove me wrong, but alas...
A fundamental problem with JMarc's approach is that he insists on a
directory structure and requires all related files to be copied to
this directory, yet it does not allow you to work in that directory
directly. If you are unlucky to use an OS
Bo Peng wrote:
your fundamental unwillingess to arrive at a reasonable compromise i
suppose...
Because no *reasonable* proposal was given.
i was hoping you would prove me wrong, but alas...
On Thu, Apr 10, 2008 at 2:15 PM, Edwin Leuven <[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
>
> > What is the problem here?
>
> your fundamental unwillingess to arrive at a reasonable compromise i
> suppose...
Because no *reasonable* proposal was given. I spent a lot of time to
design, re-design an
Bo Peng wrote:
What is the problem here?
your fundamental unwillingess to arrive at a reasonable compromise i
suppose...
[EMAIL PROTECTED] wrote:
Hi,
I've added a search box to the sidebar, primarily to show how it can
be done. I'm not sure we want it there, or perhaps even at all,.
/Christian
I like the idea of a search box. I created a Google custom search engine
for different LyX websites, including *.lyx.
On Thu, Apr 10, 2008 at 12:59 PM, Jean-Marc Lasgouttes
<[EMAIL PROTECTED]> wrote:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
>
> > 1. You 9 consecutive folders is not a good argument because even on a
> > system with that file, you need to open 8 folders.
>
> Err, I usually start from my home direc
Jean-Marc Lasgouttes wrote:
Do whatever you want, I give up. Guerrilla is not my preferred
form of technical discussion. Implement whatever monstrous thing you
want, I do not care any more. It is just too bad that KISS does not
apply here anymore.
For what it's worth, I feel the same way, and
> OTHO, surely I agree with you that we should start discussing the schedule for
> the first beta and rc releases.
Ping.
regards Uwe
"Bo Peng" <[EMAIL PROTECTED]> writes:
> 1. You 9 consecutive folders is not a good argument because even on a
> system with that file, you need to open 8 folders.
Err, I usually start from my home directory, which is
/afs/inria.fr/rocq/home/imara/lasgoutt. I do not browse from the root
of the fil
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>
> Luis Rivera wrote:
> > Awesome! You only failed to mention that I had to run the configure script
> > to have the new language in the GUI menu (I like that expression).
> >
> > Also, is this the right place to suggest new additions?
>
> Yes.
>
> I will not insist on this as I think that I made my point clear, too much
> information leaked can become a security problem later.
Great.
Then our last disagreement would be on your session proposal. I know
you would not like me to abuse our user's guide again, but if a user
send us a revise
On Thursday 10 April 2008 15:28:55 Bo Peng wrote:
> All Jose's messages in the thread of 'Will this discussion continue? Re:
> blah'.
>
> http://marc.info/?l=lyx-devel&m=120721668632621&w=2
> http://marc.info/?l=lyx-devel&m=120733743320967&w=2
Bo presented examples before we had the file locatio
> I was not proposing to name files based on their md5 key. I was just giving
> this as an example how we can compare files not using the file path.
The latter was used extensively in lyx and in EmbeddedFiles during
unbundling, so I did not consider it as a new proposal...
Bo
On Wednesday 09 April 2008 17:26:10 Bo Peng wrote:
>
> I do not have a solid scenario to say your solution is wrong, but it
> sounds like you are naming files by their contents. In the tex world,
> we insert files by names and if we insert image1 and image2, we are
> inserting two different files e
> 1/ file included by any mean (InsetInclude, InsetGraphics,
> InsetExternal, InsetListings) are equivalent and should be treated the
> same
Good.
> 2/ I do not care if there is a reference to an absolute path that is
> not bundled with the LyX file. This would be too restrictive and has
>
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>
>> Instead of reinventing the wheel, it looks like you should move
>> findInset from BufferView.cpp to a place where other code can use it
>> and then use it with a DocIterator that initially contains only the
>> Floa
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> Care to explain the difference between "in .lyx file" and "for all insets"?
>
> I meant that we should not allow absolute paths in .lyx file for all
> insets such as InsetGraphics, not only those with embedded files, IF
> absolute path in .lyx file is an c
> > 2. If you simply can not accept such a filename in .lyx file, you
> > should disable it for all insets.
>
> Care to explain the difference between "in .lyx file" and "for all insets"?
I meant that we should not allow absolute paths in .lyx file for all
insets such as InsetGraphics, not only
> I do not think this personal information problem is relevant. Where
> was is brought forward?
All Jose's messages in the thread of 'Will this discussion continue? Re: blah'.
http://marc.info/?l=lyx-devel&m=120721668632621&w=2
http://marc.info/?l=lyx-devel&m=120733743320967&w=2
Cheers,
Bo
Jean-Marc Lasgouttes wrote:
> Why not put this code in InsetCollapsable itself?
Do we want this for all collapsables? If so, yes.
Jürgen
[EMAIL PROTECTED] writes:
> Author: spitz
> Date: Thu Apr 10 12:05:00 2008
> New Revision: 24202
>
> URL: http://www.lyx.org/trac/changeset/24202
> Log:
> Extended tooltips for footnotes/marginpars:
Why not put this code in InsetCollapsable itself?
JMarc
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> The following patch fixes the context menus for conglomerate-like
>> insets.
>
> can you be more specific what exactly are you trying to fix?
> currently i know about more bugs about the context menu of
> insets toggling.
The 'show label' entry of conglo
"Bo Peng" <[EMAIL PROTECTED]> writes:
> The file produced in this way would be ugly if unbundled, but it at
> least gives you guys a peace of mind that no personal information is
> leaked. Note that I will not do this by myself, at least not at a high
> priority.
I do not think this personal infor
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> OK then. To be frank, I did not manage to read all the threads as
>> carefully as may be necessary.
>
> Now, at least we are talking about the same problem, but just to
> clarify, do you also care about information leak from relative paths
> ../../girlfri
"Leuven, E." <[EMAIL PROTECTED]> writes:
> (didn't you once had this sort of working jean-marc?)
It works for the standard classes. But I am sure there are classes
that need a cleanup.
JMarc
it happens quite often that a co-author asks me
"can you change blah blah blah in footnote 13?"
my answer then typically is
"footnote 13? how does it start?"
...
(didn't you once had this sort of working jean-marc?)
Jean-Marc Lasgouttes wrote:
> Instead of reinventing the wheel, it looks like you should move
> findInset from BufferView.cpp to a place where other code can use it
> and then use it with a DocIterator that initially contains only the
> Float inset as a slice.
Could you do this?
Jürgen
[EMAIL PROTECTED] writes:
> +docstring InsetFloat::getCaptionText(OutputParams const & runparams) const
> +{
> + if (paragraphs().empty())
> + return docstring();
> +
> + ParagraphList::const_iterator pit = paragraphs().begin();
> + for (; pit != paragraphs().end(); ++pit)
67 matches
Mail list logo
