Re: [PATCH] Complete patch for session management.

[Georg Baum]

Am Samstag, 25. März 2006 23:16 schrieb John Spray:
 My notion of the desired behaviour would encompass two cases:
  1. The user quits manually.  When next starting, the session will
 be restored if the load_session option is true.
  2. The user quits by logging out while LyX is running.  When next
 starting, the state will be restored completely.
 
 The point being that the usual behaviour would be determined by
 load_session, but we can also use this new functionality for the added
 spiff of recognising desktop-wide session management.

Yes, we should so soemthing like this. Note that there is another way to 
quit LyX:

3. Something bad happens, like a segfault or LyX is killed manually 
(emergency exit).

This is not the same as 2., because in 2. the OS sends a save session 
signal before LyX is killed hardly. We should take a safe approach and 
not attempt to save any session info in case 3, only the open documents 
as it is now.


Georg

Re: [patch] check for the preview-package

[Georg Baum]

Am Sonntag, 26. März 2006 05:10 schrieb Uwe Stöhr:
 Attached a small patch for chkconfig.ltx to check for the LaTeX-package 
 preview. I also patched the LaTeXConfig.lyx.in to describe the preview 
 package and to add descriptions for prettyref and varioref.

I put this into trunk. Jean-Marc will tell whether it goes in 1.4 also.

 Btw. for what is the file LyXConfig.lyx.in needed? 

I knew once, but forgot.


Georg

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

| 
|  |  | + ParIterator const end = b-par_iterator_end();
|  |  | + for (; it != end; ++it)
|  |  | + if (it.pit() == pit) {
|  |  | + 
bv_-setCursor(makeDocIterator(it, pos));
|  |  | + bv_-update(Update::FitCursor);
|  |  | + break;
|  |  | + }
|  |  | + }
|  |  | + }
|  It should still be refactored.
| 
|  If not for anything else that the code gets easier to read.
|  (I do not quite see how removal of id plays into this.)
|  (And no; operator[pit] on paragraphs won't solve it, just make the
|  cursor placement even more coarse grained)
| 
| You are talking about removing paragraph id, then restorePosition()
| will use filename, pit (currently id) and pos,

Where are you using id?

-- 
Lgb

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|   If not for anything else that the code gets easier to read.
|   (I do not quite see how removal of id plays into this.)
|   (And no; operator[pit] on paragraphs won't solve it, just make the
|   cursor placement even more coarse grained)
| 
| Now, a separate
| 

Can you please stop adding more and more features to the patch at
every step I just have to begin review again... more comments more
back and forth and then a new patch with new features and round and
round we go...

| Index: src/BufferView_pimpl.C
| ===
| --- src/BufferView_pimpl.C(revision 13495)
| +++ src/BufferView_pimpl.C(working copy)
| @@ -331,6 +349,9 @@
|   // to this buffer later on.
|   buffer_-saveCursor(cursor_.selectionBegin(),
|   cursor_.selectionEnd());
| + // current buffer is going to be switched-off, save cursor pos
| + LyX::ref().session().saveFilePosition(buffer_-fileName(),
| + boost::tie(cursor_.pit(), cursor_.pos()) );
|   }
|  
|   // If we are closing current buffer, switch to the first in
| @@ -804,13 +825,41 @@
|   owner_-message(bformat(_(Moved to bookmark %1$d), i));
|  }
|  
| -
|  bool BufferView::Pimpl::isSavedPosition(unsigned int i)
|  {
|   return i  saved_positions_num  !saved_positions[i].filename.empty();
|  }

Note that we use two blank lines between funciton definitions.

| +void BufferView::Pimpl::scrollToPosition(Buffer* buffer, lyx::pit_type pit, 
lyx::pos_type pos)
| +{
| + // check pit
| + if ( static_castsize_t(pit) = buffer-paragraphs().size() )
| + return;
| + 
| + ParIterator it = buffer-par_iterator_begin();
| + ParIterator const end = buffer-par_iterator_end();
| + for (; it != end; ++it)
| + if (it.pit() == pit) {
| + bv_-setCursor(makeDocIterator(it, pos));
| + bv_-update(Update::FitCursor);
| + return;
| + }
| +}

IMO too much was moved out into this function. The finding part is not
separated from the policy part.

| +string const sec_lastfiles = [recent files];
| +string const sec_lastfilepos = [cursor positions];
| +string const sec_lastopened = [last opened files];
| +string const sec_bookmarks = [bookmarks];
| +string const sec_misc = [misc info];

Please no misc section... 
(and you know how I feel about INI files...)

| Index: src/lyxfunc.C
| ===
| --- src/lyxfunc.C (revision 13495)
| +++ src/lyxfunc.C (working copy)
| @@ -1880,6 +1891,9 @@
|  
|  void LyXFunc::closeBuffer()
|  {
| + // save current cursor position 
| + LyX::ref().session().saveFilePosition(owner-buffer()-fileName(),
| + boost::tie(view()-cursor().pit(), view()-cursor().pos()) );


This looks wrong. boost::make_tuple should be used here.

| Index: src/frontends/gtk/GView.C
| ===
| --- src/frontends/gtk/GView.C (revision 13495)
| +++ src/frontends/gtk/GView.C (working copy)
| @@ -95,7 +99,17 @@
|   boost::bind(GMiniBuffer::editMode, minibuffer_.get()));
|   view_state_changed.connect(boost::bind(GView::showViewState, this));
|   signal_focus_in_event().connect(sigc::mem_fun(*this, 
GView::onFocusIn));
| - set_default_size(750, 550);
| + // 
| + int width = 750;
| + int height = 550;
| + // try to grab width/height saved from last session
| + string val = LyX::ref().session().loadMiscInfo(WindowWidth);
| + if (val != )
| + width = convertunsigned int(val);
| + val = LyX::ref().session().loadMiscInfo(WindowHeight);
| + if (val != )
| + height = convertunsigned int(val);
| + set_default_size(width, height);
|   // Make sure the buttons are disabled if needed.
|   updateToolbars();
|   string const iconName =
| @@ -117,7 +131,13 @@

Please wait with misc info and window info storing.

-- 
Lgb

List statistics

[Martin Vermeer]

Looking at the gmane list statistics, I see that in January we exceeded,
for the first time since 2004, 40 messages a day, and stayed there
(except for a small dip) until today. In March we even peaked to 60
messages a day, first since 2004 as well.

This based on the graph, which is probably moving-average.

It seems development effort is picking up. An that is in spite of a
freeze for much of this time. And we're getting new developers.

The bad news :-( is that much of this flurry is centered around Windows
and all its problems... now that we have a somewhat functioning Windows
port. The good news :-) is the cross-platform pays off, it seems. My
interpretation.

- Martin



pgpi2bKSACwPy.pgp
Description: PGP signature

[Fwd: What is the qt functions to get/set position of the main window?]

[Hammer Armin]

Hi Bo,

i've hacked the get/set function for the qt frontend on macosx some time
ago. Perhaps you can clean it up.

lyx_gui.diff : qt frontend code to get/set the window size and position
lyxrc_C.diff, lyxfunc.diff, lyxrc_h.diff : to save/retrieve the infos
from the Lyx Settings file.

The patches are agains 1.4.0 and only tested on macosx.

 mit freundlichen Gruessen / Yours
 Armin Hammer

 Original Message 
Subject: What is the qt functions to get/set position of the main window?
Date: Sat, 25 Mar 2006 12:12:19 -0600
From: Bo Peng [EMAIL PROTECTED]
To: LyX-Devel lyx-devel@lists.lyx.org

Dear list,

I am trying to preserve windows position and size for qt main window.
size seems to be easy but I could not find relevant functions for
windows position. Can anyone help?

Cheers,
Bo




--- ../lyx-1.4.0/src/lyxrc.C2005-12-12 12:13:03.0 +0100
+++ src/lyxrc.C 2005-12-19 07:55:10.0 +0100
@@ -151,6 +151,11 @@
{ \\screen_font_sizes, LyXRC::RC_SCREEN_FONT_SIZES },
{ \\screen_font_typewriter, LyXRC::RC_SCREEN_FONT_TYPEWRITER },
{ \\screen_font_typewriter_foundry, 
LyXRC::RC_SCREEN_FONT_TYPEWRITER_FOUNDRY },
+   { \\screen_geometry_height, LyXRC::RC_SCREEN_GEOMETRY_HEIGHT },   
+   { \\screen_geometry_width, LyXRC::RC_SCREEN_GEOMETRY_WIDTH }, 
+   { \\screen_geometry_xpos, LyXRC::RC_SCREEN_GEOMETRY_XPOS },
+   { \\screen_geometry_xysaved, LyXRC::RC_SCREEN_GEOMETRY_XYSAVED }, 
+   { \\screen_geometry_ypos, LyXRC::RC_SCREEN_GEOMETRY_YPOS },   
{ \\screen_zoom, LyXRC::RC_SCREEN_ZOOM },
{ \\serverpipe, LyXRC::RC_SERVERPIPE },
{ \\set_color, LyXRC::RC_SET_COLOR },
@@ -284,6 +289,12 @@
user_name = lyx::support::user_name();
 
user_email = lyx::support::user_email();
+   
+   geometry_xysaved = false;
+   geometry_xpos = -1;
+   geometry_ypos = -1;
+   geometry_width = 690;
+   geometry_height = 510;  
 }
 
 
@@ -759,6 +770,36 @@
}
break;
 
+   case RC_SCREEN_GEOMETRY_HEIGHT:
+   if (lexrc.next()) {
+   geometry_height = lexrc.getInteger();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_WIDTH:
+   if (lexrc.next()) {
+   geometry_width = lexrc.getInteger();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_XPOS:
+   if (lexrc.next()) {
+   geometry_xpos = lexrc.getInteger();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_XYSAVED:
+   if (lexrc.next()) {
+   geometry_xysaved = lexrc.getBool();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_YPOS:
+   if (lexrc.next()) {
+   geometry_ypos = lexrc.getInteger();
+   }
+   break;
+
case RC_SCREEN_FONT_ROMAN_FOUNDRY:
if (lexrc.next()) {
roman_font_foundry = lexrc.getString();
@@ -1517,6 +1558,37 @@
typewriter_font_foundry  \\n;
}
 
+   case RC_SCREEN_GEOMETRY_HEIGHT:
+   if (ignore_system_lyxrc ||
+   geometry_height != system_lyxrc.geometry_height) {
+   os  \\screen_geometry_height   geometry_height
+   '\n';
+   }
+   case RC_SCREEN_GEOMETRY_WIDTH:
+   if (ignore_system_lyxrc ||
+   geometry_width != system_lyxrc.geometry_width) {
+   os  \\screen_geometry_width   geometry_width
+   '\n';
+   }   
+   case RC_SCREEN_GEOMETRY_XYSAVED:
+   if (ignore_system_lyxrc ||
+   geometry_xysaved != system_lyxrc.geometry_xysaved) {
+   os  \\screen_geometry_xysaved   
convertstring(geometry_xysaved)
+   '\n';
+   }   
+   case RC_SCREEN_GEOMETRY_XPOS:
+   if (ignore_system_lyxrc ||
+   geometry_xpos != system_lyxrc.geometry_xpos) {
+   os  \\screen_geometry_xpos   geometry_xpos
+   '\n';
+   }
+   case RC_SCREEN_GEOMETRY_YPOS:
+   if (ignore_system_lyxrc ||
+   geometry_ypos != system_lyxrc.geometry_ypos) {
+   os  \\screen_geometry_ypos   geometry_ypos
+   '\n';
+   }
+
case RC_SCREEN_FONT_SCALABLE:
if (ignore_system_lyxrc ||
use_scalable_fonts != 

lyx140cvs: different headsep's on different pages

[Hartmut Haase]

Hi,
can someone explain why the pages of the attached file have different 
headsep's?
-- 
Viele Grüße,
Hartmut Haase

Hungerhilfe: http://www.thehungersite.com

Das heutige Motto:
When the wind is great, bow before it. When the wind is heavy, yield to it. 


Bestatter106.lyx
Description: application/lyx

Re: Some 1.5 ideas - is this the time for working on them?

[Ekkehart Schlicht]

Helge Hafting wrote:


It will obvoiusly take quite a while to get time for all of this. Please 
tell

me if something isn't ok - so I can avoid doing it.


Helge,

this is all useful and interesting - nothing that seems redundant. Yet I 
have still a further proposal (without being able to help with 
implementation):


What about a joker character in the menu Insert special character. 
If it is defined as \joker, or joker-insert, for example, the user may 
reassign anything he likes to that character (which may be taken from 
any available symbol usually not used, like strange AMS things, but 
colored like the present linebreak character). This would be handy if 
you want to use some command repeatedly without using the ugly ERT 
inserts. I would use this for \newslide or \pause in presentations, or 
for \linebreak. (The special character Linebreak produces, strangely, 
a \\ which is like a \newline (no stretching the previous line to the 
margin), but sometimes you need the \linebreak (with stretching), for 
instance when you want to manually break overstretching lines.)  I 
myself redefine \\ for such purposes at the moment. Maybe even two 
joker characters could be added? The user may actually deactivate them 
in ui. But maybe there exists such a possibility already, and I have 
overlooked it.


Just a suggestion.

Thanks for all your fruitful and good work.

Ekkehart

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Bo Peng]

 Can you please stop adding more and more features to the patch at
 every step I just have to begin review again... more comments more
 back and forth and then a new patch with new features and round and
 round we go...

I have certainly realized this problem and said 'this patch has grown bigger'...

But what am I supposed to do? Patches to unaccepted patch? If you
accept the basic patch quicker, I can send small patches to that one
each time. Also, it is perfectly fine for me if you prune the patch
yourself instead of waiting for my small changes.

 | +string const sec_lastfiles = [recent files];
 | +string const sec_lastfilepos = [cursor positions];
 | +string const sec_lastopened = [last opened files];
 | +string const sec_bookmarks = [bookmarks];
 | +string const sec_misc = [misc info];

 Please no misc section...
 (and you know how I feel about INI files...)

This section is used for frontend writers to save whatever information
they want to this session file. I can not think of a better way to do
this. Do you have any idea?

 |  void LyXFunc::closeBuffer()
 |  {
 | + // save current cursor position
 | + LyX::ref().session().saveFilePosition(owner-buffer()-fileName(),
 | + boost::tie(view()-cursor().pit(), view()-cursor().pos()) );

 This looks wrong. boost::make_tuple should be used here.

I am new to boost::tie, but one of the documents I read says it is
equivalent to make_tuple in this use. As a matter of fact, make_tupe
is A, B and tie is A, B so tie is potentially more efficient.

 Please wait with misc info and window info storing.

Why? As you can see from others' posts, people like this feature!

Bo

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 i've hacked the get/set function for the qt frontend on macosx some time
 ago. Perhaps you can clean it up.

But the maintainers do not seem to like this feature. If Lars says
yes, and prove on the rc options, I will clean the patch and submit to
him.

Thanks.
Bo

Re: Help request: QController and QView

[Abdelrazak Younes]

Angus Leeming a écrit :

Go read controllers/Dialog.C which *is* pretty transparent even if
things become less so in the frontends. My feeling about this is that people try
and make sense of the logic by starting in a frontend implementation of a
Dialog::View and, of course, end up confused because they can't see the
controlling logic.


OK, I have read Dialog.[Ch], Control*, QDialogView, etc...
And I still think that this is too complicated. The infrastructure 
assumes that all GUIs will be separate dialogs with OK, Apply, Cancel, 
and Restore buttons. IMHO the model should not know about the view. Qt4 
provide a clean separation between those too but I am having a hard time 
trying to fit that into current architecture.
I only need a base class that will transfer all lyx func request to/from 
the kernel. My QLAction class does that already for the toolbars and the 
menubars and I think this is the way to go for all kind of GUI.  This 
would mean extracting the logic from the current controllers and put 
that into what Qt4 would call delegates. A delegate job is to know 
about the data inside and to provide a nice and easy interface for the 
frontend. Basically, in the case of the Citation dialog, this is just a 
version of ControlCitation freed from the controller work. Some more 
code could be transfered from the current frontend code.


This new architecture would imply that those new dialogs use nothing 
from the frontends/controllers. No need to do that in one go, this can 
be done dialog per dialog. Of course, no need to rewrite the current 
frontends to this new architecture, this can be a Qt4 only thing.


Please don't take this all personally, the GUII surely was a good thing 
for xforms and I guess it provided an easy porting to Qt; but I think 
that we should use what Qt4 provides.


Of course I am not going this way if there is no consensus among 
potential Qt4 developers. I guess Andre is already on my side ;-), what 
about others?


Abdel.

Re: [patch] check for the preview-package

[Enrico Forestieri]

On Sun, Mar 26, 2006 at 10:28:15AM +0200, Georg Baum wrote:

 Am Sonntag, 26. März 2006 05:10 schrieb Uwe Stöhr:

  Btw. for what is the file LyXConfig.lyx.in needed? 
 
 I knew once, but forgot.

I think this file was obsoleted by LaTeXConfig.lyx.in. Perhaps
chkconfig.ltx should be updated to reflect it.

-- 
Enrico

Re: LyX 1.4.0 on Windows

[Enrico Forestieri]

Angus Leeming [EMAIL PROTECTED] writes:
 
 Jean-Marc Lasgouttes Jean-Marc.Lasgouttes at ... writes:
  Enrico my reading of it is that you need the three compilations only
  Enrico if you want an internationalized iconv program, i.e., if you
  Enrico want translated messages from iconv. I personally think that
  Enrico building libiconv with --disable-nls and then LyX with
  Enrico --with-included-gettext is sufficient. But I may be wrong 
 
  That seems very reasonable indeed.
 
 It may seem reasonable, but that's what I did (apart from the --disable-nls
 bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is
 the
 explicit --disable-nls important? Presumably not, since libiconv's configure
 will work out that it can't see a gettext.

Angus,

I don't know if you solved this problem, but I just got aware of a gettext
env var (OUTPUT_CHARSET) which may be related to it.

I have the correct output when I start a native LyX (compiled with
-mno-cygwin) as

$ LANG=ru_RU /c/Programmi/LyX-1.4.0/bin/lyx-1.4.0win32

but I get garbage when I do

$ OUTPUT_CHARSET=UTF-8 LANG=ru_RU /c/Programmi/LyX-1.4.0/bin/lyx-1.4.0win32

Anyway, OUTPUT_CHARSET=iso-8859-1 seems to work fine for me.

Here are a couple of links which may be useful:
http://www.mail-archive.com/cygwin@cygwin.com/msg37340.html
http://www.linuxdocs.org/HOWTOs/Unicode-HOWTO-3.html

HTH

-- 
Enrico

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sat, Mar 25, 2006 at 03:54:12PM +0100, Juergen Spitzmueller wrote:
 Helge Hafting wrote:
  I have some ideas, several of which I will attempt to implement myself
  if there is acceptance.  
 
 Cool. Welcome on board.
 
  * \dotfill and \hrulefill in addition to existing \hfill
I use the former a lot for documents where you sign on the dotted line
I plan on starting with this easy one.
 
 It would be the best to implement a horizontal spaces dialog, where you can 
 select the above and \hspace{some length} as well as the already defined 
 spaces in insetspace.
 
 The vspace dialog might serve as a prototype.

It's a both more complicated and simpler than that... I would say, study
first how rowpainter handles the painting of hfills.

Then, perhaps you should introduce hfill kinds in the form of an
enum, and modify the isHfill method in paragraph to return this kind, or
zero if not an hfill (getHfillKind). 

A dialog might be nice, but a good start would be menu entries for all
space _and_ hfill kinds. (Look inside insetspace.h to see what I mean
by kinds)

(BTW would it be a good idea to have tear-off menus? I find them
sometimes handy.)

- Martin


pgpDgNnFyHi0m.pgp
Description: PGP signature

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Martin Vermeer wrote:
 A dialog might be nice, but a good start would be menu entries for all
 space _and_ hfill kinds. (Look inside insetspace.h to see what I mean
 by kinds)

At least for \hspace, a dialog is needed. And it would of course make altering 
hspaces easier.

Jürgen

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sun, Mar 26, 2006 at 06:38:03PM +0200, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:
  A dialog might be nice, but a good start would be menu entries for all
  space _and_ hfill kinds. (Look inside insetspace.h to see what I mean
  by kinds)
 
 At least for \hspace, a dialog is needed. 

Not in the current implementation, see lib/stdmenus.ui and
src/factory.C.

 And it would of course make altering hspaces easier.

You mean switching between kinds? Sure. The Note inset would be a good
model to study then.

- Martin

 


pgptiUxrmbpc7.pgp
Description: PGP signature

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  i've hacked the get/set function for the qt frontend on macosx some time
|  ago. Perhaps you can clean it up.
| 
| But the maintainers do not seem to like this feature. If Lars says
| yes, and prove on the rc options, I will clean the patch and submit to
| him.

Can we go for just width and height as a first?

(then we can see if we want xpos,ypos later)

But the rest is basically ok with me.

-- 
Lgb

svn.lyx.org down?

[Abdelrazak Younes]

$ ping svn.lyx.org

Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 62.70.27.115:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Martin Vermeer wrote:
  At least for \hspace, a dialog is needed.

 Not in the current implementation, see lib/stdmenus.ui and
 src/factory.C.

I don't understand. How would you enter the length, e.g. \hspace{3em}? I think 
the minibuffer-only solution is not the way to go. And I also think that, 
apart from \hspace, a menu with 15 length entries is user friendly (that's 
why I only added a selection of insetspace there).

Jürgen

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sat, Mar 25, 2006 at 02:46:10PM +0100, Helge Hafting wrote:
 I have some ideas, several of which I will attempt to implement myself
 if there is acceptance.  This is not ordered by priority:

... 
 
 * support for nicefrac.sty (fractions with a slanted line)
   In text, this looks much better than the usual math fractions.

Agreed! This would be great. Do support all of units.sty once you're at
it, pretty please, yes?

   In tables, these are lower so numerators won't hit the table line
   above.

IIRC there are even two different LaTeX ways to add a little whitespace
inside tables to prevent this. Fractions aren't the only problem cases.

- Martin


pgpE89knvWjoQ.pgp
Description: PGP signature

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Juergen Spitzmueller wrote:
 a menu with 15 length entries is user friendly

read: _not_ user friendly.

Jürgen

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

| But what am I supposed to do? Patches to unaccepted patch? If you
| accept the basic patch quicker, I can send small patches to that one
| each time. Also, it is perfectly fine for me if you prune the patch
| yourself instead of waiting for my small changes.

A patchset would be easier to handle yes.
(Or just keep the further work on this in your private tree until we
get the basic patch apllied.)

|  | +string const sec_lastfiles = [recent files];
|  | +string const sec_lastfilepos = [cursor positions];
|  | +string const sec_lastopened = [last opened files];
|  | +string const sec_bookmarks = [bookmarks];
|  | +string const sec_misc = [misc info];
| 
|  Please no misc section...
|  (and you know how I feel about INI files...)
| 
| This section is used for frontend writers to save whatever information
| they want to this session file. I can not think of a better way to do
| this. Do you have any idea?

I understand its purpose. Hate the name though.


|  |  void LyXFunc::closeBuffer()
|  |  {
|  | + // save current cursor position
|  | + LyX::ref().session().saveFilePosition(owner-buffer()-fileName(),
|  | + boost::tie(view()-cursor().pit(), view()-cursor().pos()) 
);
| 
|  This looks wrong. boost::make_tuple should be used here.
| 
| I am new to boost::tie, but one of the documents I read says it is
| equivalent to make_tuple in this use. As a matter of fact, make_tupe
| is A, B and tie is A, B so tie is potentially more efficient.

This use of tie does feel ok, but I couldn't find it in the
documentation. Do you have a link?

|  Please wait with misc info and window info storing.
| 
| Why? As you can see from others' posts, people like this feature!

I want the basics in first so that I don't have to review a changing
target.

-- 
Lgb

Re: Help request: QController and QView

[Lars Gullik Bjønnes]

Abdelrazak Younes [EMAIL PROTECTED] writes:

| Of course I am not going this way if there is no consensus among
| potential Qt4 developers. I guess Andre is already on my side ;-),
| what about others?

It was never the intention that all GUIs must be alike. So I for one
is not against it.

BUT if we want frontends to stay close feeling wise, this is perhaps
not a good idea. (I have no strong feelings for that.)

-- 
Lgb

Re: svn.lyx.org down?

[Lars Gullik Bjønnes]

Abdelrazak Younes [EMAIL PROTECTED] writes:

| $ ping svn.lyx.org
| 
| Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:
| 
| Request timed out.

I think (hope) it is just a routing problem.

-- 
Lgb

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 Can we go for just width and height as a first?

Both Hammer and my patches can do this. So you need to decide which
approach you like better. Hammer uses lyxrc.write() to save these info
as user preferences, and I use session::saveMiscInfo() to save them as
session info.

I would definitely vote for my approach since the keyword/value
interface of session() allows saving of arbitrary information easily.
For example, if we decide to save toolbar status, windows position
later, we only need to use saveMiscInfo() and loadMiscInfo(), rather
than messing with all the RC_BLAHBLAH things.

Cheers,
Bo

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Georg Baum]

Am Sonntag, 26. März 2006 19:40 schrieb Bo Peng:
 I would definitely vote for my approach since the keyword/value
 interface of session() allows saving of arbitrary information easily.

I agree.

 For example, if we decide to save toolbar status, windows position
 later, we only need to use saveMiscInfo() and loadMiscInfo(), rather
 than messing with all the RC_BLAHBLAH things.

I share Lars' concerns about the misc section. Is it not possible to do 
without one? For example, is the frontend related information really 
different on different frontends?

BTW, I we should not invest too much time in the xforms xcode IMHO. I 
think it would be perfectly reasonable to not provide new features such 
as session support for the xforms frontend.


Georg

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sun, Mar 26, 2006 at 07:15:44PM +0200, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:
   At least for \hspace, a dialog is needed.
 
  Not in the current implementation, see lib/stdmenus.ui and
  src/factory.C.
 
 I don't understand. How would you enter the length, e.g. \hspace{3em}? I 
 think 
 the minibuffer-only solution is not the way to go. And I also think that, 
 apart from \hspace, a menu with 15 length entries is user friendly (that's 
 why I only added a selection of insetspace there).

Are you telling me that LyX has a way for inserting an arbitrary length
hspace? Where is it hidden?

/me scratching head,

- Martin



pgp1jA0dvPH6q.pgp
Description: PGP signature

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Bo Peng]

 A patchset would be easier to handle yes.

How do you guys do this? (I mean handling of multiple patches
locally.) The only way I know of is using SVK to have a local mirror
of the main repository, and perform submit and diff locally to get the
patches. But I do not like svk that much to use it.

 I understand its purpose. Hate the name though.

[session info]?

 This use of tie does feel ok, but I couldn't find it in the
 documentation. Do you have a link?

http://www.boost.org/libs/tuple/doc/tuple_users_guide.html#tiers says
that tie(i,c,a) is equivalent to make_tuple(ref(i), ref(c), ref(a)) .
But it does not use tie() in my way.

 I want the basics in first so that I don't have to review a changing
 target.

There will be no further change to this patch. Since I am not familiar
with paragraphs and cursor stack, I will depend on you to implement 
scrollToPosition. As you mentioned, the current way to save cursor
position (.pos() ) is not optimal so you might want to change that as
well.

Cheers,
Bo

Re: svn.lyx.org down?

[Abdelrazak Younes]

Lars Gullik Bjønnes a écrit :

Abdelrazak Younes [EMAIL PROTECTED] writes:

| $ ping svn.lyx.org
| 
| Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:
| 
| Request timed out.


I think (hope) it is just a routing problem.


I used to ssh without problem until yesterday, now I have:

$ ssh svn.lyx.org
Secure connection to svn.lyx.org refused.

$ ssh  -l younes svn.lyx.org
Secure connection to svn.lyx.org refused.

I am going to reboot to see if that solve the problem...

Abdel.

Re: svn.lyx.org down?

[Uwe Stöhr]

Lars Gullik Bjønnes schrieb:


| $ ping svn.lyx.org
| 
| Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:
| 
| Request timed out.


I think (hope) it is just a routing problem.


I get the same. www.lyx.org and bugzilla.lyx.org are also currently not 
available.


regards Uwe

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 I share Lars' concerns about the misc section. Is it not possible to do
 without one? For example, is the frontend related information really
 different on different frontends?

The lyxrc approach saves/loads such info for all frontends, but that
is difficult to do. For example, xform may not be able to implement
floating toolbars so toolbar positions are useless to it.

 BTW, I we should not invest too much time in the xforms xcode IMHO. I
 think it would be perfectly reasonable to not provide new features such
 as session support for the xforms frontend.

Right now, it is easy to do ...

Bo

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Martin Vermeer wrote:
 Are you telling me that LyX has a way for inserting an arbitrary length
 hspace? Where is it hidden?

No, but LaTeX has. And I think it should be finally supported. It's base 
functionality in LaTeX.
I have planned to implement a proper hspace solution (spaceinset + hfill + 
hdorfill + hrulefill + hspace in a dialog) myself. But looking at my agenda, 
I'm not unlucky at all if Helge beats me to it.

 /me scratching head,

No need to.

Jürgen

Re: Help request: QController and QView

[Abdelrazak Younes]

Lars Gullik Bjønnes a écrit :

Abdelrazak Younes [EMAIL PROTECTED] writes:

| Of course I am not going this way if there is no consensus among
| potential Qt4 developers. I guess Andre is already on my side ;-),
| what about others?

It was never the intention that all GUIs must be alike. So I for one
is not against it.


That's two! ;-)


BUT if we want frontends to stay close feeling wise, this is perhaps
not a good idea. (I have no strong feelings for that.)


Indeed, the idea would be to allow current GUIs to diverge (for the 
better). My goal is to split current GUI into model/view so that a 
functionality can have diverse form. For example, adding a citation 
could be done via a Dialog, a menu or a combo box;  but all views will 
share the same model. Another example is the TOC who can be either a 
dialog or a docked widget for outlining. Separating the model from the 
view will make the creation of a new view very cheap. The usability can 
become only better with this strategy.


Abdel.

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  A patchset would be easier to handle yes.
| 
| How do you guys do this? (I mean handling of multiple patches
| locally.) The only way I know of is using SVK to have a local mirror
| of the main repository, and perform submit and diff locally to get the
| patches. But I do not like svk that much to use it.

I have no idea... I use the cumbersome method of haveing several
trees...
 
|  I understand its purpose. Hate the name though.
| 
| [session info]?

I am suddenly a lot more positive.

|  This use of tie does feel ok, but I couldn't find it in the
|  documentation. Do you have a link?
| 
| http://www.boost.org/libs/tuple/doc/tuple_users_guide.html#tiers says
| that tie(i,c,a) is equivalent to make_tuple(ref(i), ref(c), ref(a)) .
| But it does not use tie() in my way.

Ok.
Thanks for the link.

-- 
Lgb

Re: Help request: QController and QView

[Angus Leeming]

Abdelrazak Younes [EMAIL PROTECTED] writes:
 Please don't take this all personally,

I don't. Software evolves.

 the GUII surely was a good thing 
 for xforms and I guess it provided an easy porting to Qt; but I think 
 that we should use what Qt4 provides.

Fine. Go for it.

 Of course I am not going this way if there is no consensus among 
 potential Qt4 developers. I guess Andre is already on my side , what 
 about others?

Why not make your vision concrete by porting, say, the Citation dialog?

Regards,
Angus

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  Can we go for just width and height as a first?
| 
| Both Hammer and my patches can do this. So you need to decide which
| approach you like better. Hammer uses lyxrc.write() to save these info
| as user preferences, and I use session::saveMiscInfo() to save them as
| session info.

Isn't there a difference here... With the info in lyxrc it becomes the
default geometry, with the info in session is is last session
geometry.

I think I want to be able to set the size of the app and still have
all session handling turned off.

btw. Is this a problem? That we might not want to save all session
stuff, but just parts of it?

-- 
Lgb

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 Isn't there a difference here... With the info in lyxrc it becomes the
 default geometry, with the info in session is is last session
 geometry.

His patch saves lyxrc every time when lyx exits. So, it is session
info, disguised as preference.

 I think I want to be able to set the size of the app and still have
 all session handling turned off.

You only need to set the default value of load_session to false. The
windows size part does not check lyxrc.load_session so it is always
on.

 btw. Is this a problem? That we might not want to save all session
 stuff, but just parts of it?

No. You can make the decision whether or not to put if
(lyxrc.load_session) before loading of bookmarks, and
scrollToPosition.

Bo

Re: Help request: QController and QView

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes [EMAIL PROTECTED] writes:

Please don't take this all personally,


I don't. Software evolves.

the GUII surely was a good thing 
for xforms and I guess it provided an easy porting to Qt; but I think 
that we should use what Qt4 provides.


Fine. Go for it.

Of course I am not going this way if there is no consensus among 
potential Qt4 developers. I guess Andre is already on my side , what 
about others?


Why not make your vision concrete by porting, say, the Citation dialog?


That's what I am trying to do actually. The code is already in svn. But 
I could use some help here. For sure I am not going to do all this alone 
so if there is no interest I'll just settle.


Abdel.



Regards,
Angus

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Georg Baum]

Am Sonntag, 26. März 2006 20:01 schrieb Bo Peng:
 The lyxrc approach saves/loads such info for all frontends, but that
 is difficult to do. For example, xform may not be able to implement
 floating toolbars so toolbar positions are useless to it.

Then it would simply ignore toolbar positions, like all frontends but 
xforms currently ignore wheel_jump. They could still be stored in a 
section [toolbar] or more general [geometry].

  BTW, I we should not invest too much time in the xforms xcode IMHO. I
  think it would be perfectly reasonable to not provide new features 
such
  as session support for the xforms frontend.
 
 Right now, it is easy to do ...

That is OK, but if it would not be easy we should not do it IMHO:


Georg

Re: Some 1.5 ideas - is this the time for working on them?

[Georg Baum]

Am Sonntag, 26. März 2006 20:01 schrieb Juergen Spitzmueller:
 No, but LaTeX has. And I think it should be finally supported. It's base 
 functionality in LaTeX.

Yes, I would also love to see this.

 I have planned to implement a proper hspace solution (spaceinset + hfill 
+ 
 hdorfill + hrulefill + hspace in a dialog) myself. But looking at my 
agenda, 
 I'm not unlucky at all if Helge beats me to it.

It would be nice if user defined lengths where also supported. These are 
currently missing from the vspace inset as well.


Georg

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 They could still be stored in a section [toolbar] or
 more general [geometry].

It is tempting to have sections like this, and even for each frontend
(who would run lyx with different frontends anyway?). But right now,
[session info] or [frontend] should be enough for the two entries we
have (window width and height).

Bo

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  Isn't there a difference here... With the info in lyxrc it becomes the
|  default geometry, with the info in session is is last session
|  geometry.
| 
| His patch saves lyxrc every time when lyx exits. So, it is session
| info, disguised as preference.

Ok, so we add it to preference... does not save on exit + your session
patch and we have both features?
 
|  I think I want to be able to set the size of the app and still have
|  all session handling turned off.
| 
| You only need to set the default value of load_session to false. The
| windows size part does not check lyxrc.load_session so it is always
| on.

But now you (we) are mixing rc configuration with session. IMHO not a good
thing.

-- 
Lgb

Re: svn.lyx.org down?

[Uwe Stöhr]

All xxx.lyx.org levels work now again. Thanks.

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 Ok, so we add it to preference... does not save on exit + your session
 patch and we have both features?

It is ok to have both but I really do not see the need. If windows
size is made persistent, which value should be used when both of them
(session().loadSessionValue() and lyxrc.windowsSize) are available? In
this sense, these two features actually conflict with each other.

 But now you (we) are mixing rc configuration with session. IMHO not a good
 thing.

So we should not do that and use the session() interface only.

Bo

Re: svn.lyx.org down?

[Abdelrazak Younes]

Uwe Stöhr a écrit :

All xxx.lyx.org levels work now again. Thanks.


svn.lyx.org still refuse ssh access for me...

Re: svn.lyx.org down?

[Abdelrazak Younes]

Abdelrazak Younes a écrit :

Uwe Stöhr a écrit :

All xxx.lyx.org levels work now again. Thanks.


svn.lyx.org still refuse ssh access for me...


Now it works :-)
Thanks

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sun, Mar 26, 2006 at 08:47:03PM +0200, Georg Baum wrote:
 Am Sonntag, 26. März 2006 20:01 schrieb Juergen Spitzmueller:
  No, but LaTeX has. And I think it should be finally supported. It's base 
  functionality in LaTeX.
 
 Yes, I would also love to see this.

Hmmm, it's finger painting and I don't much like it. But must admit to
having used it as ERT at times ;-)

- Martin



pgphH97n6ybyT.pgp
Description: PGP signature

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  Ok, so we add it to preference... does not save on exit + your session
|  patch and we have both features?
| 
| It is ok to have both but I really do not see the need. If windows
| size is made persistent, which value should be used when both of them
| (session().loadSessionValue() and lyxrc.windowsSize) are available? In
| this sense, these two features actually conflict with each other.

I think we should make window size configurable first, and then see if
it is still a need for making part of sessions.
 
|  But now you (we) are mixing rc configuration with session. IMHO not a good
|  thing.
| 
| So we should not do that and use the session() interface only.

No, quite the opposite. All parameters that a user might want to
configure should be rc. Only pure variables should be in session.

I do realize that width/height falls a bit in both categories.

-- 
Lgb

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 I do realize that width/height falls a bit in both categories.

1. Which way is easier save window size? Go to a dialog  to set value
or do nothing?
2. If both features are used. lyxrc.windowSize will be used only once.
I.e., when no session info exists yet.
3. All applications I have seen use the session approach. Can you
think of even one that has a dialog to set initial window size?
4. Even from an implementation point of view, I do not like the idea
of a bunch of rc entries.

Bo

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Bo Peng]

Dear list,

I just notice that bv_-setCursor(makeDocIterator(it, pos)); will
trigger an error if invalid pos is passed, because of externally
changed lyx file. Checking the validity of pos is therefore necessary
in scrollToPosition().

Please fix this problem, or I can submit another patch after my
proposed patch is applied.

Cheers,
Bo

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Martin Vermeer]

On Sun, Mar 26, 2006 at 06:10:50PM -0600, Bo Peng wrote:
  I do realize that width/height falls a bit in both categories.
 
 1. Which way is easier save window size? Go to a dialog  to set value
 or do nothing?

No dialog. Take the current window size and save it when the save button
is pressed.

 2. If both features are used. lyxrc.windowSize will be used only once.
 I.e., when no session info exists yet.
 3. All applications I have seen use the session approach. Can you
 think of even one that has a dialog to set initial window size?
 4. Even from an implementation point of view, I do not like the idea
 of a bunch of rc entries.

Yet, I must agree with Lars here. Window size is a save once thing.
Once you have found the right size, it is wrong to save it every time
again when you exit LyX. This is different with, e.g., position in the
file, which will be different each time you leave LyX. There it is
essential to have a fresh value saved.

- Martin



pgpxYQ2s3qyI5.pgp
Description: PGP signature

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

 No dialog. Take the current window size and save it when the save button
 is pressed.

You said later that you want to save it only once

 Yet, I must agree with Lars here. Window size is a save once thing.
 Once you have found the right size, it is wrong to save it every time
 again when you exit LyX. This is different with, e.g., position in the
 file, which will be different each time you leave LyX. There it is
 essential to have a fresh value saved.

Then how do you differentiate 'save size' close and usual close?  A
dialog would be needed. Also, it is perfectly normal, to me, and to
all windows users, and to, I guess, most of the *nix users, to save
window size every time. To test it, please fire firefox, resize it,
close and re-open.

Cheers,
Bo

Another automated build failure (ParagraphList.h)

[Kayvan A. Sylvan]

  g++ -DHAVE_CONFIG_H -I. -I. -I../../src -Winvalid-pch --include=./pch.h 
 -I./.. -I../../boost -Wextra -Wall -I/usr/X11R6/include -O2 -MT 
 math_casesinset.lo -MD -MP -MF .deps/math_casesinset.Tpo -c math_casesinset.C 
 -o math_casesinset.o
 In file included from math_casesinset.C:23:
 ../../src/undo.h:20:27: error: ParagraphList.h: No such file or directory
 ../../src/undo.h:83: error: 'ParagraphList' does not name a type
 make[5]: *** [math_casesinset.lo] Error 1

The above was another make dist issue fixed by the following patch.

Please apply.

Index: src/Makefile.am
===
--- src/Makefile.am (revision 13499)
+++ src/Makefile.am (working copy)
@@ -11,6 +11,7 @@
 SUBDIRS = mathed insets graphics support frontends . $(CLIENT) tex2lyx
 
 EXTRA_DIST = config.h.in stamp-h.in version.C.in \
+   ParagraphList.h \
Sectioning.h \
Sectioning.C \
Variables.C \
Index: src/support/Makefile.am
===
--- src/support/Makefile.am (revision 13499)
+++ src/support/Makefile.am (working copy)
@@ -5,7 +5,8 @@
 CLEANFILES += $(BUILT_SOURCES)
 
 EXTRA_DIST = package.C.in pch.h \
-   os_cygwin.C os_os2.C os_unix.C os_win32.C os_win32.h
+   os_cygwin.C os_os2.C os_unix.C os_win32.C os_win32.h \
+   RandomAccessList.h
 
 noinst_LTLIBRARIES = libsupport.la
 

[patch]: bug 2391: Alone superscripts incorrectly aligned in preview

[Juergen Spitzmueller]

The attached patch fixes the bug for me (approved by Uwe Stöhr).

The problem was that in the metrics calculation, we were too strict and didn't
allow negative descent values and fracs  1; both happens legally with
superscripts.

Jürgen
Index: lib/scripts/lyxpreview2bitmap.py
===
--- lib/scripts/lyxpreview2bitmap.py	(Revision 13489)
+++ lib/scripts/lyxpreview2bitmap.py	(Arbeitskopie)
@@ -103,12 +103,12 @@ def extract_metrics_info(dvipng_stdout, 
 ascent  = string.atof(match.group(2))
 
 frac = 0.5
-if ascent = 0 and descent = 0:
+if ascent = 0 or descent = 0:
 if abs(ascent + descent)  0.1:
 frac = ascent / (ascent + descent)
 
-# Sanity check
-if frac  0 or frac  1:
+	# Sanity check
+if frac  0:
 frac = 0.5
 
 metrics.write(Snippet %s %f\n % (page, frac))

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Martin Vermeer]

On Sun, 2006-03-26 at 23:15 -0600, Bo Peng wrote:
  No dialog. Take the current window size and save it when the save button
  is pressed.
 
 You said later that you want to save it only once

Yes. I meant the save button in the preferences dialog. It is (and can
be) only pressed when preferences have changed.

  Yet, I must agree with Lars here. Window size is a save once thing.
  Once you have found the right size, it is wrong to save it every time
  again when you exit LyX. This is different with, e.g., position in the
  file, which will be different each time you leave LyX. There it is
  essential to have a fresh value saved.
 
 Then how do you differentiate 'save size' close and usual close?  A
 dialog would be needed. Also, it is perfectly normal, to me, and to
 all windows users, and to, I guess, most of the *nix users, to save
 window size every time. To test it, please fire firefox, resize it,
 close and re-open.

Yes, I know. This has the interesting side effect of making it easier
for users to paint themselves into corners... has happened to me.

We can do better ;-)

- Martin



signature.asc
Description: This is a digitally signed message part

[patch] fix bug 2429

[Georg Baum]

It is not possible to insert a  in ERT. This trivial patch fixes that. It
is going into trunk later if nobody objects. Also OK for 1.4?


GeorgIndex: src/insets/insetert.C
===
--- src/insets/insetert.C	(Revision 13499)
+++ src/insets/insetert.C	(Arbeitskopie)
@@ -226,6 +236,12 @@ void InsetERT::doDispatch(LCursor  cur,
 	//lyxerr  \nInsetERT::doDispatch (begin): cmd:   cmd  endl;
 	switch (cmd.action) {
 
+	case LFUN_QUOTE: {
+		// We need to bypass the fancy quotes in LyXText
+		FuncRequest f(LFUN_SELFINSERT, \);
+		dispatch(cur, f);
+		break;
+	}
 	case LFUN_INSET_MODIFY: {
 		InsetCollapsable::CollapseStatus st;
 		InsetERTMailer::string2params(cmd.argument, st);
@@ -354,7 +369,6 @@ bool InsetERT::getStatus(LCursor  cur, 
 		case LFUN_INSERT_BOX:
 		case LFUN_GOTONOTE:
 		case LFUN_PARAGRAPH_SPACING:
-		case LFUN_QUOTE:
 		case LFUN_LABEL_GOTO:
 		case LFUN_REFERENCE_GOTO:
 		case LFUN_SPACE_INSERT:
@@ -372,6 +386,7 @@ bool InsetERT::getStatus(LCursor  cur, 
 			status.enabled(false);
 			return true;
 
+		case LFUN_QUOTE:
 		case LFUN_INSET_MODIFY:
 		case LFUN_PASTE:
 		case LFUN_PASTECLIPBOARD:

Re: [PATCH] Complete patch for session management.

[Georg Baum]

Am Samstag, 25. März 2006 23:16 schrieb John Spray:
> My notion of the desired behaviour would encompass two cases:
>  1. The user quits manually.  When next starting, the session will
> be restored if the load_session option is true.
>  2. The user quits by logging out while LyX is running.  When next
> starting, the state will be restored completely.
> 
> The point being that the usual behaviour would be determined by
> load_session, but we can also use this new functionality for the added
> spiff of recognising desktop-wide session management.

Yes, we should so soemthing like this. Note that there is another way to 
quit LyX:

3. Something bad happens, like a segfault or LyX is killed manually 
(emergency exit).

This is not the same as 2., because in 2. the OS sends a "save session" 
signal before LyX is killed hardly. We should take a safe approach and 
not attempt to save any session info in case 3, only the open documents 
as it is now.


Georg

Re: [patch] check for the preview-package

[Georg Baum]

Am Sonntag, 26. März 2006 05:10 schrieb Uwe Stöhr:
> Attached a small patch for chkconfig.ltx to check for the LaTeX-package 
> "preview". I also patched the LaTeXConfig.lyx.in to describe the preview 
> package and to add descriptions for prettyref and varioref.

I put this into trunk. Jean-Marc will tell whether it goes in 1.4 also.

> Btw. for what is the file LyXConfig.lyx.in needed? 

I knew once, but forgot.


Georg

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

"Bo Peng" <[EMAIL PROTECTED]> writes:

| >
| > | > | + ParIterator const end = b->par_iterator_end();
| > | > | + for (; it != end; ++it)
| > | > | + if (it.pit() == pit) {
| > | > | + 
bv_->setCursor(makeDocIterator(it, pos));
| > | > | + bv_->update(Update::FitCursor);
| > | > | + break;
| > | > | + }
| > | > | + }
| > | > | + }
| > It should still be refactored.
| >
| > If not for anything else that the code gets easier to read.
| > (I do not quite see how removal of id plays into this.)
| > (And no; operator[pit] on paragraphs won't solve it, just make the
| > cursor placement even more coarse grained)
| 
| You are talking about removing paragraph id, then restorePosition()
| will use filename, pit (currently id) and pos,

Where are you using id?

-- 
Lgb

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

"Bo Peng" <[EMAIL PROTECTED]> writes:

| > > If not for anything else that the code gets easier to read.
| > > (I do not quite see how removal of id plays into this.)
| > > (And no; operator[pit] on paragraphs won't solve it, just make the
| > > cursor placement even more coarse grained)
| 
| Now, a separate
| 

Can you please stop adding more and more features to the patch at
every step I just have to begin review again... more comments more
back and forth and then a new patch with new features and round and
round we go...

| Index: src/BufferView_pimpl.C
| ===
| --- src/BufferView_pimpl.C(revision 13495)
| +++ src/BufferView_pimpl.C(working copy)
| @@ -331,6 +349,9 @@
|   // to this buffer later on.
|   buffer_->saveCursor(cursor_.selectionBegin(),
|   cursor_.selectionEnd());
| + // current buffer is going to be switched-off, save cursor pos
| + LyX::ref().session().saveFilePosition(buffer_->fileName(),
| + boost::tie(cursor_.pit(), cursor_.pos()) );
|   }
|  
|   // If we are closing current buffer, switch to the first in
| @@ -804,13 +825,41 @@
|   owner_->message(bformat(_("Moved to bookmark %1$d"), i));
|  }
|  
| -
|  bool BufferView::Pimpl::isSavedPosition(unsigned int i)
|  {
|   return i < saved_positions_num && !saved_positions[i].filename.empty();
|  }

Note that we use two blank lines between funciton definitions.

| +void BufferView::Pimpl::scrollToPosition(Buffer* buffer, lyx::pit_type pit, 
lyx::pos_type pos)
| +{
| + // check pit
| + if ( static_cast(pit) >= buffer->paragraphs().size() )
| + return;
| + 
| + ParIterator it = buffer->par_iterator_begin();
| + ParIterator const end = buffer->par_iterator_end();
| + for (; it != end; ++it)
| + if (it.pit() == pit) {
| + bv_->setCursor(makeDocIterator(it, pos));
| + bv_->update(Update::FitCursor);
| + return;
| + }
| +}

IMO too much was moved out into this function. The finding part is not
separated from the policy part.

| +string const sec_lastfiles = "[recent files]";
| +string const sec_lastfilepos = "[cursor positions]";
| +string const sec_lastopened = "[last opened files]";
| +string const sec_bookmarks = "[bookmarks]";
| +string const sec_misc = "[misc info]";

Please no misc section... 
(and you know how I feel about INI files...)

| Index: src/lyxfunc.C
| ===
| --- src/lyxfunc.C (revision 13495)
| +++ src/lyxfunc.C (working copy)
| @@ -1880,6 +1891,9 @@
|  
|  void LyXFunc::closeBuffer()
|  {
| + // save current cursor position 
| + LyX::ref().session().saveFilePosition(owner->buffer()->fileName(),
| + boost::tie(view()->cursor().pit(), view()->cursor().pos()) );


This looks wrong. boost::make_tuple should be used here.

| Index: src/frontends/gtk/GView.C
| ===
| --- src/frontends/gtk/GView.C (revision 13495)
| +++ src/frontends/gtk/GView.C (working copy)
| @@ -95,7 +99,17 @@
|   boost::bind(::editMode, minibuffer_.get()));
|   view_state_changed.connect(boost::bind(::showViewState, this));
|   signal_focus_in_event().connect(sigc::mem_fun(*this, 
::onFocusIn));
| - set_default_size(750, 550);
| + // 
| + int width = 750;
| + int height = 550;
| + // try to grab width/height saved from last session
| + string val = LyX::ref().session().loadMiscInfo("WindowWidth");
| + if (val != "")
| + width = convert(val);
| + val = LyX::ref().session().loadMiscInfo("WindowHeight");
| + if (val != "")
| + height = convert(val);
| + set_default_size(width, height);
|   // Make sure the buttons are disabled if needed.
|   updateToolbars();
|   string const iconName =
| @@ -117,7 +131,13 @@

Please wait with misc info and window info storing.

-- 
Lgb

List statistics

[Martin Vermeer]

Looking at the gmane list statistics, I see that in January we exceeded,
for the first time since 2004, 40 messages a day, and stayed there
(except for a small dip) until today. In March we even peaked to 60
messages a day, first since 2004 as well.

This based on the graph, which is probably moving-average.

It seems development effort is picking up. An that is in spite of a
freeze for much of this time. And we're getting new developers.

The bad news :-( is that much of this flurry is centered around Windows
and all its problems... now that we have a somewhat functioning Windows
port. The good news :-) is the cross-platform pays off, it seems. My
interpretation.

- Martin



pgpi2bKSACwPy.pgp
Description: PGP signature

[Fwd: What is the qt functions to get/set position of the main window?]

[Hammer Armin]

Hi Bo,

i've hacked the get/set function for the qt frontend on macosx some time
ago. Perhaps you can clean it up.

lyx_gui.diff : qt frontend code to get/set the window size and position
lyxrc_C.diff, lyxfunc.diff, lyxrc_h.diff : to save/retrieve the infos
from the Lyx Settings file.

The patches are agains 1.4.0 and only tested on macosx.

 mit freundlichen Gruessen / Yours
 Armin Hammer

 Original Message 
Subject: What is the qt functions to get/set position of the main window?
Date: Sat, 25 Mar 2006 12:12:19 -0600
From: Bo Peng <[EMAIL PROTECTED]>
To: LyX-Devel 

Dear list,

I am trying to preserve windows position and size for qt main window.
size seems to be easy but I could not find relevant functions for
windows position. Can anyone help?

Cheers,
Bo




--- ../lyx-1.4.0/src/lyxrc.C2005-12-12 12:13:03.0 +0100
+++ src/lyxrc.C 2005-12-19 07:55:10.0 +0100
@@ -151,6 +151,11 @@
{ "\\screen_font_sizes", LyXRC::RC_SCREEN_FONT_SIZES },
{ "\\screen_font_typewriter", LyXRC::RC_SCREEN_FONT_TYPEWRITER },
{ "\\screen_font_typewriter_foundry", 
LyXRC::RC_SCREEN_FONT_TYPEWRITER_FOUNDRY },
+   { "\\screen_geometry_height", LyXRC::RC_SCREEN_GEOMETRY_HEIGHT },   
+   { "\\screen_geometry_width", LyXRC::RC_SCREEN_GEOMETRY_WIDTH }, 
+   { "\\screen_geometry_xpos", LyXRC::RC_SCREEN_GEOMETRY_XPOS },
+   { "\\screen_geometry_xysaved", LyXRC::RC_SCREEN_GEOMETRY_XYSAVED }, 
+   { "\\screen_geometry_ypos", LyXRC::RC_SCREEN_GEOMETRY_YPOS },   
{ "\\screen_zoom", LyXRC::RC_SCREEN_ZOOM },
{ "\\serverpipe", LyXRC::RC_SERVERPIPE },
{ "\\set_color", LyXRC::RC_SET_COLOR },
@@ -284,6 +289,12 @@
user_name = lyx::support::user_name();
 
user_email = lyx::support::user_email();
+   
+   geometry_xysaved = false;
+   geometry_xpos = -1;
+   geometry_ypos = -1;
+   geometry_width = 690;
+   geometry_height = 510;  
 }
 
 
@@ -759,6 +770,36 @@
}
break;
 
+   case RC_SCREEN_GEOMETRY_HEIGHT:
+   if (lexrc.next()) {
+   geometry_height = lexrc.getInteger();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_WIDTH:
+   if (lexrc.next()) {
+   geometry_width = lexrc.getInteger();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_XPOS:
+   if (lexrc.next()) {
+   geometry_xpos = lexrc.getInteger();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_XYSAVED:
+   if (lexrc.next()) {
+   geometry_xysaved = lexrc.getBool();
+   }
+   break;
+
+   case RC_SCREEN_GEOMETRY_YPOS:
+   if (lexrc.next()) {
+   geometry_ypos = lexrc.getInteger();
+   }
+   break;
+
case RC_SCREEN_FONT_ROMAN_FOUNDRY:
if (lexrc.next()) {
roman_font_foundry = lexrc.getString();
@@ -1517,6 +1558,37 @@
   << typewriter_font_foundry << "\"\n";
}
 
+   case RC_SCREEN_GEOMETRY_HEIGHT:
+   if (ignore_system_lyxrc ||
+   geometry_height != system_lyxrc.geometry_height) {
+   os << "\\screen_geometry_height " << geometry_height
+  << '\n';
+   }
+   case RC_SCREEN_GEOMETRY_WIDTH:
+   if (ignore_system_lyxrc ||
+   geometry_width != system_lyxrc.geometry_width) {
+   os << "\\screen_geometry_width " << geometry_width
+  << '\n';
+   }   
+   case RC_SCREEN_GEOMETRY_XYSAVED:
+   if (ignore_system_lyxrc ||
+   geometry_xysaved != system_lyxrc.geometry_xysaved) {
+   os << "\\screen_geometry_xysaved " << 
convert(geometry_xysaved)
+  << '\n';
+   }   
+   case RC_SCREEN_GEOMETRY_XPOS:
+   if (ignore_system_lyxrc ||
+   geometry_xpos != system_lyxrc.geometry_xpos) {
+   os << "\\screen_geometry_xpos " << geometry_xpos
+  << '\n';
+   }
+   case RC_SCREEN_GEOMETRY_YPOS:
+   if (ignore_system_lyxrc ||
+   geometry_ypos != system_lyxrc.geometry_ypos) {
+   os << "\\screen_geometry_ypos " << geometry_ypos
+  << '\n';
+   }
+
case RC_SCREEN_FONT_SCALABLE:
if (ignore_system_lyxrc ||
 

lyx140cvs: different headsep's on different pages

[Hartmut Haase]

Hi,
can someone explain why the pages of the attached file have different 
headsep's?
-- 
Viele Grüße,
Hartmut Haase

Hungerhilfe: http://www.thehungersite.com

Das heutige Motto:
When the wind is great, bow before it. When the wind is heavy, yield to it. 


Bestatter106.lyx
Description: application/lyx

Re: Some 1.5 ideas - is this the time for working on them?

[Ekkehart Schlicht]

Helge Hafting wrote:


It will obvoiusly take quite a while to get time for all of this. Please 
tell

me if something isn't ok - so I can avoid doing it.


Helge,

this is all useful and interesting - nothing that seems redundant. Yet I 
have still a further proposal (without being able to help with 
implementation):


What about a "joker" character in the menu "Insert special character". 
If it is defined as \joker, or joker-insert, for example, the user may 
reassign anything he likes to that character (which may be taken from 
any available symbol usually not used, like strange AMS things, but 
colored like the present linebreak character). This would be handy if 
you want to use some command repeatedly without using the ugly ERT 
inserts. I would use this for \newslide or \pause in presentations, or 
for \linebreak. (The special character "Linebreak" produces, strangely, 
a \\ which is like a \newline (no stretching the previous line to the 
margin), but sometimes you need the \linebreak (with stretching), for 
instance when you want to manually break overstretching lines.)  I 
myself redefine \\ for such purposes at the moment. Maybe even two 
"joker" characters could be added? The user may actually deactivate them 
in ui. But maybe there exists such a possibility already, and I have 
overlooked it.


Just a suggestion.

Thanks for all your fruitful and good work.

Ekkehart

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Bo Peng]

> Can you please stop adding more and more features to the patch at
> every step I just have to begin review again... more comments more
> back and forth and then a new patch with new features and round and
> round we go...

I have certainly realized this problem and said 'this patch has grown bigger'...

But what am I supposed to do? Patches to unaccepted patch? If you
accept the basic patch quicker, I can send small patches to that one
each time. Also, it is perfectly fine for me if you prune the patch
yourself instead of waiting for my small changes.

> | +string const sec_lastfiles = "[recent files]";
> | +string const sec_lastfilepos = "[cursor positions]";
> | +string const sec_lastopened = "[last opened files]";
> | +string const sec_bookmarks = "[bookmarks]";
> | +string const sec_misc = "[misc info]";
>
> Please no misc section...
> (and you know how I feel about INI files...)

This section is used for frontend writers to save whatever information
they want to this session file. I can not think of a better way to do
this. Do you have any idea?

> |  void LyXFunc::closeBuffer()
> |  {
> | + // save current cursor position
> | + LyX::ref().session().saveFilePosition(owner->buffer()->fileName(),
> | + boost::tie(view()->cursor().pit(), view()->cursor().pos()) );
>
> This looks wrong. boost::make_tuple should be used here.

I am new to boost::tie, but one of the documents I read says it is
equivalent to make_tuple in this use. As a matter of fact, make_tupe
is  and tie is  so tie is potentially more efficient.

> Please wait with misc info and window info storing.

Why? As you can see from others' posts, people like this feature!

Bo

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

> i've hacked the get/set function for the qt frontend on macosx some time
> ago. Perhaps you can clean it up.

But the maintainers do not seem to like this feature. If Lars says
yes, and prove on the rc options, I will clean the patch and submit to
him.

Thanks.
Bo

Re: Help request: QController and QView

[Abdelrazak Younes]

Angus Leeming a écrit :

Go read controllers/Dialog.C which *is* pretty transparent even if
things become less so in the frontends. My feeling about this is that people try
and make sense of the logic by starting in a frontend implementation of a
Dialog::View and, of course, end up confused because they can't see the
controlling logic.


OK, I have read Dialog.[Ch], Control*, QDialogView, etc...
And I still think that this is too complicated. The infrastructure 
assumes that all GUIs will be separate dialogs with OK, Apply, Cancel, 
and Restore buttons. IMHO the model should not know about the view. Qt4 
provide a clean separation between those too but I am having a hard time 
trying to fit that into current architecture.
I only need a base class that will transfer all lyx func request to/from 
the kernel. My QLAction class does that already for the toolbars and the 
menubars and I think this is the way to go for all kind of GUI.  This 
would mean extracting the logic from the current controllers and put 
that into what Qt4 would call "delegates". A delegate job is to know 
about the data inside and to provide a nice and easy interface for the 
frontend. Basically, in the case of the Citation dialog, this is just a 
version of ControlCitation freed from the controller work. Some more 
code could be transfered from the current frontend code.


This new architecture would imply that those new dialogs use nothing 
from the frontends/controllers. No need to do that in one go, this can 
be done dialog per dialog. Of course, no need to rewrite the current 
frontends to this new architecture, this can be a Qt4 only thing.


Please don't take this all personally, the GUII surely was a good thing 
for xforms and I guess it provided an easy porting to Qt; but I think 
that we should use what Qt4 provides.


Of course I am not going this way if there is no consensus among 
potential Qt4 developers. I guess Andre is already on my side ;-), what 
about others?


Abdel.

Re: [patch] check for the preview-package

[Enrico Forestieri]

On Sun, Mar 26, 2006 at 10:28:15AM +0200, Georg Baum wrote:

> Am Sonntag, 26. März 2006 05:10 schrieb Uwe Stöhr:

> > Btw. for what is the file LyXConfig.lyx.in needed? 
> 
> I knew once, but forgot.

I think this file was obsoleted by LaTeXConfig.lyx.in. Perhaps
chkconfig.ltx should be updated to reflect it.

-- 
Enrico

Re: LyX 1.4.0 on Windows

[Enrico Forestieri]

Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> Jean-Marc Lasgouttes  ...> writes:
> > Enrico> my reading of it is that you need the three compilations only
> > Enrico> if you want an internationalized iconv program, i.e., if you
> > Enrico> want translated messages from iconv. I personally think that
> > Enrico> building libiconv with --disable-nls and then LyX with
> > Enrico> --with-included-gettext is sufficient. But I may be wrong 
> 
> > That seems very reasonable indeed.
> 
> It may seem "reasonable", but that's what I did (apart from the --disable-nls
> bit) and, as I mention, I get garbage instead of Russian or Polish menus. Is
> the
> explicit --disable-nls important? Presumably not, since libiconv's configure
> will work out that it can't see a gettext.

Angus,

I don't know if you solved this problem, but I just got aware of a gettext
env var (OUTPUT_CHARSET) which may be related to it.

I have the correct output when I start a native LyX (compiled with
-mno-cygwin) as

$ LANG=ru_RU /c/Programmi/LyX-1.4.0/bin/lyx-1.4.0win32

but I get garbage when I do

$ OUTPUT_CHARSET=UTF-8 LANG=ru_RU /c/Programmi/LyX-1.4.0/bin/lyx-1.4.0win32

Anyway, OUTPUT_CHARSET=iso-8859-1 seems to work fine for me.

Here are a couple of links which may be useful:
http://www.mail-archive.com/cygwin@cygwin.com/msg37340.html
http://www.linuxdocs.org/HOWTOs/Unicode-HOWTO-3.html

HTH

-- 
Enrico

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sat, Mar 25, 2006 at 03:54:12PM +0100, Juergen Spitzmueller wrote:
> Helge Hafting wrote:
> > I have some ideas, several of which I will attempt to implement myself
> > if there is acceptance.  
> 
> Cool. Welcome on board.
> 
> > * \dotfill and \hrulefill in addition to existing \hfill
> >   I use the former a lot for documents where you "sign on the dotted line"
> >   I plan on starting with this easy one.
> 
> It would be the best to implement a "horizontal spaces" dialog, where you can 
> select the above and \hspace{} as well as the already defined 
> spaces in insetspace.
> 
> The vspace dialog might serve as a prototype.

It's a both more complicated and simpler than that... I would say, study
first how rowpainter handles the painting of hfills.

Then, perhaps you should introduce "hfill kinds" in the form of an
enum, and modify the isHfill method in paragraph to return this kind, or
zero if not an hfill ("getHfillKind"). 

A dialog might be nice, but a good start would be menu entries for all
space _and_ hfill kinds. (Look inside insetspace.h to see what I mean
by kinds)

(BTW would it be a good idea to have tear-off menus? I find them
sometimes handy.)

- Martin


pgpDgNnFyHi0m.pgp
Description: PGP signature

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Martin Vermeer wrote:
> A dialog might be nice, but a good start would be menu entries for all
> space _and_ hfill kinds. (Look inside insetspace.h to see what I mean
> by kinds)

At least for \hspace, a dialog is needed. And it would of course make altering 
hspaces easier.

Jürgen

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sun, Mar 26, 2006 at 06:38:03PM +0200, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > A dialog might be nice, but a good start would be menu entries for all
> > space _and_ hfill kinds. (Look inside insetspace.h to see what I mean
> > by kinds)
> 
> At least for \hspace, a dialog is needed. 

Not in the current implementation, see lib/stdmenus.ui and
src/factory.C.

> And it would of course make altering hspaces easier.

You mean switching between kinds? Sure. The Note inset would be a good
model to study then.

- Martin

 


pgptiUxrmbpc7.pgp
Description: PGP signature

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Lars Gullik Bjønnes]

"Bo Peng" <[EMAIL PROTECTED]> writes:

| > i've hacked the get/set function for the qt frontend on macosx some time
| > ago. Perhaps you can clean it up.
| 
| But the maintainers do not seem to like this feature. If Lars says
| yes, and prove on the rc options, I will clean the patch and submit to
| him.

Can we go for just width and height as a first?

(then we can see if we want xpos,ypos later)

But the rest is basically ok with me.

-- 
Lgb

svn.lyx.org down?

[Abdelrazak Younes]

$ ping svn.lyx.org

Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 62.70.27.115:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Martin Vermeer wrote:
> > At least for \hspace, a dialog is needed.
>
> Not in the current implementation, see lib/stdmenus.ui and
> src/factory.C.

I don't understand. How would you enter the length, e.g. \hspace{3em}? I think 
the minibuffer-only solution is not the way to go. And I also think that, 
apart from \hspace, a menu with 15 length entries is user friendly (that's 
why I only added a selection of insetspace there).

Jürgen

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sat, Mar 25, 2006 at 02:46:10PM +0100, Helge Hafting wrote:
> I have some ideas, several of which I will attempt to implement myself
> if there is acceptance.  This is not ordered by priority:

... 
 
> * support for nicefrac.sty (fractions with a slanted line)
>   In text, this looks much better than the usual math fractions.

Agreed! This would be great. Do support all of units.sty once you're at
it, pretty please, yes?

>   In tables, these are lower so numerators won't hit the table line
>   above.

IIRC there are even two different LaTeX ways to add a little whitespace
inside tables to prevent this. Fractions aren't the only problem cases.

- Martin


pgpE89knvWjoQ.pgp
Description: PGP signature

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Juergen Spitzmueller wrote:
> a menu with 15 length entries is user friendly

read: _not_ user friendly.

Jürgen

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

"Bo Peng" <[EMAIL PROTECTED]> writes:

| But what am I supposed to do? Patches to unaccepted patch? If you
| accept the basic patch quicker, I can send small patches to that one
| each time. Also, it is perfectly fine for me if you prune the patch
| yourself instead of waiting for my small changes.

A patchset would be easier to handle yes.
(Or just keep the further work on this in your private tree until we
get the basic patch apllied.)

| > | +string const sec_lastfiles = "[recent files]";
| > | +string const sec_lastfilepos = "[cursor positions]";
| > | +string const sec_lastopened = "[last opened files]";
| > | +string const sec_bookmarks = "[bookmarks]";
| > | +string const sec_misc = "[misc info]";
| >
| > Please no misc section...
| > (and you know how I feel about INI files...)
| 
| This section is used for frontend writers to save whatever information
| they want to this session file. I can not think of a better way to do
| this. Do you have any idea?

I understand its purpose. Hate the name though.


| > |  void LyXFunc::closeBuffer()
| > |  {
| > | + // save current cursor position
| > | + LyX::ref().session().saveFilePosition(owner->buffer()->fileName(),
| > | + boost::tie(view()->cursor().pit(), view()->cursor().pos()) 
);
| >
| > This looks wrong. boost::make_tuple should be used here.
| 
| I am new to boost::tie, but one of the documents I read says it is
| equivalent to make_tuple in this use. As a matter of fact, make_tupe
| is  and tie is  so tie is potentially more efficient.

This use of tie does feel ok, but I couldn't find it in the
documentation. Do you have a link?

| > Please wait with misc info and window info storing.
| 
| Why? As you can see from others' posts, people like this feature!

I want the basics in first so that I don't have to review a changing
target.

-- 
Lgb

Re: Help request: QController and QView

[Lars Gullik Bjønnes]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

| Of course I am not going this way if there is no consensus among
| potential Qt4 developers. I guess Andre is already on my side ;-),
| what about others?

It was never the intention that all GUIs must be alike. So I for one
is not against it.

BUT if we want frontends to stay close "feeling" wise, this is perhaps
not a good idea. (I have no strong feelings for that.)

-- 
Lgb

Re: svn.lyx.org down?

[Lars Gullik Bjønnes]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

| $ ping svn.lyx.org
| 
| Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:
| 
| Request timed out.

I think (hope) it is just a routing problem.

-- 
Lgb

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

> Can we go for just width and height as a first?

Both Hammer and my patches can do this. So you need to decide which
approach you like better. Hammer uses lyxrc.write() to save these info
as user preferences, and I use session::saveMiscInfo() to save them as
session info.

I would definitely vote for my approach since the keyword/value
interface of session() allows saving of arbitrary information easily.
For example, if we decide to save toolbar status, windows position
later, we only need to use saveMiscInfo() and loadMiscInfo(), rather
than messing with all the RC_BLAHBLAH things.

Cheers,
Bo

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Georg Baum]

Am Sonntag, 26. März 2006 19:40 schrieb Bo Peng:
> I would definitely vote for my approach since the keyword/value
> interface of session() allows saving of arbitrary information easily.

I agree.

> For example, if we decide to save toolbar status, windows position
> later, we only need to use saveMiscInfo() and loadMiscInfo(), rather
> than messing with all the RC_BLAHBLAH things.

I share Lars' concerns about the misc section. Is it not possible to do 
without one? For example, is the frontend related information really 
different on different frontends?

BTW, I we should not invest too much time in the xforms xcode IMHO. I 
think it would be perfectly reasonable to not provide new features such 
as session support for the xforms frontend.


Georg

Re: Some 1.5 ideas - is this the time for working on them?

[Martin Vermeer]

On Sun, Mar 26, 2006 at 07:15:44PM +0200, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > > At least for \hspace, a dialog is needed.
> >
> > Not in the current implementation, see lib/stdmenus.ui and
> > src/factory.C.
> 
> I don't understand. How would you enter the length, e.g. \hspace{3em}? I 
> think 
> the minibuffer-only solution is not the way to go. And I also think that, 
> apart from \hspace, a menu with 15 length entries is user friendly (that's 
> why I only added a selection of insetspace there).

Are you telling me that LyX has a way for inserting an arbitrary length
hspace? Where is it hidden?

/me scratching head,

- Martin



pgp1jA0dvPH6q.pgp
Description: PGP signature

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Bo Peng]

> A patchset would be easier to handle yes.

How do you guys do this? (I mean handling of multiple patches
locally.) The only way I know of is using SVK to have a local mirror
of the main repository, and perform submit and diff locally to get the
patches. But I do not like svk that much to use it.

> I understand its purpose. Hate the name though.

[session info]?

> This use of tie does feel ok, but I couldn't find it in the
> documentation. Do you have a link?

http://www.boost.org/libs/tuple/doc/tuple_users_guide.html#tiers says
that tie(i,c,a) is equivalent to make_tuple(ref(i), ref(c), ref(a)) .
But it does not use tie() in my way.

> I want the basics in first so that I don't have to review a changing
> target.

There will be no further change to this patch. Since I am not familiar
with paragraphs and cursor stack, I will depend on you to implement 
scrollToPosition. As you mentioned, the current way to save cursor
position (.pos() ) is not optimal so you might want to change that as
well.

Cheers,
Bo

Re: svn.lyx.org down?

[Abdelrazak Younes]

Lars Gullik Bjønnes a écrit :

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

| $ ping svn.lyx.org
| 
| Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:
| 
| Request timed out.


I think (hope) it is just a routing problem.


I used to ssh without problem until yesterday, now I have:

$ ssh svn.lyx.org
Secure connection to svn.lyx.org refused.

$ ssh  -l younes svn.lyx.org
Secure connection to svn.lyx.org refused.

I am going to reboot to see if that solve the problem...

Abdel.

Re: svn.lyx.org down?

[Uwe Stöhr]

Lars Gullik Bjønnes schrieb:


| $ ping svn.lyx.org
| 
| Pinging AUSSIE.lyx.org [62.70.27.115] with 32 bytes of data:
| 
| Request timed out.


I think (hope) it is just a routing problem.


I get the same. www.lyx.org and bugzilla.lyx.org are also currently not 
available.


regards Uwe

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

> I share Lars' concerns about the misc section. Is it not possible to do
> without one? For example, is the frontend related information really
> different on different frontends?

The lyxrc approach saves/loads such info for all frontends, but that
is difficult to do. For example, xform may not be able to implement
floating toolbars so toolbar positions are useless to it.

> BTW, I we should not invest too much time in the xforms xcode IMHO. I
> think it would be perfectly reasonable to not provide new features such
> as session support for the xforms frontend.

Right now, it is easy to do ...

Bo

Re: Some 1.5 ideas - is this the time for working on them?

[Juergen Spitzmueller]

Martin Vermeer wrote:
> Are you telling me that LyX has a way for inserting an arbitrary length
> hspace? Where is it hidden?

No, but LaTeX has. And I think it should be finally supported. It's base 
functionality in LaTeX.
I have planned to implement a proper hspace solution (spaceinset + hfill + 
hdorfill + hrulefill + hspace in a dialog) myself. But looking at my agenda, 
I'm not unlucky at all if Helge beats me to it.

> /me scratching head,

No need to.

Jürgen

Re: Help request: QController and QView

[Abdelrazak Younes]

Lars Gullik Bjønnes a écrit :

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

| Of course I am not going this way if there is no consensus among
| potential Qt4 developers. I guess Andre is already on my side ;-),
| what about others?

It was never the intention that all GUIs must be alike. So I for one
is not against it.


That's two! ;-)


BUT if we want frontends to stay close "feeling" wise, this is perhaps
not a good idea. (I have no strong feelings for that.)


Indeed, the idea would be to allow current GUIs to diverge (for the 
better). My goal is to split current GUI into model/view so that a 
functionality can have diverse form. For example, adding a citation 
could be done via a Dialog, a menu or a combo box;  but all views will 
share the same model. Another example is the TOC who can be either a 
dialog or a docked widget for outlining. Separating the model from the 
view will make the creation of a new view very cheap. The usability can 
become only better with this strategy.


Abdel.

Re: [PATCH] session menagement with bookmarks and window size (qt only) saved.

[Lars Gullik Bjønnes]

"Bo Peng" <[EMAIL PROTECTED]> writes:

| > A patchset would be easier to handle yes.
| 
| How do you guys do this? (I mean handling of multiple patches
| locally.) The only way I know of is using SVK to have a local mirror
| of the main repository, and perform submit and diff locally to get the
| patches. But I do not like svk that much to use it.

I have no idea... I use the cumbersome method of haveing several
trees...
 
| > I understand its purpose. Hate the name though.
| 
| [session info]?

I am suddenly a lot more positive.

| > This use of tie does feel ok, but I couldn't find it in the
| > documentation. Do you have a link?
| 
| http://www.boost.org/libs/tuple/doc/tuple_users_guide.html#tiers says
| that tie(i,c,a) is equivalent to make_tuple(ref(i), ref(c), ref(a)) .
| But it does not use tie() in my way.

Ok.
Thanks for the link.

-- 
Lgb

Re: Help request: QController and QView

[Angus Leeming]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Please don't take this all personally,

I don't. Software evolves.

> the GUII surely was a good thing 
> for xforms and I guess it provided an easy porting to Qt; but I think 
> that we should use what Qt4 provides.

Fine. Go for it.

> Of course I am not going this way if there is no consensus among 
> potential Qt4 developers. I guess Andre is already on my side , what 
> about others?

Why not make your vision concrete by porting, say, the Citation dialog?

Regards,
Angus

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Lars Gullik Bjønnes]

"Bo Peng" <[EMAIL PROTECTED]> writes:

| > Can we go for just width and height as a first?
| 
| Both Hammer and my patches can do this. So you need to decide which
| approach you like better. Hammer uses lyxrc.write() to save these info
| as user preferences, and I use session::saveMiscInfo() to save them as
| session info.

Isn't there a difference here... With the info in lyxrc it becomes the
"default geometry", with the info in session is is "last session
geometry".

I think I want to be able to set the size of the app and still have
all session handling turned off.

btw. Is this a problem? That we might not want to save all session
stuff, but just parts of it?

-- 
Lgb

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

> Isn't there a difference here... With the info in lyxrc it becomes the
> "default geometry", with the info in session is is "last session
> geometry".

His patch saves lyxrc every time when lyx exits. So, it is session
info, disguised as preference.

> I think I want to be able to set the size of the app and still have
> all session handling turned off.

You only need to set the default value of load_session to false. The
windows size part does not check lyxrc.load_session so it is always
on.

> btw. Is this a problem? That we might not want to save all session
> stuff, but just parts of it?

No. You can make the decision whether or not to put "if
(lyxrc.load_session)" before loading of bookmarks, and
scrollToPosition.

Bo

Re: Help request: QController and QView

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Please don't take this all personally,


I don't. Software evolves.

the GUII surely was a good thing 
for xforms and I guess it provided an easy porting to Qt; but I think 
that we should use what Qt4 provides.


Fine. Go for it.

Of course I am not going this way if there is no consensus among 
potential Qt4 developers. I guess Andre is already on my side , what 
about others?


Why not make your vision concrete by porting, say, the Citation dialog?


That's what I am trying to do actually. The code is already in svn. But 
I could use some help here. For sure I am not going to do all this alone 
so if there is no interest I'll just settle.


Abdel.



Regards,
Angus

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Georg Baum]

Am Sonntag, 26. März 2006 20:01 schrieb Bo Peng:
> The lyxrc approach saves/loads such info for all frontends, but that
> is difficult to do. For example, xform may not be able to implement
> floating toolbars so toolbar positions are useless to it.

Then it would simply ignore toolbar positions, like all frontends but 
xforms currently ignore wheel_jump. They could still be stored in a 
section [toolbar] or more general [geometry].

> > BTW, I we should not invest too much time in the xforms xcode IMHO. I
> > think it would be perfectly reasonable to not provide new features 
such
> > as session support for the xforms frontend.
> 
> Right now, it is easy to do ...

That is OK, but if it would not be easy we should not do it IMHO:


Georg

Re: Some 1.5 ideas - is this the time for working on them?

[Georg Baum]

Am Sonntag, 26. März 2006 20:01 schrieb Juergen Spitzmueller:
> No, but LaTeX has. And I think it should be finally supported. It's base 
> functionality in LaTeX.

Yes, I would also love to see this.

> I have planned to implement a proper hspace solution (spaceinset + hfill 
+ 
> hdorfill + hrulefill + hspace in a dialog) myself. But looking at my 
agenda, 
> I'm not unlucky at all if Helge beats me to it.

It would be nice if user defined lengths where also supported. These are 
currently missing from the vspace inset as well.


Georg

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

> They could still be stored in a section [toolbar] or
> more general [geometry].

It is tempting to have sections like this, and even for each frontend
(who would run lyx with different frontends anyway?). But right now,
[session info] or [frontend] should be enough for the two entries we
have (window width and height).

Bo

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Lars Gullik Bjønnes]

"Bo Peng" <[EMAIL PROTECTED]> writes:

| > Isn't there a difference here... With the info in lyxrc it becomes the
| > "default geometry", with the info in session is is "last session
| > geometry".
| 
| His patch saves lyxrc every time when lyx exits. So, it is session
| info, disguised as preference.

Ok, so we add it to preference... does not save on exit + your session
patch and we have both features?
 
| > I think I want to be able to set the size of the app and still have
| > all session handling turned off.
| 
| You only need to set the default value of load_session to false. The
| windows size part does not check lyxrc.load_session so it is always
| on.

But now you (we) are mixing rc configuration with session. IMHO not a good
thing.

-- 
Lgb

Re: svn.lyx.org down?

[Uwe Stöhr]

All xxx.lyx.org levels work now again. Thanks.

Re: [Fwd: What is the qt functions to get/set position of the main window?]

[Bo Peng]

> Ok, so we add it to preference... does not save on exit + your session
> patch and we have both features?

It is ok to have both but I really do not see the need. If windows
size is made persistent, which value should be used when both of them
(session().loadSessionValue() and lyxrc.windowsSize) are available? In
this sense, these two features actually conflict with each other.

> But now you (we) are mixing rc configuration with session. IMHO not a good
> thing.

So we should not do that and use the session() interface only.

Bo