Re: Completion, cell-forward and the Tab key

[Jürgen Spitzmüller]

Stefan Schimanski wrote:
 What is e.g. OpenOffice doing?

You have to use the return key to accept a completion. Not a very good 
solution IMHO.

Jürgen

Re: Horizontal space inset

[Jürgen Spitzmüller]

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 spacing, so that he
 knows that this could also be a vertical space in some circumstances,
 whereas a non-expert user would understand that this is something special,
 even if he doesn't know in what respect. It is a pity that a tool-tip
 cannot be attached to the combobox entries...

We try to avoid LaTeXisms in the GUI, and I think this hint is too covert. 
I also think terms like qquad should be replaced by double quad.

What about the attached?

Jürgen
Index: lib/ui/stdcontext.inc
===
--- lib/ui/stdcontext.inc	(Revision 24072)
+++ lib/ui/stdcontext.inc	(Arbeitskopie)
@@ -149,11 +149,11 @@
 		Item Interword Space|w next-inset-modify space \space{}
 		Item Protected Space|o next-inset-modify space ~
 		Item Thin Space|T next-inset-modify space \thinspace{}
+		Item Negative Thin Space|N next-inset-modify space \negthinspace{}
+		Item Half Quad Space (Enskip)|k next-inset-modify space \enskip{}
+		Item Protected Half Quad Space (Enspace)|E next-inset-modify space \enspace{}
 		Item Quad Space|Q next-inset-modify space \quad{}
-		Item QQuad Space|u next-inset-modify space \qquad{}
-		Item Enspace|E next-inset-modify space \enspace{}
-		Item Enskip|k next-inset-modify space \enskip{}
-		Item Negative Thin Space|N next-inset-modify space \negthinspace{}
+		Item Double Quad Space|u next-inset-modify space \qquad{}
 		Item Horizontal Fill|F next-inset-modify space \hfill{}
 		Item Protected Horizontal Fill|i next-inset-modify space \hspace*{\fill}
 		Item Horizontal Fill (Dots)|D next-inset-modify space \dotfill{}
Index: src/frontends/qt4/ui/HSpaceUi.ui
===
--- src/frontends/qt4/ui/HSpaceUi.ui	(Revision 24072)
+++ src/frontends/qt4/ui/HSpaceUi.ui	(Arbeitskopie)
@@ -76,7 +76,7 @@
  /item
  item
   property name=text 
-   stringEnspace (0.5 em)/string
+   stringHalf Quad (0.5 em)/string
   /property
  /item
  item
@@ -86,7 +86,7 @@
  /item
  item
   property name=text 
-   stringQQuad (2 em)/string
+   stringDouble Quad (2 em)/string
   /property
  /item
  item
Index: src/frontends/qt4/GuiHSpace.cpp
===
--- src/frontends/qt4/GuiHSpace.cpp	(Revision 24072)
+++ src/frontends/qt4/GuiHSpace.cpp	(Arbeitskopie)
@@ -96,6 +96,12 @@
 		selection == 0 || selection == 3  ||
 		(selection == 6  pattern == 0) || selection == 7;
 	keepCB-setEnabled(enable_keep);
+	if (selection == 3)
+		keepCB-setToolTip(qt_(Insert the spacing even after a line break.\n
+   Note that a protected Half Quad will be turned into\n
+   a vertical space if used at the beginning of a paragraph!));
+	else
+		keepCB-setToolTip(qt_(Insert the spacing even after a line break));
 	changed();
 }
 

Re: New site

[christian . ridderstrom]

On Tue, 1 Apr 2008, Jean-Marc Lasgouttes wrote:


Le 31 mars 08 à 23:27, [EMAIL PROTECTED] a écrit :
Hmm... I looked at the conf.file, do you happen to know why is there a '?' 
in the regexp?


AliasMatch ^/test/([?A-Z].*) /home/lyx/www/www-user/test/index.php/Main
/$1

For all I know, the '?' is needed, but I'd like to check if you have any 
idea.


No idea.


I think I know why now... one option to removing Main/ from the URI was to 
instead use something like:


www.lyx.org/test/?n=HomePage

where the '?' is the first thin in the URI. We can just leave it as it is.

/Christia

--
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: [devel-list] Re: New LyX website

[christian . ridderstrom]

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.org is... substantial... :-)

/C

--
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: [devel-list] Re: New LyX website

[Pavel Sanda]

 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

Re: How to Implement Transparent Unbundling

[Jean-Marc Lasgouttes]

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 your mentor, co-authors,
 reviewers, they only need to view it, or do minor editing, so they do
 not have to unpack your file. 
 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.

JMarc

[experimental PATCH] using qmake to detect Qt

[Jean-Marc Lasgouttes]

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 is that I can 

1/ build LyX on mandriva 2007.1+Qt 4.2
2/ build LyX on OSX 10.4+Qt 4.3 installed as a bundle (straight from
trolltech's site)

Remaining problems are

- requires autoconf 2.60 (easy to fix)

- does not do a separate check for QtCore only. I'll fix it if it is
  really needed not to link against QtGui (shouldn't this be a no-op
  for stuff like tex2lyx?)

- has no way to force linking against static libs (useful for OS X?)


Making this work should be as easy as

./configure --with-qt=/path/to/qt4/dir

The --with-qt is only needed if the right qmake is not on your path (I
did not need it on osx)

I have no idea whether this works on windows/mingw or windows/cygwin,
but I'd be interested to learn about it.

The general idea is that I want to avoid working further on that if it
proves to be a dead-end.

JMarc

PS: on a related note, shall we try to switch to libtool 2.2 for 1.6?

svndiff

Index: src/frontends/qt4/Makefile.am
===
--- src/frontends/qt4/Makefile.am	(revision 24081)
+++ src/frontends/qt4/Makefile.am	(working copy)
@@ -8,15 +8,15 @@ CLEANFILES += $(BUILT_SOURCES)
 
 #  Qt stuff  #
 # Use _() for localization instead of tr() or trUtf8()
-UIC4FLAGS=-tr lyx::qt_
+UICFLAGS=-tr lyx::qt_
 
 ui_%.h: ui/%.ui
-	$(UIC4) $(UIC4FLAGS) $ -o $@
+	$(UIC) $(UICFLAGS) $ -o $@
 
 MOCEDFILES = $(MOCHEADER:%.h=%_moc.cpp)
 
 %_moc.cpp: %.h
-	$(MOC4) -o $@ $
+	$(MOC) -o $@ $
 
 Resources.qrc: Makefile
 	echo !DOCTYPE RCCRCC version='1.0'qresource  $@
@@ -26,7 +26,7 @@ Resources.qrc: Makefile
 	echo /qresource/RCC  $@
 
 Resources.cpp: Resources.qrc
-	$(RCC4) $ -name Resources -o $@
+	$(RCC) $ -name Resources -o $@
 
 
 #  LIBRARIES  #
@@ -34,15 +34,15 @@ Resources.cpp: Resources.qrc
 noinst_LTLIBRARIES = liblyxqt4.la
 
 liblyxqt4_la_DEPENDENCIES = $(MOCEDFILES)
-liblyxqt4_la_LDFLAGS = $(QT4_LDFLAGS)
-liblyxqt4_la_LIBADD = $(QT4_LIB) 
+liblyxqt4_la_LDFLAGS = $(QT_LDFLAGS)
+liblyxqt4_la_LIBADD = $(QT_LIBS)
 
 AM_CPPFLAGS += \
-	$(QT4_CPPFLAGS) \
+	$(QT_CPPFLAGS) \
 	-I$(top_srcdir)/src \
 	-I$(top_srcdir)/src/frontends \
 	-I$(top_srcdir)/images \
-	$(QT4_INCLUDES) $(BOOST_INCLUDES)
+	$(BOOST_INCLUDES)
 
 SOURCEFILES = \
 	ButtonPolicy.cpp \
Index: src/Makefile.am
===
--- src/Makefile.am	(revision 24081)
+++ src/Makefile.am	(working copy)
@@ -23,6 +23,9 @@ OTHERLIBS = $(BOOST_LIBS) $(INTLLIBS) $(
 noinst_LTLIBRARIES = liblyxcore.la
 bin_PROGRAMS = lyx
 
+lyx_CXXFLAGS = $(QT_CXXFLAGS) $(AM_CXXFLAGS)
+lyx_CPPFLAGS = $(QT_CPPFLAGS) $(AM_CPPFLAGS)
+lyx_LDFLAGS  = $(QT_LDFLAGS) $(LDFLAGS)
 lyx_LDADD = \
 	liblyxcore.la \
 	liblyxmathed.la \
@@ -32,7 +35,7 @@ lyx_LDADD = \
 	liblyxgraphics.la \
 	support/liblyxsupport.la \
 	$(OTHERLIBS) \
-	$(QT4_LIB) 
+	$(QT_LIBS) 
 
 if LYX_WIN_RESOURCE
 .rc.o:
Index: src/support/Makefile.am
===
--- src/support/Makefile.am	(revision 24081)
+++ src/support/Makefile.am	(working copy)
@@ -7,8 +7,7 @@ EXTRA_DIST = pch.h \
 
 noinst_LTLIBRARIES = liblyxsupport.la
 
-liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(QT4_CORE_LIB) $(BOOST_SIGNALS)
-liblyxsupport_la_LDFLAGS = $(QT4_CORE_LDFLAGS)
+liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(BOOST_SIGNALS)
 
 BUILT_SOURCES = $(PCH_FILE)
 
@@ -23,7 +22,7 @@ CLEANFILES += $(MOCEDFILES)
 BUILT_SOURCES += $(MOCEDFILES)
 
 %_moc.cpp: %.h
-	$(MOC4) -o $@ $
+	$(MOC) -o $@ $
 
 liblyxsupport_la_DEPENDENCIES = $(MOCEDFILES)
 
@@ -31,7 +30,7 @@ liblyxsupport_la_DEPENDENCIES = $(MOCEDF
 ##
 
 AM_CPPFLAGS += $(PCH_FLAGS) -I$(srcdir)/.. $(BOOST_INCLUDES)
-AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES) -I$(srcdir)/minizip
+AM_CPPFLAGS += $(QT_CPPFLAGS) -I$(srcdir)/minizip
 
 # force the use of C++ compiler for minizip/*.c files, because
 # gcc can not go through the included boost files.
@@ -148,8 +147,8 @@ check_PROGRAMS = \
 	check_lstrings
 
 check_convert_LDADD = liblyxsupport.la  \
-	$(BOOST_LIBS) $(QT4_CORE_LIB)
-check_convert_LDFLAGS = $(QT4_CORE_LDFLAGS)
+	$(BOOST_LIBS) $(QT_CORE_LIBS)
+check_convert_LDFLAGS = $(QT_CORE_LDFLAGS)
 check_convert_SOURCES = \
 	tests/check_convert.cpp \
 	tests/boost.cpp
@@ -159,8 +158,8 @@ check_filetools_SOURCES = \
 	tests/check_filetools.cpp \
 	tests/boost.cpp
 
-check_lstrings_LDADD = liblyxsupport.la $(BOOST_LIBS) $(QT4_CORE_LIB)
-check_lstrings_LDFLAGS = $(QT4_CORE_LDFLAGS)
+check_lstrings_LDADD = liblyxsupport.la $(BOOST_LIBS) $(QT_CORE_LIB)

Re: drawing of selection

[José Matos]

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, that includes of course the chapter numbers, the items bullets, 
etc...

Without it we have an irregular selection and it is not pleasing, at least to 
my eyes.

-- 
José Abílio

Re: How to Implement Transparent Unbundling

[Bo Peng]

   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 questions raised on that thread if
you are going to endorse Richard's proposal. Briefly speaking,
Ricahrd's proposal first exaggerated the problem by forcing the
unbundling of .lyx file (whereas I argue here that unbundling is not
always needed), and proposed a radical solution that copies all
embedded files to a directory under the document directory. This leads
to ugliness such as cleanup of an embed directory, and difficulties in
opening a file under a readonly directory. 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.

Cheers,
Bo

Re: [devel-list] Re: New LyX website

[christian . ridderstrom]

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   http://www.md.kth.se/~chr

MiKTeK Problem Report: Permission denied

[Ed Sykes]

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 recently updated MikTeX and am running the latest version of LyX on 
Windows XP Professional.

Any suggestions are deeply appreciated 


Thanks so much,

Cheers,
Ed Sykes
Sheridan College,
Canada 

Re: How to Implement Transparent Unbundling [was Re: EmbeddedFile Feature]

[rgheck]

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.



Then we need to educate such users the problem, and solutions.

  
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.


rh

RE: drawing of selection

[Leuven, E.]

 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/TextMetrics.cpp	(revision 24087)
+++ src/TextMetrics.cpp	(working copy)
@@ -2025,8 +2025,8 @@
 		if (row_selection) {
 			DocIterator beg = bv_-cursor().selectionBegin();
 			DocIterator end = bv_-cursor().selectionEnd();
-			bool const beg_margin = beg.pit()  pit  i == 0;
-			bool const end_margin = end.pit()  pit  i == nrows - 1;
+			bool const beg_margin = beg.pit()  pit || row.sel_beg == cur.textRow().pos();
+			bool const end_margin = end.pit()  pit || row.sel_end == cur.textRow().endpos();
 			beg.pit() = pit;
 			beg.pos() = row.sel_beg;
 			end.pit() = pit;
@@ -2082,17 +2082,23 @@
 
 	// draw the margins
 	if (drawOnBegMargin) {
-		if (text_-isRTL(buffer, beg.paragraph()))
-			pi.pain.fillRectangle(x + x1, y1, width() - x1, y2 - y1, Color_selection);
-		else
-			pi.pain.fillRectangle(x, y1, x1, y2 - y1, Color_selection);
+		if (text_-isRTL(buffer, beg.paragraph())) {
+			int lm = bv_-leftMargin();
+			pi.pain.fillRectangle(x + x1, y1, width() - lm - x1, y2 - y1, Color_selection);
+		} else {
+			int rm = bv_-rightMargin();
+			pi.pain.fillRectangle(rm, y1, x1 - rm, y2 - y1, Color_selection);
+		}
 	}
 
 	if (drawOnEndMargin) {
-		if (text_-isRTL(buffer, beg.paragraph()))
-			pi.pain.fillRectangle(x, y1, x2, y2 - y1, Color_selection);
-		else
-			pi.pain.fillRectangle(x + x2, y1, width() - x2, y2 - y1, Color_selection);
+		if (text_-isRTL(buffer, beg.paragraph())) {
+			int rm = bv_-rightMargin();
+			pi.pain.fillRectangle(x + rm, y1, x2 - rm, y2 - y1, Color_selection);
+		} else {
+			int lm = bv_-leftMargin();
+			pi.pain.fillRectangle(x + x2, y1, width() - lm - x2, y2 - y1, Color_selection);
+		}
 	}
 
 	// if we are on a boundary from the beginning, it's probably

Re: How to Implement Transparent Unbundling [was Re: EmbeddedFile Feature]

[Bo Peng]

  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 the same file
on different systems due to OS differences. This will be a much worse
problem if users would like to do this by hand (e.g. copy all files
from one system to another and try to make a document compile), and
our feature is really helpful here.

We can of course, disable the embedding of such files, as you
suggested, and as I can also easily do; or allow users to do this, but
give appropriate warnings and solutions (such as helping users move
them to the document directory). Given the benefits of sharing such
files, and the chance this happens, and the easiness of a solution, I
prefer the later.

Cheers,
Bo

RE: drawing of selection

[Leuven, E.]

 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...

Re: This old bug in nested Noweb files and External Template solution

[José Matos]

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 unknowingly created a new bug on the same lines here:

 http://bugzilla.lyx.org/show_bug.cgi?id=4655

 The problem is that one cannot write a Noweb book in parts that are
 included in a main book file because child documents do not get
 weaved.

 If we don't find a work around, I think you should seriouly consider
 removing Book (Noweb) from the document styles.

 My idea is to work around this by treating the noweb lyx file as
 External Material.  I'm trying to write the external template, but I
 don't understand the format of it. I have been hoping that, as soon as
 I can make the question specific enough, then one of you will say ah,
 that's easy, do this...  So here's from ~/.lyx/external_template,
 where I'm trying to use the XFig example to handle the lyx noweb
 document.  What do I put in that will cause LyX to notice the lyx file
 is supposed to be gobbled up as Noweb, dumped out to LaTeX, processed
 by the Converter from the LyX config.

I guess that this problem could be solved adding the original document 
location to the kpsepath path, no? I have similar problems when using a logo 
in beamer preamble that would be solved this way.

I remember have seen some remark from Jean-Marc about a similar issue but I am 
not sure they are related.
-- 
José Abílio

Re: drawing of selection

[José Matos]

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

Re: drawing of selection

[Jürgen Spitzmüller]

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

Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[rgheck]

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 dispute
 now. But it matters, it seems to me, for the other reasons I've
 mentioned, viz: If the embedding stuff changes, I want the change only
 to affect things that have to do with embedding.



snip Your example /snip

I can not believe that we spent so much time on this small issue. Of
course when we use another reprentation to params, we would better be
able to reproduce params. The meta_ patch will do exactly this, and if
someone would like to use a EmbeddedFileMap, the same issue should be
considered. 

  
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.


And you're missing the point of the example. If you use an 
EmbeddedFileMap, you can't recover the order of the parameters. That's 
why the LaTeX output would change. Of course, you could add some 
auxiliary data structure that recorded this information, but that would 
be ugly. And why should you need to do that? There's nothing about what 
the EmbeddedFileList represents that has anything to do with order.


The example wasn't idle. Using a map in InsetBibtex is totally natural: 
a map from parameter representations, like biblio, to the EmbeddedFile 
objects that represent them; then we get easy lookup of one from the 
other. There's no reason to use an EmbeddedFileList. We don't use any of 
the methods of EmbeddedFileList except the ones that we get from 
std::vector (and the findFile() method, which ought just to be a wrapper 
around find_if). So we're not using the EmbeddedFileList at all, and we 
might as well just use vectorEmbeddedFile. But if so, why can't we use 
a mapdocstring, EmbeddedFile? (This also has non-trivial advantages 
back in Buffer.cpp.) But we can't do that if we're iterating over the 
vector to access the parameters. So we shouldn't iterate over the 
vector. In short, and as I've said before: The basic operations of the 
inset should not depend upon this kind of stuff.


I don't see why any of that should be remotely controversial. It's 
Programming 101 stuff.


Can someone step in here please and resolve this? If I'm wrong, please 
feel free to tell me.


Richard

Re: How to Implement Transparent Unbundling

[rgheck]

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 hard to
justify.



  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 but in the session (local) stuff. 
Absolute file paths could be stored locally in the session, but they should 
never be in the (portable) lyx file.


  

+1

rh

RE: drawing of selection

[Leuven, E.]

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

Re: How to Implement Transparent Unbundling

[José Matos]

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.

  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 but in the session (local) stuff. 
Absolute file paths could be stored locally in the session, but they should 
never be in the (portable) lyx file.

 Cheers,
 Bo

-- 
José Abílio

Re: How to Implement Transparent Unbundling

[rgheck]

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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Bo Peng]

  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 is totally natural:

Come on, if you use a map, you open a file with embedded files and
save it. The embedded files may be saved in a different order and
result in a totally different .lyx file. It is lucky that you are not
supposed to svn an embedded .lyx file.

  Can someone step in here please and resolve this? If I'm wrong, please
  feel free to tell me.

Please.

Bo

Re: How to Implement Transparent Unbundling

[Bo Peng]

   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 but in the session (local) stuff.
  Absolute file paths could be stored locally in the session, but they should
  never be in the (portable) lyx file.

The absolute-path files *are* in a temporary directory as long as you
do not extract them. I do not know what you meant by  absolute file
paths could not be stored because this has been what lyx is doing for
ages.

Bo

Re: How to Implement Transparent Unbundling

[Bo Peng]

  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 systems.

Bo

Re: How to Implement Transparent Unbundling

[Bo Peng]

  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 bundled mode,
they are supposed to be copied to a directory under the document
directory, but what about unbundled mode? The core design of the
current approach is that bundle and unbundle are totally reversible,
without loss of any information.

Cheers,
Bo

Re: Horizontal space inset

[Andre Poenitz]

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 spacing, so that he
  knows that this could also be a vertical space in some circumstances,
  whereas a non-expert user would understand that this is something special,
  even if he doesn't know in what respect. It is a pity that a tool-tip
  cannot be attached to the combobox entries...
 
 We try to avoid LaTeXisms in the GUI, and I think this hint is too covert. 
 I also think terms like qquad should be replaced by double quad.

I think the LaTeX names should be available _somewhere_ nevertheless,
e.g. in the tooltips...

Andre'

Re: Horizontal space inset

[Enrico Forestieri]

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 spacing, so that he
  knows that this could also be a vertical space in some circumstances,
  whereas a non-expert user would understand that this is something special,
  even if he doesn't know in what respect. It is a pity that a tool-tip
  cannot be attached to the combobox entries...
 
 We try to avoid LaTeXisms in the GUI, and I think this hint is too covert. 

Okay.

 I also think terms like qquad should be replaced by double quad.

Agreed.

 What about the attached?

I think it will do. After all, placing an \enspace at the beginning
of a paragraph is not so likely given that TeX does not remove spaces
at the beginning and end of a paragraph, and thus nobody should need
to check protect. And even if they do, they are warned by the tool tip
(good idea, btw).

-- 
Enrico

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Jean-Marc Lasgouttes]

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 go seemlessly into
an svn archive. I understand this may not be doable immediately, but
it is something that would make much sense.

JMarc

Re: How to Implement Transparent Unbundling

[Jean-Marc Lasgouttes]

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 example.

 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...

 Briefly speaking, Ricahrd's proposal first exaggerated the problem
 by forcing the unbundling of .lyx file (whereas I argue here that
 unbundling is not always needed), and proposed a radical solution
 that copies all embedded files to a directory under the document
 directory. This leads to ugliness such as cleanup of an embed
 directory, and difficulties in opening a file under a readonly
 directory. 

As I stated somewhere else, I'd like a solution where embedding is
separated from compression. Embedding would be 'document as a
directory), while compression would be just compression (of single
file or directory). 

 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.

Concerning out-of-tree files, deciding that they should not be bundled
is IMO the cleanest and simplest solution. This gives us a clear model
to work with.

Note that these are completely uninformed thoughts (I admit I have not
read the whole thread).

JMarc

Re: How to Implement Transparent Unbundling

[Bo Peng]

   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 because of this, without thinking of all the drawbacks.

  Concerning out-of-tree files, deciding that they should not be bundled
  is IMO the cleanest and simplest solution. This gives us a clear model
  to work with.

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.

Cheers,
Bo

Re: drawing of selection

[Andre Poenitz]

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 as a result:
 
 http://leuven.economists.nl/lyx/sel2.png
 
 which i think is much nicer
 
 opinions/suggestions?

I think the new screenshot is much nicer.

Have you checked more complicated cases of nesting?

Andre'

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Bo Peng]

  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 something that would make much sense.

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.

We are not even at alpha stage so this can be changed.

Bo

Fix: File selection dialog on Windows

[Joost Verburg]

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
===
--- src/support/FileFilterList.cpp  (revision 24088)
+++ src/support/FileFilterList.cpp  (working copy)
@@ -99,7 +99,12 @@
// FIXME UNICODE
string const filter = to_utf8(qt_style_filter)
+ (qt_style_filter.empty() ? string() : ;;)
-   + to_utf8(_(All files (*)));
+   + to_utf8(_(All Files ))
+#if defined(_WIN32)
+   + ((*.*));
+#else
+   + ((*));
+#endif
 
// Split data such as TeX documents (*.tex);;LyX Documents (*.lyx)
// into individual filters.

Re: How to Implement Transparent Unbundling

[José Matos]

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 one question, out of curiosity, do you know of any other program that does 
what you are proposing (working with external files)?

Referring to the option I would like to wait before moving into that, that 
should be our last option.

 Cheers,
 Bo

-- 
José Abílio

Re: Fix: File selection dialog on Windows

[José Matos]

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 shows up?

-- 
José Abílio

Re: Fix: File selection dialog on Windows

[Joost Verburg]

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 where this shows up?


Yes.

Joost

Re: How to Implement Transparent Unbundling

[Bo Peng]

  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 options to edit them. In the latex world, all files are
external. The design of our embedding feature tries to please users in
both worlds. One can work completely in one style, or in another, and
the conversion between them will not loss any information.

Because of this uniqueness, I do not know any program that tries to
embed external files and unbundle them to another file system.

Note that, if we disallow embedding of such files, an embed file may
fail to compile on another system. My goal was to allow complete
bundling of external files and the status quo is that everyone can
make such a file easily, which can be viewed and compiled on another
system, but unbundling can be troublesome.

Cheers,
Bo

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[rgheck]

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 embedded files remains the same after minor changes.


rh

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[rgheck]

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 forbid I might have had trouble 
understanding your code.



 The example wasn't idle. Using a map in InsetBibtex is totally natural:



Come on, if you use a map, you open a file with embedded files and
save it. The embedded files may be saved in a different order and
result in a totally different .lyx file. It is lucky that you are not
supposed to svn an embedded .lyx file.

  
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.


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 produce 
the map from an EmbeddedFileList, but the much easier thing to do is to 
have InsetBibtex::bibfiles_ itself be such a map, and I'll just return a 
const reference to it---just like we do now. If your implementation of 
the embedding feature prohibits me from doing this, then that, it seems 
to me, is a big problem. Do you think it does? If not, is it OK with you 
if I make this change?


And second: If the order of the embedded files in the LyX file matters, 
then you'd better check the code, because it simply does not guarantee 
that the order will not change after minor edits. It is also false that 
it might change after an open/save sequence, unless you've moved 
systems. But in that case, it may change anyway.


rh

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Bo Peng]

  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
vectorEmbeddedFile to mapdocstring, EmbeddedFile. This will of
course change buffer level embedded file list.

  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 produce
  the map from an EmbeddedFileList, but the much easier thing to do is to
  have InsetBibtex::bibfiles_ itself be such a map, and I'll just return a
  const reference to it---just like we do now. If your implementation of
  the embedding feature prohibits me from doing this, then that, it seems
  to me, is a big problem. Do you think it does? If not, is it OK with you
  if I make this change?

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. A complication here is that registerEmbeddedFile has to ask
params for the order of the files this is in the end not so good.

  And second: If the order of the embedded files in the LyX file matters,
  then you'd better check the code, because it simply does not guarantee
  that the order will not change after minor edits. It is also false that
  it might change after an open/save sequence, unless you've moved
  systems. But in that case, it may change anyway.

The current code will not change the order of embedded files, unless
you use a map to return bib files without order from InsetBibtex.

Bo

Docked widgets

[Pavel Sanda]

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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[rgheck]

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 produce
 the map from an EmbeddedFileList, but the much easier thing to do is to
 have InsetBibtex::bibfiles_ itself be such a map, and I'll just return a
 const reference to it---just like we do now. If your implementation of
 the embedding feature prohibits me from doing this, then that, it seems
 to me, is a big problem. Do you think it does? If not, is it OK with you
 if I make this change?



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_ but over params, and 
we (quickly) look up the embedded file info in the map. We do it this 
way because we should keep the order. This requires that bibfiles_ and 
the params be in sync, but they have to be kept in sync anyway. We 
resolved that issue a long time ago.



A complication here is that registerEmbeddedFile has to ask
params for the order of the files this is in the end not so good.

  
Why do they need to be saved in the same order as the parameters? If the 
concern is that the order should stay the same from save to save, then 
this is a non-issue: It will, because the order of the map will not 
change unless the keys do. This will be so even across systems and 
platforms.

 And second: If the order of the embedded files in the LyX file matters,
 then you'd better check the code, because it simply does not guarantee
 that the order will not change after minor edits. It is also false that
 it might change after an open/save sequence, unless you've moved
 systems. But in that case, it may change anyway.



The current code will not change the order of embedded files, unless
you use a map to return bib files without order from InsetBibtex.

  
Yes, it will. Not just from open/save---I didn't say that---but it will 
change the order, say, if you change the order of the files in the 
bibliography inset, or if you move one graphic in front of another. This 
is because of how the files are registered. If it matters that the order 
stay the same, then you need to sort the list in 
EmbeddedFileList::writeFile(), or probably better in update(). But if 
you do that, then it doesn't matter what the reported order is, and it 
doesn't matter if we use a map.


rh

LyX site - left to do?

[christian . ridderstrom]

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/index.php/Main.NewWebsiteDevelopment

Anyway, I've used the toc to and restructured it... we can simply colour 
code the issues that we feel must be done before a release. Please have a 
look, so far I haven't really added any.


I've also put my name down for some of the issues that I'll look at.

/Christian
--
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: Docked widgets

[Andre Poenitz]

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 the main app? That's a feature.
 
 these are intended behaviour or bug? or not easy to implement?

Probably a change of one line (use no parent widget at dock widget
construction)

Andre'

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Bo Peng]

   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_ but over params, and
  we (quickly) look up the embedded file info in the map. We do it this
  way because we should keep the order. This requires that bibfiles_ and
  the params be in sync, but they have to be kept in sync anyway. We
  resolved that issue a long time ago.

OK. We have agree upon at least a few things,

1. EmbeddedFileList (or map) has to be in sync with params, has to be
valid, so it can not be separated from params. In this sense, who
should be the core information (so that another one does not have to
be updated) is a false problem.

2. EmbeddedFile needs this meta_, and your solution of mapmeta_,
EmbeddedFile is acceptable to me. However, meta_ is a solution to a
general problem, that may be needed anyway in, for example,
InsetGraphics. I am not against the idea that you fix InsetBibtex now,
and fix InsetGraphic later.

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? 2. When we are in need
some information, from whom should we ask for it? I say they are minor
problems because if params and EmbeddedFiles are in sync, it does not
really matter, so let use just use the easier method. I tend to use
EmbeddedFileList because it is structured so it is easier to handle.

   The current code will not change the order of embedded files, unless
   you use a map to return bib files without order from InsetBibtex.
  
  
  Yes, it will. Not just from open/save---I didn't say that---but it will
  change the order, say, if you change the order of the files in the
  bibliography inset, or if you move one graphic in front of another. This
  is because of how the files are registered. If it matters that the order
  stay the same, then you need to sort the list in
  EmbeddedFileList::writeFile(), or probably better in update(). But if
  you do that, then it doesn't matter what the reported order is, and it
  doesn't matter if we use a map.

I think sorting the embedded files before writing is a great idea. At
least it no longer matters if you use map..., embeddedfile in
InsetBibtex::registerFile.

Cheers,
Bo

Re: LyX site - left to do?

[Pavel Sanda]

 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

Re: LyX site - left to do?

[Joost Verburg]

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://www.lyx.org/test/RecentChanges

Joost

Map Behavior

[rgheck]

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
Professor of Philosophy
Brown University

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[rgheck]

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 bibfiles_ but over params, and
 we (quickly) look up the embedded file info in the map. We do it this
 way because we should keep the order. This requires that bibfiles_ and
 the params be in sync, but they have to be kept in sync anyway. We
 resolved that issue a long time ago.



OK. We have agree upon at least a few things,

1. EmbeddedFileList (or map) has to be in sync with params, has to be
valid, so it can not be separated from params. In this sense, who
should be the core information (so that another one does not have to
be updated) is a false problem.

2. EmbeddedFile needs this meta_, and your solution of mapmeta_,
EmbeddedFile is acceptable to me. However, meta_ is a solution to a
general problem, that may be needed anyway in, for example,
InsetGraphics. I am not against the idea that you fix InsetBibtex now,
and fix InsetGraphic later.

  
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 finished.



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.



2. When we are in need
some information, from whom should we ask for it? I say they are minor
problems because if params and EmbeddedFiles are in sync, it does not
really matter, so let use just use the easier method. 

  
Iterating over params is more sensible, I think, if only because, if 
embedding is not enabled, you needn't consult anything else. Exactly 
what the code will look like, I don't yet know, but we'll have things like:

   string const database =
   buffer().enabled() ? consult(paramIterator-first) : 
paramIterator-first;

We'd anyway have (more or less)
   string const database =
   buffer().enabled() ? bibfilesIterator-availableFilename() : 
bibfilesIterator-metaInfo();
So it doesn't end up mattering that much, and the former makes it 
clearer exactly where the information from EmbeddedFiles is used and 
where it is not.


Anyway, it sounds as if we're well enough agreed that I can move ahead 
with this.


rh

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Bo Peng]

   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 implementation of setParam because if you set params
first, and then update EmbeddedFileList, you may be bounced back to
set params again (to disable embedding). On the other hand, if you
update EmbeddedFile first, you do not have to do this. Anyway, all
these can happen in setParam and the differences are trivial.

   2. When we are in need
   some information, from whom should we ask for it? I say they are minor
   problems because if params and EmbeddedFiles are in sync, it does not
   really matter, so let use just use the easier method.
  
  
  Iterating over params is more sensible, I think, if only because, if
  embedding is not enabled, you needn't consult anything else. Exactly
  what the code will look like, I don't yet know, but we'll have things like:
 string const database =
 buffer().enabled() ? consult(paramIterator-first) :
  paramIterator-first;
  We'd anyway have (more or less)
 string const database =
 buffer().enabled() ? bibfilesIterator-availableFilename() :
  bibfilesIterator-metaInfo();
  So it doesn't end up mattering that much, and the former makes it
  clearer exactly where the information from EmbeddedFiles is used and
  where it is not.

I will have to see your patch (or commits) to determine if I like it,
but you know I dislike parsing params again and again. :-)

Bo

Re: Map Behavior

[Andre Poenitz]

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 items. Right?

Yes.

Andre'

Re: drawing of selection

[Abdelrazak Younes]

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 this as a result:

http://leuven.economists.nl/lyx/sel2.png

which i think is much nicer

opinions/suggestions?


I think the new screenshot is much nicer.

Have you checked more complicated cases of nesting?


Yes, please check more complicated case, I remember having some trouble


Andre'

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Andre Poenitz]

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, more or less. But note that,
  when we output latex, we iterate not over bibfiles_ but over params, and
  we (quickly) look up the embedded file info in the map. We do it this
  way because we should keep the order. This requires that bibfiles_ and
  the params be in sync, but they have to be kept in sync anyway. We
  resolved that issue a long time ago.
 

 OK. We have agree upon at least a few things,

 1. EmbeddedFileList (or map) has to be in sync with params, has to be
 valid, so it can not be separated from params. In this sense, who
 should be the core information (so that another one does not have to
 be updated) is a false problem.

 2. EmbeddedFile needs this meta_, and your solution of mapmeta_,
 EmbeddedFile is acceptable to me. However, meta_ is a solution to a
 general problem, that may be needed anyway in, for example,
 InsetGraphics. I am not against the idea that you fix InsetBibtex now,
 and fix InsetGraphic later.

   
 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 finished.

Could you please elaborate on why having the InsetCommand hierarchy is
useful at all?

As far as I can tell the main benefit was to have a uniform means to
pass Parameters through the Controller layer in the Old Days. This
layer is gone now, and it feels a bit strange to pass around unrelated
pieces of data from otherwise unrelated insets in a common structure.
Wouldn't per-inset specific data with direct access from the GUI simplify
overall structure and reduce conversion costs?

[Note that I did not follow GUI development too closely then, so I might
easily miss something very important here.]

Andre'

Re: drawing of selection

[Abdelrazak Younes]

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 removes some drawing code, with this as a result:

http://leuven.economists.nl/lyx/sel2.png

which i think is much nicer

opinions/suggestions?


I think the new screenshot is much nicer.

Have you checked more complicated cases of nesting?


Yes, please check more complicated case, I remember having some trouble


... with some corner cases while rewriting the selection code.

Sorry I switched to qn azerty keyboard and it seems that some key 
combination provoked the sending :)


Abdel.
PS: By the way, I'll be off-line for another week or two.

Re: New site

[Joost Verburg]

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 pixels now but it would 
indeed be better if it was not displayed for small widths. It's not very 
easy to fix, I'll have a look at it later.


Thanks for tour consideration ;-)


It's fixed.

Joost

Re: New site

[Andre Poenitz]

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/troublesome for small
 widths.
 I understand what you mean. It's just about 20 pixels now but it would 
 indeed be better if it was not displayed for small widths. It's not very 
 easy to fix, I'll have a look at it later.
 Thanks for tour consideration ;-)

 It's fixed.

Yes.. better now. Thanks.

Andre'

InsetCommandParams

[Andre Poenitz]

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 inset that in the end achieve something pretty
similar to

void InsetMathSqrt::write(WriteStream  os) const
{
os  \\sqrt{  cell(0)  '}';
}

void Parser::parse1(InsetMathGrid  grid, unsigned flags,
const mode_type mode, const bool numbered)
{
[...]
else if (t.cs() == sqrt) { [...]
cell-push_back(MathAtom(new InsetMathSqrt));
parse(cell-back().nucleus()-cell(0), 
FLAG_ITEM, mode);
}
[...]
}

i.e. in each class derived from InsetCommand there is already more code
needed just to _interface_ the nice general code in InsetCommandParams
than an inset specific read/write implemention would take. This is
cancer that should not be allowed to grow any further.

What is, btw, LATEX_KV_REQUIRED and LATEX_KV_OPTIONAL good for?
LyX compiles fine without those?

Andre'

Re: [Cvslog] r24083 - in /lyx-devel/trunk: development/MacOSX/lyxrc.di...

[Enrico Forestieri]

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
 
 Modified:
 lyx-devel/trunk/development/MacOSX/lyxrc.dist.in
 lyx-devel/trunk/src/LyXRC.cpp
 
 Modified: lyx-devel/trunk/development/MacOSX/lyxrc.dist.in
 URL: 
 http://www.lyx.org/trac/file/lyx-devel/trunk/development/MacOSX/lyxrc.dist.in?rev=24083
 ==
 --- lyx-devel/trunk/development/MacOSX/lyxrc.dist.in (original)
 +++ lyx-devel/trunk/development/MacOSX/lyxrc.dist.in Tue Apr  1 11:18:03 2008
 @@ -27,6 +27,7 @@
  \screen_font_roman Times
  \screen_font_sans Helvetica
  \screen_font_typewriter Courier
 +\open_buffers_in_tabs false
  
  #
  # COLOR SECTION ###
 
 Modified: lyx-devel/trunk/src/LyXRC.cpp
 URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/LyXRC.cpp?rev=24083
 ==
 --- lyx-devel/trunk/src/LyXRC.cpp (original)
 +++ lyx-devel/trunk/src/LyXRC.cpp Tue Apr  1 11:18:03 2008
 @@ -295,12 +295,7 @@
   converter_cache_maxage = 6 * 30 * 24 * 3600; // 6 months
   user_name = to_utf8(support::user_name());
   user_email = to_utf8(support::user_email());
 -#ifdef __APPLE_CC__
 - open_buffers_in_tabs = false;
 -#else
   open_buffers_in_tabs = true;
 -#endif
 - use_bundled_format = false;

Did you intentionally prune this last line?

-- 
Enrico

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[rgheck]

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 finished.
  


Could you please elaborate on why having the InsetCommand hierarchy is
useful at all?

As far as I can tell the main benefit was to have a uniform means to
pass Parameters through the Controller layer in the Old Days. This
layer is gone now, and it feels a bit strange to pass around unrelated
pieces of data from otherwise unrelated insets in a common structure.
Wouldn't per-inset specific data with direct access from the GUI simplify
overall structure and reduce conversion costs?
  


Frankly, I don't know the overall structure here well enough to be sure 
exactly what the advantages or disadvantages to keeping the 
InsetCommandParams business the way it is. Mostly, I try to go on how 
Georg explained this to me some time ago, and the understanding I've 
developed since then of why he (they?) did things the way they did. In 
particular, Georg insisted that we are not to subclass 
InsetCommandParams, not unless we have a really, really good reason. 
There are times it seems it would be very natural to me to do so, but 
Georg made a strong case (I don't remember all the details) for not 
doing so, and if that's how he designed the code, then, well, I'm 
guessing there are reasons, and I'd probably find them out if I violated 
his orders.


I agree that there's something unhappy about the stringification, 
unstringification, and so on and so forth. But, as JMarc often says, we 
know we have to do that anyway---remember that the strings are in 
exactly the form they are in the .lyx file---so it's not that 
unreasonable to use the same infrastructure to pass things around. That 
said, I also agree with Abdel that we shouldn't bind ourselves to doing 
that if it makes things overly complex, and I don't really care that 
much how things are passed back and forth from the GUI. But that's 
really a separate issue from how ICP works. You can build an ICP without 
all the stringification. You just do it directly:

params.setParam(bibfiles) = whatever;
and then you can pass params itself to the inset if you like. Doing so 
has a downside, though, one that JMarc (again) is always pointing out, 
namely, that if you go via an LFUN, you get all kinds of updates, etc, 
for free; in particular, going via the dispatch mechanism gets you this. 
But then you do need a common representation of the parameters being 
passed, and a string is a pretty natural choice. (I don't even want to 
think about all the casting that would otherwise be required.) But the 
main point, really, is that this is a different issue. The conversion 
cost question is really separate from the question whether ICP is A Good 
Thing. By itself, getting rid of ICP wouldn't help you there.


Anyway, even if there were reasons to do a large scale re-write of this 
stuff, I don't see anyone doing that any time real soon. So, unless 
someone is going to do that, then, as things stand, I strongly suspect 
that there's substantial duplication of code across InsetGraphicsParams, 
InsetExternalParams, and InsetCommandParams. (There has to be.) Barring 
the massive re-write, then, the strategy I suggested seems sensible. And 
for the same reason, barring some large-scale change of direction, I'm 
reluctant to introduce InsetBibtexParams and take InsetBibtex out of the 
existing framework.


Hope that helps.

Richard

Re: InsetCommandParams

[rgheck]

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

Re: LyX site - left to do?

[Joost Verburg]

[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 we 
have right now is so much better that I see no reasons to wait.


Joost

Re: Take 2: time for alpha

[Pavel Sanda]

   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 00:53:12 CEST 2008

 -- 
 José Abílio

Re: LyX site - left to do?

[Pavel Sanda]

 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://www.lyx.org/test/RecentChanges

thanks
pavel

Re: InsetCommandParams

[rgheck]

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)  '}';
}

void Parser::parse1(InsetMathGrid  grid, unsigned flags,
const mode_type mode, const bool numbered)
{
[...]
else if (t.cs() == sqrt) { [...]
cell-push_back(MathAtom(new InsetMathSqrt));
parse(cell-back().nucleus()-cell(0), 
FLAG_ITEM, mode);

}
[...]
}

i.e. in each class derived from InsetCommand there is already more code
needed just to _interface_ the nice general code in InsetCommandParams
than an inset specific read/write implemention would take. This is
cancer that should not be allowed to grow any further.
  
Where is all this extra code in, say, InsetHyperlink? I don't see it. It 
doesn't even have its own write() or read() method. Same for InsetLabel. 
Same for more of them. There is messy interface code in InsetBibtex, 
yes. I'll give you that one. But that will be there anyway, I suspect.


Anyway, I'm not insisting upon converting InsetGraphicsParam. If the 
patch makes things worse, we shouldn't do it, obviously. I won't know 
that until I look more closely. But if it loses 200 lines of code, I 
suspect that will make you happy. ;-)


rh

Re: Docked widgets

[Pavel Sanda]

  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 it locally for me ;)
pavel

Re: LyX site - left to do?

[Pavel Sanda]

 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 now is so much better that I see no reasons to wait.


1.
- i would like to have some complete list of links in one place, i.e.
this page http://www.lyx.org/internet/. Also - two nonenglish sites should
be added - CJK and Hebrew (both are pretty contemporary ones).


2.
- i'm missing the developers corner in sidebar
i don't like the current solution, because:
 - Links for Developers section is visually lost under ToC and the naming
does not describe the aim correctly.
 - i have an impression we have 'Development' under 'Contribute' just because 
   we don't know where to put Donate section (maybe support?).
 - there are links i'm regularly using, and probably i'm not alone.
   why not to have it on sidebar?

My proposition would be something like:
* Development
 * Main page
 * Road Map + added current development news page (http://www.lyx.org/news/)
 * i18n status genrated page
 * How to use svn
  (about these below i dont have strong opinion, maybe just links from Main 
page)
 * Translation
 * Stuff read
 * Mirroring


3.
Its good habit to have site map (but this has to be created at the end, when 
the structure is fixed).

pavel

Re: LyX site - left to do?

[Rex C. Eastbourne]

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 is on-line, but 
what we have right now is so much better that I see no reasons to wait.


Joost


Agreed!

Rex

Re: [experimental PATCH] using qmake to detect Qt

[Enrico Forestieri]

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:

checking for qmake... /usr/local/qt/4.3.4/bin/qmake
checking for moc... /usr/local/qt/4.3.4/bin/moc
checking for uic... /usr/local/qt/4.3.4/bin/uic
checking for rcc... /usr/local/qt/4.3.4/bin/rcc
checking whether host operating system is Darwin... no
checking for the DEFINES to use with Qt...
checking for the INCPATH to use with Qt... -I/usr/lib/qt3/mkspecs/cygwin-g++ 
-I. -I.
checking for the LDFLAGS to use with Qt... -Wl,--enable-runtime-pseudo-reloc
checking for the LIBS to use with Qt...
checking for Qt's version... 4.3.4

Here, the DEFINES, INCPATH, LDFLAGS, and LIBS bits are all wrong.
I traced this to QMAKESPEC=/usr/lib/qt3/mkspecs/cygwin-g++
being put in my environment by /etc/profile.d/qt3-devel.sh

Then, I unset QMAKESPEC and got:

checking for qmake... /usr/local/qt/4.3.4/bin/qmake
checking for moc... /usr/local/qt/4.3.4/bin/moc
checking for uic... /usr/local/qt/4.3.4/bin/uic
checking for rcc... /usr/local/qt/4.3.4/bin/rcc
checking whether host operating system is Darwin... no
QMAKESPEC has not been set, so configuration cannot be deduced.
Error processing project file: /tmp/conftest3180.dir/conftest3180.dir.pro
configure: error: Calling /usr/local/qt/4.3.4/bin/qmake failed.

Thus, I set QMAKESPEC=/usr/local/qt/4.3.4/mkspecs/cygwin-g++-win32
but was greeted with:

checking for qmake... /usr/local/qt/4.3.4/bin/qmake
checking for moc... /usr/local/qt/4.3.4/bin/moc
checking for uic... /usr/local/qt/4.3.4/bin/uic
checking for rcc... /usr/local/qt/4.3.4/bin/rcc
checking whether host operating system is Darwin... no
Project LOAD(): Feature qt_config cannot be found.
configure: error: Calling /usr/local/qt/4.3.4/bin/qmake failed.

:(

I had a look at configure, and saw that it tries to extract info from
some Makefile. So I tried pointing to the qt4 build dir by using
--with-qt='/usr/local/src/qt/qtwin-4.3.4/build-cygwin'
and that seems to have (almost) worked:

checking for qmake... /usr/local/src/qt/qtwin-4.3.4/build-cygwin/bin/qmake
checking for moc... /usr/local/src/qt/qtwin-4.3.4/build-cygwin/bin/moc
checking for uic... /usr/local/src/qt/qtwin-4.3.4/build-cygwin/bin/uic
checking for rcc... /usr/local/src/qt/qtwin-4.3.4/build-cygwin/bin/rcc
checking whether host operating system is Darwin... no
checking for the DEFINES to use with Qt... -DUNICODE -DQT_NO_DEBUG 
-DQT_NO_KEYWORDS -DQT_GUI_LIB -DQT_CORE_LIB
checking for the INCPATH to use with Qt... 
-I/usr/local/src/qt/qtwin-4.3.4/mkspecs/cygwin-g++-win32 -I. 
-I/usr/local/qt/4.3.4/include/QtCore -I/usr/local/qt/4.3.4/include/QtCore 
-I/usr/local/qt/4.3.4/include/QtGui -I/usr/local/qt/4.3.4/include/QtGui 
-I/usr/local/qt/4.3.4/include -I. -I. -I.
checking for the LDFLAGS to use with Qt... -Wl,-s
checking for the LIBS to use with Qt... -L/usr/local/qt/4.3.4/lib -lQtGui 
-L/usr/local/qt/4.3.4/lib -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm 
-lwinspool -lpng -lmsimg32 -lQtCore -lkernel32 -luser32 -lshell32 -luuid 
-lole32 -ladvapi32 -lz -lm -lpthread
checking for Qt's version... 4.3.4

I don't want to use the same LDFLAGS used to build Qt, for example, as
in this case I would lose the debug info, whether or not I want it.
Then, I have to point configure to the build dir, but should also have
installed Qt, as the spotted directories are the installation ones.
Needless to say that I find all of this very inconvenient.
Moreover, I don't think that this is cygwin specific.

-- 
Enrico

Swapping modifier keys on LyX/Mac: new patch for Qt 4.3.4

[Jason WOODARD]

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
the patch and posted links to them at
http://wiki.lyx.org/Mac/LyXmodifierKeys.  This is obviously not ideal.

I finally got around to making a better patch that configures the
swapping behavior at runtime based on a property in a preferences file.
The patch is appended below.  Details are posted on the LyXmodifierKeys
wiki page, along with a patched Universal binary of LyX 1.5.4 (built
with Qt/Mac 4.3.4) and scripts to create and apply the patch to a clean
Qt source distribution.  I also compiled and tested against the SVN
trunk (r24030), and it appears to work fine.

I believe the performance impact is negligible -- one or two extra if
tests on a static boolean each time a modifier key is pressed -- and
there is no change in Qt's behavior unless swapping is enabled.  Thanks
to Jens and Chris Menzel (on copy), it has now been tested on both PPC
and Intel Macs under both Tiger and Leopard.

Would the folks who maintain the Mac binaries (Bennett in particular)
consider incorporating this patch into future official Mac releases?

-j

Jason Woodard
[EMAIL PROTECTED]



diff -Naur src/gui/kernel/qapplication_mac.cpp
src-patched/gui/kernel/qapplication_mac.cpp
--- src/gui/kernel/qapplication_mac.cpp 2008-03-23 22:25:23.0
+0800
+++ src-patched/gui/kernel/qapplication_mac.cpp 2008-03-23
22:26:56.0 +0800
@@ -157,6 +157,7 @@
 static bool qt_button_down_in_content; // whether the button_down was
in the content area.
 static bool qt_mac_previous_press_in_popup_mode = false;
 static bool qt_mac_no_click_through_mode = false;
+extern bool qt_mac_swap_modifiers;  // from qkeymapper_mac.cpp; keymap
hack
 static QPointerQWidget qt_mouseover;
 #if defined(QT_DEBUG)
 static boolappNoGrab= false;// mouse/keyboard
grabbing
@@ -411,6 +412,12 @@
 if (appleValue.isValid())
 qt_antialiasing_threshold = appleValue.toInt();
 
+// begin keymap hack
+appleValue = appleSettings.value(QLatin1String(QtSwapModifiers));
+if (appleValue.isValid())
+qt_mac_swap_modifiers = appleValue.toBool();
+// end keymap hack
+
 #ifdef DEBUG_PLATFORM_SETTINGS
 qDebug(qt_mac_update_os_settings
*);
 #endif
diff -Naur src/gui/kernel/qkeymapper_mac.cpp
src-patched/gui/kernel/qkeymapper_mac.cpp
--- src/gui/kernel/qkeymapper_mac.cpp   2008-03-23 22:24:27.0
+0800
+++ src-patched/gui/kernel/qkeymapper_mac.cpp   2008-03-26
21:38:38.0 +0800
@@ -62,6 +62,7 @@
   Internal variables and functions
 

*/
 bool qt_mac_eat_unicode_key = false;
+bool qt_mac_swap_modifiers = false;  // keymap hack
 extern bool qt_sendSpontaneousEvent(QObject *obj, QEvent *event);
//qapplication_mac.cpp
 
 Q_GUI_EXPORT void qt_mac_secure_keyboard(bool b)
@@ -144,20 +145,50 @@
 { kEventKeyModifierNumLockMask, QT_MAC_MAP_ENUM(Qt::KeypadModifier)
},
 { 0, QT_MAC_MAP_ENUM(0) }
 };
+
+// begin keymap hack
+static qt_mac_enum_mapper qt_mac_modifier_symbols_swapped[] = {
+{ shiftKey, QT_MAC_MAP_ENUM(Qt::ShiftModifier) },
+{ rightShiftKey, QT_MAC_MAP_ENUM(Qt::ShiftModifier) },
+{ controlKey, QT_MAC_MAP_ENUM(Qt::ControlModifier) },
+{ rightControlKey, QT_MAC_MAP_ENUM(Qt::ControlModifier) },
+{ cmdKey, QT_MAC_MAP_ENUM(Qt::MetaModifier) },
+{ kEventKeyModifierNumLockMask, QT_MAC_MAP_ENUM(Qt::KeypadModifier)
},
+{ 0, QT_MAC_MAP_ENUM(0) }
+};
+// end keymap hack
+
 Qt::KeyboardModifiers qt_mac_get_modifiers(int keys)
 {
 #ifdef DEBUG_KEY_BINDINGS_MODIFIERS
 qDebug(Qt: internal: **Mapping modifiers: %d (0x%04x), keys,
keys);
 #endif
 Qt::KeyboardModifiers ret = Qt::NoModifier;
-for(int i = 0; qt_mac_modifier_symbols[i].qt_code; i++) {
-if(keys  qt_mac_modifier_symbols[i].mac_code) {
+
+// begin keymap hack
+if(qt_mac_swap_modifiers) {
+// same as below except use swapped array instead of original
one
+for(int i = 0; qt_mac_modifier_symbols_swapped[i].qt_code; i++)
{
+if(keys  qt_mac_modifier_symbols_swapped[i].mac_code) {
 #ifdef DEBUG_KEY_BINDINGS_MODIFIERS
-qDebug(Qt: internal: got modifier: %s,
qt_mac_modifier_symbols[i].desc);
+qDebug(Qt: internal: got swapped modifier: %s,
qt_mac_modifier_symbols_swapped[i].desc);
 #endif
-ret |=
Qt::KeyboardModifier(qt_mac_modifier_symbols[i].qt_code);
+ret |=
Qt::KeyboardModifier(qt_mac_modifier_symbols_swapped[i].qt_code);
+}
+}
+} else {
+// original code
+for(int i = 0; qt_mac_modifier_symbols[i].qt_code; i++) {
+if(keys  

Re: Completion, cell-forward and the Tab key

[Jürgen Spitzmüller]

Stefan Schimanski wrote:
> What is e.g. OpenOffice doing?

You have to use the return key to accept a completion. Not a very good 
solution IMHO.

Jürgen

Re: Horizontal space inset

[Jürgen Spitzmüller]

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 spacing, so that he
> knows that this could also be a vertical space in some circumstances,
> whereas a non-expert user would understand that this is something special,
> even if he doesn't know in what respect. It is a pity that a tool-tip
> cannot be attached to the combobox entries...

We try to avoid LaTeXisms in the GUI, and I think this hint is too covert. 
I also think terms like "qquad" should be replaced by "double quad".

What about the attached?

Jürgen
Index: lib/ui/stdcontext.inc
===
--- lib/ui/stdcontext.inc	(Revision 24072)
+++ lib/ui/stdcontext.inc	(Arbeitskopie)
@@ -149,11 +149,11 @@
 		Item "Interword Space|w" "next-inset-modify space \space{}"
 		Item "Protected Space|o" "next-inset-modify space ~"
 		Item "Thin Space|T" "next-inset-modify space \thinspace{}"
+		Item "Negative Thin Space|N" "next-inset-modify space \negthinspace{}"
+		Item "Half Quad Space (Enskip)|k" "next-inset-modify space \enskip{}"
+		Item "Protected Half Quad Space (Enspace)|E" "next-inset-modify space \enspace{}"
 		Item "Quad Space|Q" "next-inset-modify space \quad{}"
-		Item "QQuad Space|u" "next-inset-modify space \qquad{}"
-		Item "Enspace|E" "next-inset-modify space \enspace{}"
-		Item "Enskip|k" "next-inset-modify space \enskip{}"
-		Item "Negative Thin Space|N" "next-inset-modify space \negthinspace{}"
+		Item "Double Quad Space|u" "next-inset-modify space \qquad{}"
 		Item "Horizontal Fill|F" "next-inset-modify space \hfill{}"
 		Item "Protected Horizontal Fill|i" "next-inset-modify space \hspace*{\fill}"
 		Item "Horizontal Fill (Dots)|D" "next-inset-modify space \dotfill{}"
Index: src/frontends/qt4/ui/HSpaceUi.ui
===
--- src/frontends/qt4/ui/HSpaceUi.ui	(Revision 24072)
+++ src/frontends/qt4/ui/HSpaceUi.ui	(Arbeitskopie)
@@ -76,7 +76,7 @@
  
  
   
-   Enspace (0.5 em)
+   Half Quad (0.5 em)
   
  
  
@@ -86,7 +86,7 @@
  
  
   
-   QQuad (2 em)
+   Double Quad (2 em)
   
  
  
Index: src/frontends/qt4/GuiHSpace.cpp
===
--- src/frontends/qt4/GuiHSpace.cpp	(Revision 24072)
+++ src/frontends/qt4/GuiHSpace.cpp	(Arbeitskopie)
@@ -96,6 +96,12 @@
 		selection == 0 || selection == 3  ||
 		(selection == 6 && pattern == 0) || selection == 7;
 	keepCB->setEnabled(enable_keep);
+	if (selection == 3)
+		keepCB->setToolTip(qt_("Insert the spacing even after a line break.\n"
+   "Note that a protected Half Quad will be turned into\n"
+   "a vertical space if used at the beginning of a paragraph!"));
+	else
+		keepCB->setToolTip(qt_("Insert the spacing even after a line break"));
 	changed();
 }
 

Re: New site

[christian . ridderstrom]

On Tue, 1 Apr 2008, Jean-Marc Lasgouttes wrote:


Le 31 mars 08 à 23:27, [EMAIL PROTECTED] a écrit :
Hmm... I looked at the conf.file, do you happen to know why is there a '?' 
in the regexp?


AliasMatch ^/test/([?A-Z].*) /home/lyx/www/www-user/test/index.php/Main
/$1

For all I know, the '?' is needed, but I'd like to check if you have any 
idea.


No idea.


I think I know why now... one option to removing Main/ from the URI was to 
instead use something like:


www.lyx.org/test/?n=HomePage

where the '?' is the first thin in the URI. We can just leave it as it is.

/Christia

--
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: [devel-list] Re: New LyX website

[christian . ridderstrom]

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.org is... substantial... :-)

/C

--
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: [devel-list] Re: New LyX website

[Pavel Sanda]

>> 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

Re: How to Implement Transparent Unbundling

[Jean-Marc Lasgouttes]

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 your mentor, co-authors,
>> reviewers, they only need to view it, or do minor editing, so they do
>> not have to unpack your file. 
> 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.

JMarc

[experimental PATCH] using qmake to detect Qt

[Jean-Marc Lasgouttes]

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 is that I can 

1/ build LyX on mandriva 2007.1+Qt 4.2
2/ build LyX on OSX 10.4+Qt 4.3 installed as a bundle (straight from
trolltech's site)

Remaining problems are

- requires autoconf 2.60 (easy to fix)

- does not do a separate check for QtCore only. I'll fix it if it is
  really needed not to link against QtGui (shouldn't this be a no-op
  for stuff like tex2lyx?)

- has no way to force linking against static libs (useful for OS X?)


Making this work should be as easy as

./configure --with-qt=/path/to/qt4/dir

The --with-qt is only needed if the right qmake is not on your path (I
did not need it on osx)

I have no idea whether this works on windows/mingw or windows/cygwin,
but I'd be interested to learn about it.

The general idea is that I want to avoid working further on that if it
proves to be a dead-end.

JMarc

PS: on a related note, shall we try to switch to libtool 2.2 for 1.6?

svndiff

Index: src/frontends/qt4/Makefile.am
===
--- src/frontends/qt4/Makefile.am	(revision 24081)
+++ src/frontends/qt4/Makefile.am	(working copy)
@@ -8,15 +8,15 @@ CLEANFILES += $(BUILT_SOURCES)
 
 #  Qt stuff  #
 # Use _() for localization instead of tr() or trUtf8()
-UIC4FLAGS=-tr lyx::qt_
+UICFLAGS=-tr lyx::qt_
 
 ui_%.h: ui/%.ui
-	$(UIC4) $(UIC4FLAGS) $< -o $@
+	$(UIC) $(UICFLAGS) $< -o $@
 
 MOCEDFILES = $(MOCHEADER:%.h=%_moc.cpp)
 
 %_moc.cpp: %.h
-	$(MOC4) -o $@ $<
+	$(MOC) -o $@ $<
 
 Resources.qrc: Makefile
 	echo "" > $@
@@ -26,7 +26,7 @@ Resources.qrc: Makefile
 	echo "" >> $@
 
 Resources.cpp: Resources.qrc
-	$(RCC4) $< -name Resources -o $@
+	$(RCC) $< -name Resources -o $@
 
 
 #  LIBRARIES  #
@@ -34,15 +34,15 @@ Resources.cpp: Resources.qrc
 noinst_LTLIBRARIES = liblyxqt4.la
 
 liblyxqt4_la_DEPENDENCIES = $(MOCEDFILES)
-liblyxqt4_la_LDFLAGS = $(QT4_LDFLAGS)
-liblyxqt4_la_LIBADD = $(QT4_LIB) 
+liblyxqt4_la_LDFLAGS = $(QT_LDFLAGS)
+liblyxqt4_la_LIBADD = $(QT_LIBS)
 
 AM_CPPFLAGS += \
-	$(QT4_CPPFLAGS) \
+	$(QT_CPPFLAGS) \
 	-I$(top_srcdir)/src \
 	-I$(top_srcdir)/src/frontends \
 	-I$(top_srcdir)/images \
-	$(QT4_INCLUDES) $(BOOST_INCLUDES)
+	$(BOOST_INCLUDES)
 
 SOURCEFILES = \
 	ButtonPolicy.cpp \
Index: src/Makefile.am
===
--- src/Makefile.am	(revision 24081)
+++ src/Makefile.am	(working copy)
@@ -23,6 +23,9 @@ OTHERLIBS = $(BOOST_LIBS) $(INTLLIBS) $(
 noinst_LTLIBRARIES = liblyxcore.la
 bin_PROGRAMS = lyx
 
+lyx_CXXFLAGS = $(QT_CXXFLAGS) $(AM_CXXFLAGS)
+lyx_CPPFLAGS = $(QT_CPPFLAGS) $(AM_CPPFLAGS)
+lyx_LDFLAGS  = $(QT_LDFLAGS) $(LDFLAGS)
 lyx_LDADD = \
 	liblyxcore.la \
 	liblyxmathed.la \
@@ -32,7 +35,7 @@ lyx_LDADD = \
 	liblyxgraphics.la \
 	support/liblyxsupport.la \
 	$(OTHERLIBS) \
-	$(QT4_LIB) 
+	$(QT_LIBS) 
 
 if LYX_WIN_RESOURCE
 .rc.o:
Index: src/support/Makefile.am
===
--- src/support/Makefile.am	(revision 24081)
+++ src/support/Makefile.am	(working copy)
@@ -7,8 +7,7 @@ EXTRA_DIST = pch.h \
 
 noinst_LTLIBRARIES = liblyxsupport.la
 
-liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(QT4_CORE_LIB) $(BOOST_SIGNALS)
-liblyxsupport_la_LDFLAGS = $(QT4_CORE_LDFLAGS)
+liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(BOOST_SIGNALS)
 
 BUILT_SOURCES = $(PCH_FILE)
 
@@ -23,7 +22,7 @@ CLEANFILES += $(MOCEDFILES)
 BUILT_SOURCES += $(MOCEDFILES)
 
 %_moc.cpp: %.h
-	$(MOC4) -o $@ $<
+	$(MOC) -o $@ $<
 
 liblyxsupport_la_DEPENDENCIES = $(MOCEDFILES)
 
@@ -31,7 +30,7 @@ liblyxsupport_la_DEPENDENCIES = $(MOCEDF
 ##
 
 AM_CPPFLAGS += $(PCH_FLAGS) -I$(srcdir)/.. $(BOOST_INCLUDES)
-AM_CPPFLAGS += $(QT4_CPPFLAGS) $(QT4_CORE_INCLUDES) -I$(srcdir)/minizip
+AM_CPPFLAGS += $(QT_CPPFLAGS) -I$(srcdir)/minizip
 
 # force the use of C++ compiler for minizip/*.c files, because
 # gcc can not go through the included boost files.
@@ -148,8 +147,8 @@ check_PROGRAMS = \
 	check_lstrings
 
 check_convert_LDADD = liblyxsupport.la  \
-	$(BOOST_LIBS) $(QT4_CORE_LIB)
-check_convert_LDFLAGS = $(QT4_CORE_LDFLAGS)
+	$(BOOST_LIBS) $(QT_CORE_LIBS)
+check_convert_LDFLAGS = $(QT_CORE_LDFLAGS)
 check_convert_SOURCES = \
 	tests/check_convert.cpp \
 	tests/boost.cpp
@@ -159,8 +158,8 @@ check_filetools_SOURCES = \
 	tests/check_filetools.cpp \
 	tests/boost.cpp
 
-check_lstrings_LDADD = liblyxsupport.la $(BOOST_LIBS) $(QT4_CORE_LIB)
-check_lstrings_LDFLAGS = $(QT4_CORE_LDFLAGS)
+check_lstrings_LDADD = liblyxsupport.la $(BOOST_LIBS) $(QT_CORE_LIB)
+check_lstrings_LDFLAGS = $(QT_CORE_LDFLAGS)
 

Re: drawing of selection

[José Matos]

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, that includes of course the chapter numbers, the items bullets, 
etc...

Without it we have an irregular selection and it is not pleasing, at least to 
my eyes.

-- 
José Abílio

Re: How to Implement Transparent Unbundling

[Bo Peng]

>  > 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 questions raised on that thread if
you are going to endorse Richard's proposal. Briefly speaking,
Ricahrd's proposal first exaggerated the problem by forcing the
unbundling of .lyx file (whereas I argue here that unbundling is not
always needed), and proposed a radical solution that copies all
embedded files to a directory under the document directory. This leads
to ugliness such as cleanup of an embed directory, and difficulties in
opening a file under a readonly directory. 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.

Cheers,
Bo

Re: [devel-list] Re: New LyX website

[christian . ridderstrom]

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   http://www.md.kth.se/~chr

MiKTeK Problem Report: Permission denied

[Ed Sykes]

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 recently updated MikTeX and am running the latest version of LyX on 
Windows XP Professional.

Any suggestions are deeply appreciated 


Thanks so much,

Cheers,
Ed Sykes
Sheridan College,
Canada 

Re: How to Implement Transparent Unbundling [was Re: EmbeddedFile Feature]

[rgheck]

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.



Then we need to educate such users the problem, and solutions.

  
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.


rh

RE: drawing of selection

[Leuven, E.]

> 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/TextMetrics.cpp	(revision 24087)
+++ src/TextMetrics.cpp	(working copy)
@@ -2025,8 +2025,8 @@
 		if (row_selection) {
 			DocIterator beg = bv_->cursor().selectionBegin();
 			DocIterator end = bv_->cursor().selectionEnd();
-			bool const beg_margin = beg.pit() < pit && i == 0;
-			bool const end_margin = end.pit() > pit && i == nrows - 1;
+			bool const beg_margin = beg.pit() < pit || row.sel_beg == cur.textRow().pos();
+			bool const end_margin = end.pit() > pit || row.sel_end == cur.textRow().endpos();
 			beg.pit() = pit;
 			beg.pos() = row.sel_beg;
 			end.pit() = pit;
@@ -2082,17 +2082,23 @@
 
 	// draw the margins
 	if (drawOnBegMargin) {
-		if (text_->isRTL(buffer, beg.paragraph()))
-			pi.pain.fillRectangle(x + x1, y1, width() - x1, y2 - y1, Color_selection);
-		else
-			pi.pain.fillRectangle(x, y1, x1, y2 - y1, Color_selection);
+		if (text_->isRTL(buffer, beg.paragraph())) {
+			int lm = bv_->leftMargin();
+			pi.pain.fillRectangle(x + x1, y1, width() - lm - x1, y2 - y1, Color_selection);
+		} else {
+			int rm = bv_->rightMargin();
+			pi.pain.fillRectangle(rm, y1, x1 - rm, y2 - y1, Color_selection);
+		}
 	}
 
 	if (drawOnEndMargin) {
-		if (text_->isRTL(buffer, beg.paragraph()))
-			pi.pain.fillRectangle(x, y1, x2, y2 - y1, Color_selection);
-		else
-			pi.pain.fillRectangle(x + x2, y1, width() - x2, y2 - y1, Color_selection);
+		if (text_->isRTL(buffer, beg.paragraph())) {
+			int rm = bv_->rightMargin();
+			pi.pain.fillRectangle(x + rm, y1, x2 - rm, y2 - y1, Color_selection);
+		} else {
+			int lm = bv_->leftMargin();
+			pi.pain.fillRectangle(x + x2, y1, width() - lm - x2, y2 - y1, Color_selection);
+		}
 	}
 
 	// if we are on a boundary from the beginning, it's probably

Re: How to Implement Transparent Unbundling [was Re: EmbeddedFile Feature]

[Bo Peng]

>  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 the same file
on different systems due to OS differences. This will be a much worse
problem if users would like to do this by hand (e.g. copy all files
from one system to another and try to make a document compile), and
our feature is really helpful here.

We can of course, disable the embedding of such files, as you
suggested, and as I can also easily do; or allow users to do this, but
give appropriate warnings and solutions (such as helping users move
them to the document directory). Given the benefits of sharing such
files, and the chance this happens, and the easiness of a solution, I
prefer the later.

Cheers,
Bo

RE: drawing of selection

[Leuven, E.]

> 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...

Re: This old bug in nested Noweb files and External Template solution

[José Matos]

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 unknowingly created a new bug on the same lines here:
>
> http://bugzilla.lyx.org/show_bug.cgi?id=4655
>
> The problem is that one cannot write a Noweb book in parts that are
> included in a main book file because child documents do not get
> weaved.
>
> If we don't find a work around, I think you should seriouly consider
> removing Book (Noweb) from the document styles.
>
> My idea is to work around this by treating the noweb lyx file as
> External Material.  I'm trying to write the external template, but I
> don't understand the format of it. I have been hoping that, as soon as
> I can make the question specific enough, then one of you will say "ah,
> that's easy, do this..."  So here's from ~/.lyx/external_template,
> where I'm trying to use the XFig example to handle the lyx noweb
> document.  What do I put in that will cause LyX to notice the lyx file
> is supposed to be gobbled up as Noweb, dumped out to LaTeX, processed
> by the Converter from the LyX config.

I guess that this problem could be solved adding the original document 
location to the kpsepath path, no? I have similar problems when using a logo 
in beamer preamble that would be solved this way.

I remember have seen some remark from Jean-Marc about a similar issue but I am 
not sure they are related.
-- 
José Abílio

Re: drawing of selection

[José Matos]

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

Re: drawing of selection

[Jürgen Spitzmüller]

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

Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[rgheck]

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 dispute
 now. But it matters, it seems to me, for the other reasons I've
 mentioned, viz: If the embedding stuff changes, I want the change only
 to affect things that have to do with embedding.



 Your example 

I can not believe that we spent so much time on this small issue. Of
course when we use another reprentation to params, we would better be
able to reproduce params. The meta_ patch will do exactly this, and if
someone would like to use a EmbeddedFileMap, the same issue should be
considered. 

  
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.


And you're missing the point of the example. If you use an 
EmbeddedFileMap, you can't recover the order of the parameters. That's 
why the LaTeX output would change. Of course, you could add some 
auxiliary data structure that recorded this information, but that would 
be ugly. And why should you need to do that? There's nothing about what 
the EmbeddedFileList represents that has anything to do with order.


The example wasn't idle. Using a map in InsetBibtex is totally natural: 
a map from parameter representations, like "biblio", to the EmbeddedFile 
objects that represent them; then we get easy lookup of one from the 
other. There's no reason to use an EmbeddedFileList. We don't use any of 
the methods of EmbeddedFileList except the ones that we get from 
std::vector (and the findFile() method, which ought just to be a wrapper 
around find_if). So we're not using the EmbeddedFileList at all, and we 
might as well just use vector. But if so, why can't we use 
a map? (This also has non-trivial advantages 
back in Buffer.cpp.) But we can't do that if we're iterating over the 
vector to access the parameters. So we shouldn't iterate over the 
vector. In short, and as I've said before: The basic operations of the 
inset should not depend upon this kind of stuff.


I don't see why any of that should be remotely controversial. It's 
Programming 101 stuff.


Can someone step in here please and resolve this? If I'm wrong, please 
feel free to tell me.


Richard

Re: How to Implement Transparent Unbundling

[rgheck]

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 hard to
justify.



  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 but in the session (local) stuff. 
Absolute file paths could be stored locally in the session, but they should 
never be in the (portable) lyx file.


  

+1

rh

RE: drawing of selection

[Leuven, E.]

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

Re: How to Implement Transparent Unbundling

[José Matos]

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.

  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 but in the session (local) stuff. 
Absolute file paths could be stored locally in the session, but they should 
never be in the (portable) lyx file.

> Cheers,
> Bo

-- 
José Abílio

Re: How to Implement Transparent Unbundling

[rgheck]

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

Re: Can Someone Please Resolve This? [Re: InsetBibtex Design Issue]

[Bo Peng]

>  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 is totally natural:

Come on, if you use a map, you open a file with embedded files and
save it. The embedded files may be saved in a different order and
result in a totally different .lyx file. It is lucky that you are not
supposed to svn an embedded .lyx file.

>  Can someone step in here please and resolve this? If I'm wrong, please
>  feel free to tell me.

Please.

Bo

Re: How to Implement Transparent Unbundling

[Bo Peng]

>   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 but in the session (local) stuff.
>  Absolute file paths could be stored locally in the session, but they should
>  never be in the (portable) lyx file.

The absolute-path files *are* in a temporary directory as long as you
do not extract them. I do not know what you meant by  "absolute file
paths could not be stored" because this has been what lyx is doing for
ages.

Bo

Re: How to Implement Transparent Unbundling

[Bo Peng]

>  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 systems.

Bo

Re: How to Implement Transparent Unbundling

[Bo Peng]

>  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 bundled mode,
they are supposed to be copied to a directory under the document
directory, but what about unbundled mode? The core design of the
current approach is that bundle and unbundle are totally reversible,
without loss of any information.

Cheers,
Bo

Re: Horizontal space inset

[Andre Poenitz]

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 spacing, so that he
> > knows that this could also be a vertical space in some circumstances,
> > whereas a non-expert user would understand that this is something special,
> > even if he doesn't know in what respect. It is a pity that a tool-tip
> > cannot be attached to the combobox entries...
> 
> We try to avoid LaTeXisms in the GUI, and I think this hint is too covert. 
> I also think terms like "qquad" should be replaced by "double quad".

I think the LaTeX names should be available _somewhere_ nevertheless,
e.g. in the tooltips...

Andre'

Re: Horizontal space inset

[Enrico Forestieri]

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 spacing, so that he
> > knows that this could also be a vertical space in some circumstances,
> > whereas a non-expert user would understand that this is something special,
> > even if he doesn't know in what respect. It is a pity that a tool-tip
> > cannot be attached to the combobox entries...
> 
> We try to avoid LaTeXisms in the GUI, and I think this hint is too covert. 

Okay.

> I also think terms like "qquad" should be replaced by "double quad".

Agreed.

> What about the attached?

I think it will do. After all, placing an \enspace at the beginning
of a paragraph is not so likely given that TeX does not remove spaces
at the beginning and end of a paragraph, and thus nobody should need
to check "protect". And even if they do, they are warned by the tool tip
(good idea, btw).

-- 
Enrico