Michael Gerz wrote:
> Jürgen, do you think we have enough patches for 1.5.2?
No. We still have important issues to solve.
I'll send out another update soon.
Jürgen
Uwe Stöhr wrote:
> can this fix also go into branch?:
> http://www.lyx.org/trac/changeset/20257
Please wait. Paul Rubin has done a major rewrite of the AMS classes that will
go in soon. I don't want to interfere his work.
Jürgen
On Fri, Sep 14, 2007 at 02:08:10AM -0400, Richard Heck wrote:
>
> This seems to solve the problem. I'll commit if there's no objection.
>
> By the way, there's a lot of mismatch now between filenames and
> classnames. E.g., the class defined in GuiCitation.cpp is
> GuiCitationDialog. Which way
This seems to solve the problem. I'll commit if there's no objection.
By the way, there's a lot of mismatch now between filenames and
classnames. E.g., the class defined in GuiCitation.cpp is
GuiCitationDialog. Which way should this be resolved?
Richard
--
==
Richard Heck wrote:
As said. I have some idea what's wrong here, but it may be a more
general problem, so someone else should have a look.
Open the citation dialog. Nothing's there! Now hit restore, and it's
all there.
The problem is that nothing is calling
GuiCitationDialog::initialisePa
Martin Vermeer wrote:
On Fri, Sep 14, 2007 at 01:35:57AM +0200, Tommaso Cucinotta wrote:
Jean-Marc Lasgouttes ha scritto:
Tommaso Cucinotta <[EMAIL PROTECTED]> writes:
On a related note, what about implementing the C-Tab shortcut
almost standard on multi-document editors (cyc
> Here is a question for you: Do you want to display true, embedded
> filename, or the may-not-exist external filename in the graphics
> dialog? The attached patch does the former, but in a ugly way:
>
Attached is an updated patch, which is even uglier because it tries to
display 'Embedded:/filena
Oops, sorry Abdel, I forgot to send to the list.
> > Why? RandomAccessList::iterator is a std::list::iterator...
>
> Right but operator[] is fast. There was a fast iterator version once
The code is full std::advance(pit, something) or boost::next(pit,
something) that is currently O(n). That's why
On Fri, Sep 14, 2007 at 01:35:57AM +0200, Tommaso Cucinotta wrote:
> Jean-Marc Lasgouttes ha scritto:
> >Tommaso Cucinotta <[EMAIL PROTECTED]> writes:
> >
> >
> >>On a related note, what about implementing the C-Tab shortcut
> >>almost standard on multi-document editors (cycle through
> >>open bu
On 14/09/2007, at 12:35 PM, Bennett Helm wrote:
This looks to me like you have a failed svn update. Unless you've
made changes to it, try deleting ca.po and svn update again. It
should work.
Bennett
Thanks Bennet.
I had to delete all the .po files to solve the problem.
"Making all in p
On Sep 13, 2007, at 9:37 PM, Roger Mc Murtrie wrote:
Intel Mac
Max OSX 10.4.10
make fails for trunk in po:
Making all in po
test ! -f ./LyX-1.6.pot || \
test -z "ca.gmo cs.gmo de.gmo es.gmo eu.gmo fi.gmo fr.gmo
gl.gmo he.gmo hu.gmo it.gmo ja.gmo ko.gmo nb.gmo nn.gmo pl.gmo
pt.gmo
> Or output to a string (or ostringstream) first and then use rstrip.
> But it may be that this will not do encoding properly. What encoding
> does hyperref want in its title things?
afaiu there is possibility to switch between PDFDocEncoding and unicode.
i played a bit with setting enc. to utf8
On Fri, 2007-09-14 at 11:31 +1000, Darren Freeman wrote:
> Suggestion: A dialogue could ask whether the user wants to update the
> existing preview, thus only one menu item is required for each file
> format to preview. They need only one set of keybindings, plus two more
> for "Update existing" an
Intel Mac
Max OSX 10.4.10
make fails for trunk in po:
Making all in po
test ! -f ./LyX-1.6.pot || \
test -z "ca.gmo cs.gmo de.gmo es.gmo eu.gmo fi.gmo fr.gmo
gl.gmo he.gmo hu.gmo it.gmo ja.gmo ko.gmo nb.gmo nn.gmo pl.gmo pt.gmo
ro.gmo tr.gmo zh_CN.gmo zh_TW.gmo" || make ca.gmo cs.g
On Fri, 2007-09-14 at 00:57 +0200, Tommaso Cucinotta wrote:
> Also, let me propose some rework of the View menu (independently
> from the master-buffer-view being accepted or not):
I'm in favour of this change compared to the present menu.
However I'd like to make a couple of suggestions for th
Index: src/LyXFunc.cpp
===
--- src/LyXFunc.cpp (revisione 20259)
+++ src/LyXFunc.cpp (copia locale)
@@ -999,6 +1001,16 @@
Exporter::preview(lyx_view_->buffer(), argument);
brea
Jean-Marc Lasgouttes ha scritto:
Tommaso Cucinotta <[EMAIL PROTECTED]> writes:
On a related note, what about implementing the C-Tab shortcut
almost standard on multi-document editors (cycle through
open buffers).
We have Ctrl-PageUp/Down for that. C-Tab is often used by other things
(
Bo Peng ha scritto:
[...]
We already have many items
under the View menu, and a shortcut-only hidden feature is not that
appealing.
Also, let me propose some rework of the View menu (independently
from the master-buffer-view being accepted or not):
View
+- Zoom
| +- Increase 20% (C-+)
| +-
As said. I have some idea what's wrong here, but it may be a more
general problem, so someone else should have a look.
Open the citation dialog. Nothing's there! Now hit restore, and it's all
there.
The problem is that nothing is calling
GuiCitationDialog::initialiseParams(). I'm not sure
Attached is the last patch in this series (but for bugfixing): It adds
the frontend for selecting modules, etc. Comments welcome.
It doesn't actually seem to work at the moment. Something is broken in
this dialog and in the citation dialog. This is presumably a consequence
of the recent chao
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> I expect people will think this is at best ugly. I guess I'd do it by
>> outputting the comma BEFORE each bit...but only after testing some flag
>
> you cant after, there's no way back :)
Or output to a string (or ostringstream) first and then use rstr
Tommaso Cucinotta <[EMAIL PROTECTED]> writes:
> On a related note, what about implementing the C-Tab shortcut
> almost standard on multi-document editors (cycle through
> open buffers).
We have Ctrl-PageUp/Down for that. C-Tab is often used by other things
(but we could add it nevertheless).
> S
Tommaso Cucinotta wrote:
On a related note, what about implementing the C-Tab shortcut
almost standard on multi-document editors (cycle through
open buffers).
I think this already exists. Check the .bind file.
Richard
--
==
Richar
Pavel Sanda wrote:
I expect people will think this is at best ugly. I guess I'd do it by
outputting the comma BEFORE each bit...but only after testing some flag
you cant after, there's no way back :)
that tells us whether we've done the first one yet.
i was thinking about impl
Bo Peng ha scritto:
It is useful, but it is not so difficult to switch to the master
buffer and generate preview from there. We already have many items
under the View menu, and a shortcut-only hidden feature is not that
appealing.
Just a note: when you're about to finish an article, often
you
> I expect people will think this is at best ugly. I guess I'd do it by
> outputting the comma BEFORE each bit...but only after testing some flag
you cant after, there's no way back :)
> that tells us whether we've done the first one yet.
i was thinking about implementing some stream in-betwee
Richard Heck <[EMAIL PROTECTED]> writes:
> It might help make the code a little clearer if all of this stuff were
> taken out into a PDFOptions::writeLatex(odocstream &) routine that
> could just be called directly here, without even checking
> use_hyperref. You could do that there. And then chang
Richard Heck <[EMAIL PROTECTED]> writes:
>> All the range of export types should be supported, though.
>>
> And it is, as Tommaso has it.
I mean that we should have a C-M-d binding for postscript. And
probably a master-buffer-update lfun for completeness.
JMarc
Comments below.
diff --git a/src/BufferParams.cpp b/src/BufferParams.cpp
index e566cdd..2d297e2 100644
--- a/src/BufferParams.cpp
+++ b/src/BufferParams.cpp
@@ -1123,6 +1171,52 @@ bool BufferParams::writeLaTeX(odocstream & os, LaTeXFeatures
& features,
+ from_utf8(preambl
hi,
this is iteration #2. i guess that #3 will be needed still :)
any comments to code welcomed. i have tested it on the few cases
i usually use and seems to work.
sum of TODOS & screenshot added to wiki:
http://wiki.lyx.org/Devel/PDFSupport
TODOs & (my) questions
- does the ending ',' in \usep
Alfredo Braunstein wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Good idea, specially because what we have now is: "slow iteration as a list,
slow insertion as a vector"
Not really, what we have now is "fast iteration as a vector, fast
Why? RandomAccessList::iterator is a std::list
Jean-Marc Lasgouttes wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
I find it useful. Maybe others too.
It is useful, but it is not so difficult to switch to the master
buffer and generate preview from there. We already have many items
under the View menu, and a shortcut-only hidden fe
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > Good idea, specially because what we have now is: "slow iteration as a list,
> > slow insertion as a vector"
>
> Not really, what we have now is "fast iteration as a vector, fast
Why? RandomAccessList::iterator is a std::list::iterator...
>
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> The only drawback of the list based solution is that there is a little
> memory overhead. The advantage is of course that the problem below is
> easily solved:
>> The only problem could be if we assume list-type iterator stability on
>> insertion. No
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> I find it useful. Maybe others too.
>
> It is useful, but it is not so difficult to switch to the master
> buffer and generate preview from there. We already have many items
> under the View menu, and a shortcut-only hidden feature is not that
> appealing.
Edwin Leuven wrote:
However, this is very Qt/Gui intensive and I certainly do not have the
needed knowledge to do it. As a matter of fact, I asked help for
similar things when I design the listing dialog but everyone was busy.
people were busy and you were in a rush i seem to remember ;-)
i wou
> > I find it useful. Maybe others too.
>
> It is useful, but it is not so difficult to switch to the master
> buffer and generate preview from there. We already have many items
> under the View menu, and a shortcut-only hidden feature is not that
> appealing.
is it possible to achive this functi
Bo Peng wrote:
still think that an autogenerated properties dialog will be even better
though...
This is exactly what I proposed.
oops
The whole idea is not that difficult, we simply need a few text files
with fields like
parameter name, group name, type, hint, default value, validation
ty
Jürgen,
can this fix also go into branch?:
http://www.lyx.org/trac/changeset/20257
regards Uwe
Jürgen,
can this fix also go into branch?
regards Uwe
> I find it useful. Maybe others too.
It is useful, but it is not so difficult to switch to the master
buffer and generate preview from there. We already have many items
under the View menu, and a shortcut-only hidden feature is not that
appealing.
Bo
> still think that an autogenerated properties dialog will be even better
> though...
This is exactly what I proposed.
> the information you have put now in ParValidator::ParValidator() could
> be parsed to build the dialog
Yes.
> if there are a lot of parameters as with listing i am sure they
Bo Peng wrote:
We call it consistent behaviour. ;-)
Then we can implement a 'compose' dialog, that
1. Option [params ] Compose_Button
2. When the compose button is pressed, dialog 'compose
listings/hyperref/whatever options' is triggered.
3. This dialog has all the val
José Matos wrote:
On Thursday 13 September 2007 17:40:10 Bo Peng wrote:
We call it consistent behaviour. ;-)
Then we can implement a 'compose' dialog, that
1. Option [params ] Compose_Button
2. When the compose button is pressed, dialog 'compose
listings/hyper
Pavel Sanda wrote:
So you guys are willing to remove validation and allow the input of
arbitrary (wrong) parameters, just to make the dialog look prettier?
if you remove the validation from listings now, there will be screem
from users already using it. if it hasnt been shot down before 1.5.0
r
On Thursday 13 September 2007 17:40:10 Bo Peng wrote:
> > We call it consistent behaviour. ;-)
>
> Then we can implement a 'compose' dialog, that
>
> 1. Option [params ] Compose_Button
>
> 2. When the compose button is pressed, dialog 'compose
> listings/hyperref/whatever opt
Alfredo Braunstein wrote:
Jean-Marc Lasgouttes wrote:
Alfredo Braunstein <[EMAIL PROTECTED]>
writes:
I don't think it's possible unfortunately, for the reasons in my other
post. We could have a O(1) RandomAccessList::getIterator(int pos) but
it's obviously not so cool ;-) And it doesn't work
> So you guys are willing to remove validation and allow the input of
> arbitrary (wrong) parameters, just to make the dialog look prettier?
if you remove the validation from listings now, there will be screem
from users already using it. if it hasnt been shot down before 1.5.0
release, its afaik
On Thursday 13 September 2007 17:23:23 Bo Peng wrote:
> You know how much time I spent on this validation system, and on the
> AUTO embedding feature?
Much indeed. :-)
The validation is nice and I would like to see it extended to other places.
But I would like to see that happen in a smooth a
> We call it consistent behaviour. ;-)
Then we can implement a 'compose' dialog, that
1. Option [params ] Compose_Button
2. When the compose button is pressed, dialog 'compose
listings/hyperref/whatever options' is triggered.
3. This dialog has all the validation faciliti
Here is a question for you: Do you want to display true, embedded
filename, or the may-not-exist external filename in the graphics
dialog? The attached patch does the former, but in a ugly way:
1. call updateDialog("graphics"); in setEmbed().
LFUN_INSET_DIALOG_UPDATE is triggered as expected.
2.
> We call it consistent behaviour. ;-)
>
> Note that the problem happens as well for other packages. Again it would be
> nice to have a general solution. The point is not to look prettier but to
> have the same look and feel everywhere, the principle of least surprise. (not
> sure if this is th
Bo Peng wrote:
LFUNs can accept as many parameters as you like and, in principle, in
whatever form you like. You just have to parse it.
So I guess I can use
LFUN_EMBEDDED_FILES embed file
LFUN_EMBEDDED_FILES add file
etc..
I don't see why not, in principle.
rh
--
==
Jean-Marc Lasgouttes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]>
> writes:
>
>> I don't think it's possible unfortunately, for the reasons in my other
>> post. We could have a O(1) RandomAccessList::getIterator(int pos) but
>> it's obviously not so cool ;-) And it doesn't work for advancing a
On Thursday 13 September 2007 16:32:11 Bo Peng wrote:
> So you guys are willing to remove validation and allow the input of
> arbitrary (wrong) parameters, just to make the dialog look prettier?
We call it consistent behaviour. ;-)
Note that the problem happens as well for other packages. Aga
> LFUNs can accept as many parameters as you like and, in principle, in
> whatever form you like. You just have to parse it.
So I guess I can use
LFUN_EMBEDDED_FILES embed file
LFUN_EMBEDDED_FILES add file
etc..
Bo
Bo Peng wrote:
You are right, but the problem is that there are two many opearations:
add file, extract file, embed file, dis-embed file, ...
How many exactly? Which of these could be useful from the lyx-server?
If LFUN can only accept one parameter, then
LFUN_EMBED_FILE file
LFUN
> > i would prefer a simple lineedit as with the document class options
> > and would expect people who use this functionality to read the
> > listings documentation.
> >
> > so i do not see the urgency of validating the input and duplicating
> > the documentation in a separate hints window. we don
> > You are right, but the problem is that there are two many opearations:
> > add file, extract file, embed file, dis-embed file, ...
>
> How many exactly? Which of these could be useful from the lyx-server?
If LFUN can only accept one parameter, then
LFUN_EMBED_FILE file
LFUN_UN_EMBED_FILE file
"Leuven, E." <[EMAIL PROTECTED]> writes:
> i would prefer a simple lineedit as with the document class options
> and would expect people who use this functionality to read the
> listings documentation.
>
> so i do not see the urgency of validating the input and duplicating
> the documentation in a
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> Makes me wonder: isn't embedding something we would like to do with an
>> lfun (which would take care of the dirty work)?
>
> You are right, but the problem is that there are two many opearations:
> add file, extract file, embed file, dis-embed file, ...
H
i would prefer a simple lineedit as with the document class options and would
expect people who use this functionality to read the listings documentation.
so i do not see the urgency of validating the input and duplicating the
documentation in a separate hints window. we don't do that with the d
On Tue, 11 Sep 2007 18:18:05 +0300
Martin Vermeer <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Sep 2007 10:50:56 +0300
> Martin Vermeer <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 11 Sep 2007 08:15:11 +0300
> > Martin Vermeer <[EMAIL PROTECTED]> wrote:
> >
> > > On Mon, Sep 10, 2007 at 10:42:32PM +0200,
> Makes me wonder: isn't embedding something we would like to do with an
> lfun (which would take care of the dirty work)?
You are right, but the problem is that there are two many opearations:
add file, extract file, embed file, dis-embed file, ...
> What happens when the document is read-only?
> now there is a big textedit with an ugly "documentation" field next to it and
> that i don't like so much:
If you can think of a better-looking alternative to display hints and
error messages, I will be quite happy to change that. (I do not like
that very much either)
Bo
Hi all,
the attached patch adds the LFUN_MASTER_PREVIEW
command ("master-preview"), triggered through the
C-M-t binding (with the "ps" argument). When run from
a child document, this command shows a preview built
from the master buffer. If a master is not found, it
previews the current buffer.
I
Helge Hafting <[EMAIL PROTECTED]> writes:
> Edwin Leuven wrote:
>> Bo Peng wrote:
>>> But there is no way to GUI'ify all 163 listings parameters.
>>
>> support the important ones and if people want to set the others they
>> can use the preamble?
> The problem is, you either support things through
Helge Hafting wrote:
> The problem is, you either support things through the
> preamble or some dialog, but not both.
let me guess, the law of hafting?
> If you use the listing support, where in the preamble would
> you put an additional option?
in the case of the listings package i had the impr
Edwin Leuven wrote:
Bo Peng wrote:
But there is no way to GUI'ify all 163 listings parameters.
support the important ones and if people want to set the others they
can use the preamble?
The problem is, you either support things through the
preamble or some dialog, but not both.
If you use th
Roger Mc Murtrie <[EMAIL PROTECTED]> writes:
> In the /lib/doc/Makefile, I removed the space after biblio in
> esbibliodocdir = $(pkgdatadir)/doc/es/biblio
> make install then performed successfully producing a working 1.5.2svn
Thansk for the report. I removed this space.
JMarc
"Leuven, E." <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> But it is difficult to have a good loking UI in this case, where
>> auto-generating does not show.
>
> i guess it could look like the property editor in qt's designer
Where is that? I am not very fluent with this program...
Jean-Marc Lasgouttes wrote:
> But it is difficult to have a good loking UI in this case, where
> auto-generating does not show.
i guess it could look like the property editor in qt's designer
that would be fine with me though (and things would also have a consistent look
'n feel)...
Edwin Leuven <[EMAIL PROTECTED]> writes:
>
> it would be nice to have package definitions in modules from which we
> could auto-generate a properties dialogs, both for the package and the
> environments it defines...
>
But it is difficult to have a good loking UI in this case, where
auto-genera
[EMAIL PROTECTED] writes:
> Author: bpeng
> Date: Thu Sep 13 06:45:49 2007
> New Revision: 20253
>
> URL: http://www.lyx.org/trac/changeset/20253
> Log:
> Embedding: mark buffer dirty after changing embedding status
Makes me wonder: isn't embedding something we would like to do with an
lfun (whic
Bo Peng wrote:
But there is no way to GUI'ify all 163 listings parameters.
support the important ones and if people want to set the others they can
use the preamble?
it would be nice to have package definitions in modules from which we
could auto-generate a properties dialogs, both for the
75 matches
Mail list logo
