The muscial Lyx
Hi all, I found something funny this morning. When copying from one window to the other one of the same lyx instance using the middle mouse button on Linux, LyX inserts some musical notes. When using STRG+C and STRG+V they don't appear. I don't know what info to provide, except a screen shot. have a good day Jonathan lyx2.png Description: PNG image
Re: r15655 - in /lyx-devel/branches/BRANCH_1_4_X: src/lyxfont.C
On Thu, Nov 02, 2006 at 07:32:21AM +, José Matos wrote: On Thursday 02 November 2006 6:11 am, Enrico Forestieri wrote: Georg, I think you forgot to update src/ChangeLog. Another reason why having 1.5 as the stable series is an beneficial. ;-) I actually like having ChangeLog files in the sources ;-) -- Enrico
Re: About New TabBar and Multiple-Windows
Lars Gullik Bjønnes wrote: Joost Verburg [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | sure it does. I do this all the time with emacs and firefox. | | Firefox has only a single process for all windows. | | In LyX you can have right now: | | 1) Multiple LyX instances (different processes) | 2) Multiple windows per instance | 3) Multiple documents per window | | 2) and 3) share the same data, but 1) does not. Do you really expect | the users to know which windows belong to which instance? as a matter of fact, yes I do. I would have liked us to have some better control over files that might have changed on disk though. (And this is a problem we have regardless of only one lyx instance or not.) And solving that problem is far better than artificially restricting LyX IMHO for two reasons: - This intelligent stuff usually strikes back - It will solve another serious problem: I edit a .lyx file on disk with my text editor to do some fancy search/replace, and accidentally overwrite it later with the old version that was still loaded in LyX. In fact the solution of this problem is very easy: Remember the last write time fo the file, and check it again before saving. If the two times differ, ask the user what to do. I really hate applications that think they know better what I want to do. If I open two LyX instances I have a reason to do so, and LyX should not override that decision. Georg
Re: r15655 - in /lyx-devel/branches/BRANCH_1_4_X: src/lyxfont.C
Enrico Forestieri wrote: Georg, I think you forgot to update src/ChangeLog. We don't use it anymore. Georg
Re: r15655 - in /lyx-devel/branches/BRANCH_1_4_X: src/lyxfont.C
Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Enrico Forestieri wrote: Georg, I think you forgot to update src/ChangeLog. Georg We don't use it anymore. Well, at least I try to update it in 1.4. I am not sure whether this is 100% necessary, so this is why I never complain to you about that :) JMarc
Re: Movable toolbars
On Tue, Oct 31, 2006 at 04:46:07PM +0100, Abdelrazak Younes wrote: Peter Kümmel wrote: Because - it costs us nothing - it's a nice feature for the user - I don't see any reason way we should disable it - we are releasing only a alpha version - I don't want to start a endless discussion I've just enabled it. I think we should make a distinction between the different toolbars. Vertical orientation for the standard toolbar and for the Command buffer do not make sense because we have edit boxes there. But no need to worry about that for now. The advanced users that we are know how to drag them back to an horizontal orientation :-) IMO, this functionality is not useful and the grippies simply take away space for the icons such that you have to enlarge the window to see them all :( -- Enrico
Re: About New TabBar and Multiple-Windows
José Matos wrote: On Wednesday 01 November 2006 6:11 pm, Joost Verburg wrote: It does not make sense to allow multiple instances when each instance can also have multiple windows. There is no way to tell which window belongs to which instance and therefore you can easily loose data by saving the wrong version of a document. What is the difference to what we have now? The session stuff, and the multiple window feature. Why don't we see people complaining about that? Because a) nothing is loaded automatically from an old session I might not remember anymore and b) only one window per instance is possible. I did not follow the multiple window feature/session stuff/toolbars discussion too closely, but I can't resist to make the following two remarks: - It looks like there is still much confusion how actually sessions should work in connection with multiple windows and toolbars. - It seems to eat quite a lot of developer resources. I predicted that two weeks ago, but nobody did believe me then :-( Georg
[patch] chars-transpose
Hi! I attached a patch (actually two, one against 1.4.4svn and one against 1.5.0svn) to bugzilla (http://bugzilla.lyx.org/show_bug.cgi?id=2939). To make it useful, you'll want to create a key binding for it (not included in the patch). I believe Jean-Marc is planning to commit it as soon as he gets a chance to test it, but meanwhile if anyone else wants to test it... Dov
Re: r15655 - in /lyx-devel/branches/BRANCH_1_4_X: src/lyxfont.C
Jean-Marc Lasgouttes wrote: Well, at least I try to update it in 1.4. I am not sure whether this is 100% necessary, so this is why I never complain to you about that :) I see. I thought that they where also abandoned in 1.4, but I have to admit that I am also too lazy to do both ChangeLog and commit log. Georg
Re: r15655 - in /lyx-devel/branches/BRANCH_1_4_X: src/lyxfont.C
On Thu, Nov 02, 2006 at 09:39:30AM +0100, Jean-Marc Lasgouttes wrote: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Enrico Forestieri wrote: Georg, I think you forgot to update src/ChangeLog. Georg We don't use it anymore. Well, at least I try to update it in 1.4. I am not sure whether this is 100% necessary, so this is why I never complain to you about that :) I seem to remember that ChangeLog files should be updated in 1.4. I noticed it simply because only src/lyxfont.C was updated after an svn up, so I went to src/ChangeLog to see what changed and could not find any entry. -- Enrico
Re: guiapi.C
Abdelrazak Younes [EMAIL PROTECTED] writes: | Angus Leeming wrote: | Abdelrazak Younes [EMAIL PROTECTED] writes: | Do we still need guiapi.[Ch]? Again, it seems like it is not | linked to the final LyX executable. | I let it there because I don't know it is used in some external | client. We shall know if this is true or not before removing this. | You can kill it. Lars introduced it years ago when he got exited by | the idea of dll-importing the frontend library, but the idea never | came to anything concrete. | | This is almost concrete now :-) You misunderstand. This was about runtime dynamic loading of libraries, not about using dynamic libraries and letting the system linker handle it upon startup. | The file can always be resurrected later on; it's meant to be a C- | language wrapper to our C++ frontend library calls. | | I'll kill it then. C++ dll are common nowadays, I don't think we'll | ever need to wrap the frontend interface in C. As dlopen(3) only have a C-interface you have to provide a C-api to get to the underlying C++-api... -- Lgb
Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Bo Peng wrote: Yeah, it was not that hard (see below). It's just that I don't have much time. This does solves my bookmark problem, but are you sure it is a good idea to open all buffers that was opened in the parent window? I know you understand the difference but for the sake of clarity let me repeat that again: The buffers are not opened again in the second window. They are opened once and only once. A window can only show one buffer at a time. The new tabbar is designed to show a list of all available buffer (this is Peter's doing, not mine). So this is independent from the number of opened windows. As it is now, the TabBar is just a shortcut for the View-Document submenu, that's all. I've already warned you all about that multiple times. My proposal was that we do not open any buffer but allow users to switch to them from view menu item. That was just my preference though. Read above: the Buffer is not opened again, only shown. With the new tabbar, it is all or nothing, you don't have a choice. All, please listen: I propose to remove the multi-window feature from the menu, or even remove the LFUN entirely. We can have it back when the new TabWidget that will replace the tabbar is ready (most probably in 1.6). Abdel.
Re: r15655 - in /lyx-devel/branches/BRANCH_1_4_X: src/lyxfont.C
On Thu, 2006-11-02 at 10:02 +0100, Enrico Forestieri wrote: On Thu, Nov 02, 2006 at 09:39:30AM +0100, Jean-Marc Lasgouttes wrote: Georg == Georg Baum [EMAIL PROTECTED] writes: Georg Enrico Forestieri wrote: Georg, I think you forgot to update src/ChangeLog. Georg We don't use it anymore. Well, at least I try to update it in 1.4. I am not sure whether this is 100% necessary, so this is why I never complain to you about that :) I seem to remember that ChangeLog files should be updated in 1.4. I noticed it simply because only src/lyxfont.C was updated after an svn up, so I went to src/ChangeLog to see what changed and could not find any entry. You can find the change logs from SVN. In my understanding the practice is to commit with a changelog, and post that to the list too (which seems a bit 'both belt and suspenders'). And status.14x should be updated. - Martin signature.asc Description: This is a digitally signed message part
Re: Coord cache and single par update
Martin Vermeer wrote: Hmmm, I don't think this is done in 1.4, and still single par update works just fine there... in 1.5 the infrastructure is there but it isn't working properly, as whole-screen updates have been layered on top of it with reckless disregard for what was already there, which thus is now completely useless. I am a bit angry about this. It would have been so easy to see what exactly is getting rendered using the PAINTING debug flag. Dear Martin, I've asked multiple times for help when trying to understand this metrics and coordcache stuff. Nobody ever stepped in. So IMHO, it's a bit easy to say that you are angry now. The old code was not understandable at _all_ and I believe it is much more understandable now that is has been cleaned up a bit. What about first getting the old singlepar/singlerow functionality back into a working state? Then we can see what is missing and provide it. Now we talk :-). I am open for suggestion and for help. Abdel.
Re: Coord cache and single par update
Martin Vermeer wrote: Note that the job will be easier if stale caches are not covered up by the current overzealous full-screen refresh behaviour. I suggest getting rid of that first. The full refresh thing is due to the cursor bug. I will work on it as soon as I find some free time. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Abdelrazak Younes wrote: Bo Peng wrote: Yeah, it was not that hard (see below). It's just that I don't have much time. This does solves my bookmark problem, but are you sure it is a good idea to open all buffers that was opened in the parent window? I know you understand the difference but for the sake of clarity let me repeat that again: The buffers are not opened again in the second window. They are opened once and only once. Maybe it helps when we describe it in other words. Due to Abdel's great work we now have a Model/View design. The buffers are the models and the Windows are the views. As you know there is only one model but arbitrarily much views. The problem is now, what do we with the views, they are all identical, because currently they are a whole view of the model. Maybe it is really the best do disable the multiple-view support until we know how we will handle this. One idea is to divide the one bug buffer into several smaller ones which all are viewed by a view, which doesn't know anything about other buffers. But then a multiple view of one document becomes impossible. To have this we could use something like a buffer-proxy... A other solution is to somehow handle within the views which part of the buffer is viewed. A window can only show one buffer at a time. The new tabbar is designed to show a list of all available buffer (this is Peter's doing, not mine). So this is independent from the number of opened windows. As it is now, the TabBar is just a shortcut for the View-Document submenu, that's all. I've already warned you all about that multiple times. My proposal was that we do not open any buffer but allow users to switch to them from view menu item. That was just my preference though. Read above: the Buffer is not opened again, only shown. With the new tabbar, it is all or nothing, you don't have a choice. All, please listen: I propose to remove the multi-window feature from the menu, or even remove the LFUN entirely. We can have it back when the new TabWidget that will replace the tabbar is ready (most probably in 1.6). Abdel. -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Abdelrazak Younes wrote: I propose to remove the multi-window feature from the menu, or even remove the LFUN entirely. We can have it back when the new TabWidget that will replace the tabbar is ready (most probably in 1.6). But we could also explain it to the user how it works: Beware there is only ONE document in your computer-memory but you could edit this ONE document with MULTIPLE windows. Then we will have some feedback how usefull this is, how the user likes it, which ideas they have to change the behavior, and so on. Isn't THIS the purpose a alpha release? We want feedback, not release the final product. -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Peter Kümmel wrote: A other solution is to somehow handle within the views which part of the buffer is viewed. This is what we have already: Each LyXView (WorkArea really) has its own unique BufferView which is a view of one part of the document. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Abdelrazak Younes wrote: Peter Kümmel wrote: A other solution is to somehow handle within the views which part of the buffer is viewed. This is what we have already: Each LyXView (WorkArea really) has its own unique BufferView which is a view of one part of the document. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view -- Peter Kümmel
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Abdelrazak Younes [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | | A other solution is to somehow handle within the views which part | of the buffer is viewed. | | This is what we have already: Each LyXView (WorkArea really) has its | own unique BufferView which is a view of one part of the document. | Except for some cursor bug (the famous dEPM bug), this is working fine. ..except that metrics is shared between views. (And this fails miserably when the windows are of different widths.) -- Lgb
Alpha release until monday 6. November
I think we should really release a alpha version of LyX 1.5 until Monday, 6. November. Why should we wait? It is a alpha release, it needs not to be perfect. I already think it is too stable for a alpha release. What is a Alpha release? http://en.wikipedia.org/wiki/Alpha_release#Alpha The alpha version of a product still awaits full debugging or full implementation of all its functionality but satisfies a majority of the software requirements. It often lacks features promised in the final release but demonstrates the feasibility and basic structure of the software. What about this Alpha-Release Show-Stopper-Criteria: Two clicks and crash, Peter P.S.: If you are still skeptical. Repress your perfectionist tendencies, it is only a alpha release, it is only a alpha release, it is only a alpha release, it is only a alpha release, it is only a alpha release, it is only a alpha release...
Re: About New TabBar and Multiple-Windows
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Abdelrazak Younes wrote:
This does not help. But after a CTRL-N all is fine,
so it couldn't be that hard for someone who knows
all the details. ;)
Yeah, it was not that hard (see below). It's just that I don't have much
time.
Abdel.
Great, it is fixed now.
This commit initialise correctly the tab bar in a new window.
* GuiView::init(): switch to the first avalaible buffer if any.
* GuiWorkArea::focusInEvent(): update the LyXView tab bar there.
Modified:
lyx-devel/trunk/src/frontends/qt4/GuiView.C
lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C
Modified: lyx-devel/trunk/src/frontends/qt4/GuiView.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/qt4/GuiView.C?rev=15685
==
--- lyx-devel/trunk/src/frontends/qt4/GuiView.C (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiView.C Wed Nov 1 23:57:32 2006
@@ -149,6 +149,9 @@
QObject::connect(statusbar_timer_, SIGNAL(timeout()),
this, SLOT(update_view_state_qt()));
+
+if (!work_area_-bufferView().buffer() !theBufferList().empty())
+setBuffer(theBufferList().first());
// make sure the buttons are disabled if needed
updateToolbars();
Modified: lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C?rev=15685
==
--- lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C Wed Nov 1 23:57:32
2006
@@ -288,6 +288,9 @@
void GuiWorkArea::focusInEvent(QFocusEvent * /*event*/)
{
+// FIXME: it would be better to send a signal newBuffer()
+// in BufferList that could be connected to the different tabbar.
+lyx_view_.updateTab();
startBlinkingCursor();
}
--
Peter Kümmel
Re: Input of CJK characters is O.K. but view fails
On Tue, 2006-10-31 at 08:46 +0100, Georg Baum wrote: Add the proper encodings to lib/encodings and languages to lib/languages. Then you need to fix the frontend that all encodings from lib/encodings can be selected, currently the list is hardcoded in src/frontends/qt4/QDocumentDialog.C. Can one just add utf-8 and expect it to work? I saw in lyx-devel that it is not clear whether support for utf-8 will be there in 1.5.0... I pulled the code frm svn and will try to build it to see how well can LyX play with XeTeX...bot Kile Texmaker work with utf-8 so it will be pitty if LyX is lacking proper support... Sincerely, Gour
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Peter Kümmel wrote: Abdelrazak Younes wrote: Peter Kümmel wrote: A other solution is to somehow handle within the views which part of the buffer is viewed. This is what we have already: Each LyXView (WorkArea really) has its own unique BufferView which is a view of one part of the document. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view OK, here is my try at it: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel.
Re: Alpha release until monday 6. November
Peter Kümmel [EMAIL PROTECTED] writes: | I think we should really release a alpha version | of LyX 1.5 until Monday, 6. November. Why change a decision already made? -- Lgb
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Lars Gullik Bjønnes wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: | Peter Kümmel wrote: | | A other solution is to somehow handle within the views which part | of the buffer is viewed. | | This is what we have already: Each LyXView (WorkArea really) has its | own unique BufferView which is a view of one part of the document. | Except for some cursor bug (the famous dEPM bug), this is working fine. ..except that metrics is shared between views. This should not be. Each BufferView now has its own CoordCache. If there's still something shared, this should be fixed. (And this fails miserably when the windows are of different widths.) The problem is different here. I believe that there's some cursor interaction problem that leads. This leads to crashes but most of the time, if you have two BufferView sharing the same Buffer, changing the geometry of one does not impact the other one (except if there's some editing that invalidated the cursor of the other BufferView). Abdel.
Re: Input of CJK characters is O.K. but view fails
On Thu, 2006-11-02 at 11:41 +0100, Gour wrote: I pulled the code from svn and will try to build it to see how well can LyX play with XeTeX...both Kile Texmaker work with utf-8 so it will be pity if LyX is lacking proper support... Ahh, some problems with my keyboard :-) Sincerely, Gour
Re: [patch] new InsetCommandParams
Am Mittwoch, 1. November 2006 15:38 schrieb Ozgur Ugras BARAN: By the way, I haven't seen nomencl commit in svn. Is something missing, or do you need new diff? Shortly after you went on holiday a freeze was announced, and nothing new was allowed to go in. Fortunately Jose (the 1.5.0 release manager) agreed to put the nomencl stuff in. As I wrote earlier I have a couple of comments. First I fixed some formatting issues (and IIRC I also found one or two bugs, please compare with your code, I forgot the details). Your latest version came too late for me, so that is not included in this diff. Please merge in the changes. I forgot whether the lyx2lyx part was finished, I'll check that over the weekend. The following needs to be done before it goes in: - Documentation in Userguide.lyx (or Extended.lyx? I don't know. Ask Uwe if in doubt). Please use LyX 1.4 for editing, the diff should not contain a file format change. - The parameter names should be the same as in the official documentation IMO. - The user visible strings should be unified: You should not mix Notation List and Glossary IMO. I'd like to have a final look over the weekend, so if you could send me the final version until saturday that would be great. Georg PS: Please let's continue on the list.
Re: Input of CJK characters is O.K. but view fails
Gour wrote: On Tue, 2006-10-31 at 08:46 +0100, Georg Baum wrote: Add the proper encodings to lib/encodings and languages to lib/languages. Then you need to fix the frontend that all encodings from lib/encodings can be selected, currently the list is hardcoded in src/frontends/qt4/QDocumentDialog.C. Can one just add utf-8 and expect it to work? As far as LyX is concerned: Yes. It is only commented out because it is a file format change. But of course you can not expect that all the present LaTeX limitations of utf8 encoded files will go away. Georg
Re: [patch] new InsetCommandParams
And the patch...Index: src/LyXAction.C
===
--- src/LyXAction.C (Revision 15688)
+++ src/LyXAction.C (Arbeitskopie)
@@ -366,6 +366,8 @@ void LyXAction::init()
{ LFUN_WINDOW_NEW, window-new, NoBuffer },
{ LFUN_WINDOW_CLOSE, window-close, NoBuffer },
{ LFUN_UNICODE_INSERT, unicode-insert, Noop },
+ { LFUN_NOMENCL_INSERT, nomencl-insert, Noop },
+ { LFUN_NOMENCL_PRINT, nomencl-print, Noop },
{ LFUN_NOACTION, , Noop }
};
Index: src/LaTeXFeatures.C
===
--- src/LaTeXFeatures.C (Revision 15688)
+++ src/LaTeXFeatures.C (Arbeitskopie)
@@ -386,6 +386,11 @@ string const LaTeXFeatures::getPackages(
if (isRequired(xy))
packages \\usepackage[all]{xy}\n;
+ if (isRequired(nomencl)) {
+ packages \\usepackage{nomencl}\n
+ \\makeglossary\n;
+ }
+
return packages.str();
}
Index: src/insets/insetnomencl.h
===
--- src/insets/insetnomencl.h (Revision 0)
+++ src/insets/insetnomencl.h (Revision 0)
@@ -0,0 +1,68 @@
+// -*- C++ -*-
+/**
+ * \file insetnomencl.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author O. U. BARAN (derived from Index counterpart of Lars Gullik Bjønnes. Thanks Lars)
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef INSET_NOMENCL_H
+#define INSET_NOMENCL_H
+
+
+#include insetcommand.h
+
+
+namespace lyx {
+
+class LaTeXFeatures;
+
+/** Used to insert notation labels
+ */
+class InsetNomencl : public InsetCommand {
+public:
+ ///
+ InsetNomencl(InsetCommandParams const );
+ ///
+ docstring const getScreenLabel(Buffer const ) const;
+ ///
+ EDITABLE editable() const { return IS_EDITABLE; }
+ ///
+ InsetBase::Code lyxCode() const;
+ ///
+ int docbook(Buffer const , odocstream ,
+ OutputParams const ) const;
+private:
+ virtual std::auto_ptrInsetBase doClone() const {
+ return std::auto_ptrInsetBase(new InsetNomencl(params()));
+ }
+};
+
+
+class InsetPrintNomencl : public InsetCommand {
+public:
+ ///
+ InsetPrintNomencl(InsetCommandParams const );
+ /// Updates needed features for this inset.
+ void validate(LaTeXFeatures features) const;
+ ///
+ EDITABLE editable() const { return NOT_EDITABLE; }
+ ///
+ InsetBase::Code lyxCode() const;
+ ///
+ bool display() const { return true; }
+ ///
+ docstring const getScreenLabel(Buffer const ) const;
+private:
+ virtual std::auto_ptrInsetBase doClone() const {
+ return std::auto_ptrInsetBase(new InsetPrintNomencl(params()));
+ }
+};
+
+
+} // namespace lyx
+
+#endif
Index: src/insets/insetbase.h
===
--- src/insets/insetbase.h (Revision 15688)
+++ src/insets/insetbase.h (Arbeitskopie)
@@ -322,7 +322,11 @@ public:
///
VSPACE_CODE,
///
- MATHMACROARG_CODE
+ MATHMACROARG_CODE,
+ ///
+ NOMENCL_CODE, // 45
+ ///
+ NOMENCL_PRINT_CODE
};
/** returns the Code corresponding to the \c name.
Index: src/insets/insetcommandparams.C
===
--- src/insets/insetcommandparams.C (Revision 15688)
+++ src/insets/insetcommandparams.C (Arbeitskopie)
@@ -109,14 +109,23 @@ InsetCommandParams::findInfo(std::string
return info;
}
- // InsetIndex, InsetPrintIndex, InsetLabel
- if (name == index || name == printindex || name == label) {
+ // InsetIndex, InsetPrintIndex, InsetLabel, InsetPrintNomencl
+ if (name == index || name == printindex || name == label ||
+ name == printglossary) {
static const char * const paramnames[] = {name, };
static const bool isoptional[] = {false};
static const CommandInfo info = {1, paramnames, isoptional};
return info;
}
+ // InsetNomencl
+ if (name == nomenclature) {
+ static const char * const paramnames[] = {name, explanation, sortas, };
+ static const bool isoptional[] = {false, false, true};
+ static const CommandInfo info = {3, paramnames, isoptional};
+ return info;
+ }
+
// InsetRef
if (name == eqref || name == pageref || name == vpageref ||
name == vref || name == prettyref || name == ref) {
Index: src/insets/insetnomencl.C
===
--- src/insets/insetnomencl.C (Revision 0)
+++ src/insets/insetnomencl.C (Revision 0)
@@ -0,0 +1,76 @@
+/**
+ * \file insetnomencl.C
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author O. U. BARAN (derived from Index counterpart of Lars Gullik Bjønnes. Thanks Lars.)
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+#include config.h
+
+#include insetnomencl.h
+
+#include dispatchresult.h
+#include funcrequest.h
+#include gettext.h
+#include LaTeXFeatures.h
+#include metricsinfo.h
+#include sgml.h
+
+
+namespace lyx {
+
+using std::string;
+
+
Re: Alpha release until monday 6. November
Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | I think we should really release a alpha version | of LyX 1.5 until Monday, 6. November. Why change a decision already made? Because - it wasn't that clear - it was more a decision for a beta release - to push LyX forward - we are flexible - we will collect more bug reports - it focuses the development - it makes existing problems more visible - most decisions were not discussed - Abdel can't do much for the next two weeks - Bo is on vacation - Michael is very busy because he's the best man on work - Maybe we find more Mac developers - currently we are in a run and we couldn't keep with the pace - I think waiting longer is wasted time, and we've already waste too much time - I see now reason to wait - I will see results - I think I have some support for this propose Peter
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Abdelrazak Younes [EMAIL PROTECTED] writes: | Lars Gullik Bjønnes wrote: | Abdelrazak Younes [EMAIL PROTECTED] writes: | | Peter Kümmel wrote: | | | A other solution is to somehow handle within the views which | part | | of the buffer is viewed. | | | This is what we have already: Each LyXView (WorkArea really) has | its | | own unique BufferView which is a view of one part of the document. | | Except for some cursor bug (the famous dEPM bug), this is working fine. | ..except that metrics is shared between views. | | This should not be. Each BufferView now has its own CoordCache. If | there's still something shared, this should be fixed. | | | (And this fails miserably when the windows are of different widths.) | | The problem is different here. I believe that there's some cursor | interaction problem that leads. This leads to crashes but most of the | time, if you have two BufferView sharing the same Buffer, changing the | geometry of one does not impact the other one (except if there's some | editing that invalidated the cursor of the other BufferView). Just try it for yourself and you will see. -- Lgb
AW: Alpha release until monday 6. November
I think we should really release a alpha version of LyX 1.5 until Monday, 6. November. Veto! We agreed on Nov 13th and I need the time for CT. And, after all, it is Jose who makes the decisions. Michael
Re: AW: Alpha release until monday 6. November
[EMAIL PROTECTED] wrote: I think we should really release a alpha version of LyX 1.5 until Monday, 6. November. Veto! We agreed on Nov 13th and I need the time for CT. And, after all, it is Jose who makes the decisions. Michael Haven't you read the Post Scriptum? ;) We could do the next alpha release when you've finished CT, then you don't have the pressure to complete it until 13th. Peter
Re: Input of CJK characters is O.K. but view fails
On Thu, 2006-11-02 at 11:55 +0100, Georg Baum wrote: Can one just add utf-8 and expect it to work? As far as LyX is concerned: Yes. It is only commented out because it is a file format change. Great! Let me try... Will it be added in 1.5.0 ? But of course you can not expect that all the present LaTeX limitations of utf8 encoded files will go away. That's why we have XeTeX ;) Sincerely, Gour
Re: Alpha release until monday 6. November
On Thursday 02 November 2006 11:08 am, Peter Kümmel wrote: Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | I think we should really release a alpha version | of LyX 1.5 until Monday, 6. November. Why change a decision already made? With all the due respect Peter, your enthusiasm makes me smile, and I like it but I would like to argue back. Because - it wasn't that clear I am sorry to disagree but every other post in this list seems to imply otherwise. - it was more a decision for a beta release I have stated clearly that it was an alpha release what we meant, I have even explained codewise what it implied. (No more new major features after this release). - to push LyX forward - we are flexible - we will collect more bug reports - it focuses the development - it makes existing problems more visible I doubt that. Developers knew the deadline and they are acting accordingly, changing time expectations can be extremely frustrating, for anyone (myself included). - most decisions were not discussed I don't understand your point here. - Abdel can't do much for the next two weeks - Bo is on vacation - Michael is very busy because he's the best man on work With all the due respect for the developers you mentioned, but I don't see how that is relevant here. - Maybe we find more Mac developers Just for releasing earlier? - currently we are in a run and we couldn't keep with the pace - I think waiting longer is wasted time, and we've already waste too much time These two points are contradicting each other. - I see now reason to wait - I will see results - I think I have some support for this propose Peter, as stated above, your energy is welcome in the project, but sometimes a little bit of patience pays off. :-) Peter -- José Abílio
Re: [patch] new InsetCommandParams
On 11/2/06, Georg Baum [EMAIL PROTECTED] wrote:
Am Mittwoch, 1. November 2006 15:38 schrieb Ozgur Ugras BARAN:
By the way, I haven't seen nomencl commit in svn. Is something
missing, or do you need new diff?
Shortly after you went on holiday a freeze was announced, and nothing new
was allowed to go in. Fortunately Jose (the 1.5.0 release manager) agreed
to put the nomencl stuff in.
Oh, this is bad news, since I have almost completed the multiple indices stuff..
As I wrote earlier I have a couple of comments. First I fixed some
formatting issues (and IIRC I also found one or two bugs, please compare
with your code, I forgot the details). Your latest version came too late
for me, so that is not included in this diff. Please merge in the changes.
I forgot whether the lyx2lyx part was finished, I'll check that over the
weekend.
Where can I find your code? Is it after my latest correction at Oct. 20th?
The following needs to be done before it goes in:
- Documentation in Userguide.lyx (or Extended.lyx? I don't know. Ask Uwe if
in doubt). Please use LyX 1.4 for editing, the diff should not contain a
file format change.
I will complete it before the weekend
- The parameter names should be the same as in the official documentation
IMO.
Sure..
- The user visible strings should be unified: You should not mix Notation
List and Glossary IMO.
Only place that the users can see a text except Notation is the
output. In the output, the title of the notation is printed as
Nomenclature. The reason I choose the text Notation through the user
interface is that, most non-native English speakers does not know the
word nomenclature, but most know the word notation. What I planned to
do is to write this down as a warning and note that they can change
the title of notation with command
\renewcommand{\nomname{List of Symbols}}
I'd like to have a final look over the weekend, so if you could send me the
final version until saturday that would be great.
I will try to complete. The problem is that, (stupidly) I am using the
same code for nomencl and multi indices. I have to separate them
first..
Georg
PS: Please let's continue on the list.
Ugras
Re: My Big Fat (Greek?) Cursor
John Levon wrote: On Wed, Nov 01, 2006 at 03:21:13PM +0100, Abdelrazak Younes wrote: But quite frankly, I don't understand what's so bad about letting the user change the cursor width. If anywhere, it belongs in a desktop-wide preference, not LyX doing its own thing. (And yes, same applies to colours: ideally we would be using native widgets.) You have a point. Ideally, we should use native widgets. But only if they are good enough for our use. If not, then rolling our own makes lyx better. The alternative to our own cursor then is not to use a bad widget, but to actually fix qt4. Helge Hafting
Re: LyX 1.5 translations
Michael Gerz wrote: Lars Gullik Bjønnes wrote: IMHO we should not merge translations from 1.4 at all. (or at most on a case by case basis. And if translators want it (I don't want it for NB f.ex.), msgmerge can be used for this.) Lars, I am a careful man :-) Right now, I am checking the state of the 1.4 and 1.5 translations on a case-by-case basis. If the 1.4 translations are better (for many languages they are significantly better!), I will remerge. Otherwise, I won't. I will put nb.po on my black list. Any particular problem with nb.po? Helge Hafting
Re: LyX 1.5 translations
Helge Hafting [EMAIL PROTECTED] writes: | Michael Gerz wrote: | Lars Gullik Bjønnes wrote: | | IMHO we should not merge translations from 1.4 at all. (or at most on | a case by case basis. And if translators want it (I don't want it for | NB f.ex.), msgmerge can be used for this.) | | Lars, I am a careful man :-) | | Right now, I am checking the state of the 1.4 and 1.5 translations | on a case-by-case basis. If the 1.4 translations are better (for | many languages they are significantly better!), I will remerge. | Otherwise, I won't. | | I will put nb.po on my black list. | Any particular problem with nb.po? Helge Hafting No. Only that it is missing translations and have a few fuzzy entries. I am working slowly on them help would be appreciated. -- Lgb
Re: [patch] new InsetCommandParams
Ozgur Ugras BARAN wrote:
On 11/2/06, Georg Baum
[EMAIL PROTECTED] wrote:
Shortly after you went on holiday a freeze was announced, and nothing new
was allowed to go in. Fortunately Jose (the 1.5.0 release manager) agreed
to put the nomencl stuff in.
Oh, this is bad news, since I have almost completed the multiple indices
stuff..
You can be lucky that the nomencl stuff is allowed at all.
As I wrote earlier I have a couple of comments. First I fixed some
formatting issues (and IIRC I also found one or two bugs, please compare
with your code, I forgot the details). Your latest version came too late
for me, so that is not included in this diff. Please merge in the
changes. I forgot whether the lyx2lyx part was finished, I'll check that
over the weekend.
Where can I find your code? Is it after my latest correction at Oct. 20th?
No, as I wrote, your latest correction is not included, because I already
did some changes. I forgot to attach the diff, but sent it in another post
afterwards.
The following needs to be done before it goes in:
- Documentation in Userguide.lyx (or Extended.lyx? I don't know. Ask Uwe
if in doubt). Please use LyX 1.4 for editing, the diff should not contain
a file format change.
I will complete it before the weekend
Fine.
- The user visible strings should be unified: You should not mix
Notation List and Glossary IMO.
Only place that the users can see a text except Notation is the
output. In the output, the title of the notation is printed as
Nomenclature. The reason I choose the text Notation through the user
interface is that, most non-native English speakers does not know the
word nomenclature, but most know the word notation. What I planned to
do is to write this down as a warning and note that they can change
the title of notation with command
\renewcommand{\nomname{List of Symbols}}
Then that must have been from an earlier version.
Georg
Re: Alpha release until monday 6. November
José Matos wrote: On Thursday 02 November 2006 11:08 am, Peter Kümmel wrote: Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | I think we should really release a alpha version | of LyX 1.5 until Monday, 6. November. Why change a decision already made? With all the due respect Peter, your enthusiasm makes me smile, and I like it but I would like to argue back. OK, I've tried it and failed. A comfort is, Asger also failed. Sad to see that I couldn't infect the others with my enthusiasm, seem the developers of LyX are more boring and inflexible than I thought. Regards, Peter Because - it wasn't that clear I am sorry to disagree but every other post in this list seems to imply otherwise. - it was more a decision for a beta release I have stated clearly that it was an alpha release what we meant, I have even explained codewise what it implied. (No more new major features after this release). - to push LyX forward - we are flexible - we will collect more bug reports - it focuses the development - it makes existing problems more visible I doubt that. Developers knew the deadline and they are acting accordingly, changing time expectations can be extremely frustrating, for anyone (myself included). - most decisions were not discussed I don't understand your point here. - Abdel can't do much for the next two weeks - Bo is on vacation - Michael is very busy because he's the best man on work With all the due respect for the developers you mentioned, but I don't see how that is relevant here. - Maybe we find more Mac developers Just for releasing earlier? - currently we are in a run and we couldn't keep with the pace - I think waiting longer is wasted time, and we've already waste too much time These two points are contradicting each other. - I see now reason to wait - I will see results - I think I have some support for this propose Peter, as stated above, your energy is welcome in the project, but sometimes a little bit of patience pays off. :-) Peter
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Abdelrazak Younes wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: Peter Kümmel wrote: A other solution is to somehow handle within the views which part of the buffer is viewed. This is what we have already: Each LyXView (WorkArea really) has its own unique BufferView which is a view of one part of the document. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view OK, here is my try at it: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel. Thanks Abdel, this is very good. We should add it some where in the wiki. Peter
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Abdelrazak Younes wrote: Peter Kümmel wrote: Abdelrazak Younes wrote: Peter Kümmel wrote: A other solution is to somehow handle within the views which part of the buffer is viewed. This is what we have already: Each LyXView (WorkArea really) has its own unique BufferView which is a view of one part of the document. Except for some cursor bug (the famous dEPM bug), this is working fine. Abdel. Ah, didn't know that. So could you describe the design a little bit with the MVC language, I think this will help a lot of people to read and understand the code. Something like this: model: - buffer the one big buffer view: - WorkArea partly view of the buffer - lyxview frontent impl of the view OK, here is my try at it: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel. We could also add it some where in to development/. -- Peter Kümmel
Re: Just 2 show stoppers from a test release - segfault on edit-reconfigure
Abdelrazak Younes wrote: Peter Kümmel wrote: Helge Hafting wrote: Asger Ottar Alstrup wrote: Hi, An update on the status of 1.5.svn. Nice work, guys - we are down to just 2 known show-stoppers for a test release: Another showstopper: edit-reconfigure = Segmentation fault I don't know what it is - here is a backtrace: You mean Tools-reconfigure? And you have no docuemnt open? Then this patch helps. Not enough because there might be no BufferView. I have committed the same fix but with LyXView instaed. I will kill this lyx_cb.[Ch] when 1.6 is open for development. I am going to review all those messages. Very good - reconfigure works now. Whether I have a document open or not. Helge Hafting
Re: Alpha release until monday 6. November
On Thursday 02 November 2006 12:20 pm, Peter Kümmel wrote: OK, I've tried it and failed. A comfort is, Asger also failed. What? As far as I understand, I have been all morning evaluating some exams from my students so my mood is not the best, Asger has being doing an evaluation of what needs to be done before a release. That is a work that needs to be done, as I have stated before I am grateful to Asger for doing this. Sad to see that I couldn't infect the others with my enthusiasm, seem the developers of LyX are more boring and inflexible than I thought. You are young lad. :-) The right mix between discipline and enthusiasm is always difficult, but I think that we have been improving here. :-) Or else it would be very difficult for me to believe that we are a bunch of masochists. :-) Regards, Peter -- José Abílio
Bug 2959: Can't modify document branches - and badness with non-ascii names
I opened an existing document, went to document-settings-branches, and discovered: 1. I can't activate/deactivate the existing branch. The branch name is non-ascii. I can add a new one and activate/deactivate it, if the name is ascii. 2. Adding a new branch with a non-ascii name destroys the non-ascii characters in the name. I get a square instead. Clearly, the new branch entryfield and the list box uses different encodings! Maybe this explains (1) too. Such a branch cannot be removed either, while a branch with a ascii name is removeable. 3. I can't change branch colors at all - even if the name *is* ascii-only. This is today's lyx 1.5svn Helge Hafting
Re: Coord cache and single par update
On Thu, 2006-11-02 at 10:40 +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: Hmmm, I don't think this is done in 1.4, and still single par update works just fine there... in 1.5 the infrastructure is there but it isn't working properly, as whole-screen updates have been layered on top of it with reckless disregard for what was already there, which thus is now completely useless. I am a bit angry about this. It would have been so easy to see what exactly is getting rendered using the PAINTING debug flag. Dear Martin, I've asked multiple times for help when trying to understand this metrics and coordcache stuff. Nobody ever stepped in. So IMHO, it's a bit easy to say that you are angry now. I know, but I just didn't connect it to rendering/rowpainter stuff. I would have reacted if you had asked about that. The old code was not understandable at _all_ and I believe it is much more understandable now that is has been cleaned up a bit. What about first getting the old singlepar/singlerow functionality back into a working state? Then we can see what is missing and provide it. Now we talk :-). I am open for suggestion and for help. Abdel. signature.asc Description: This is a digitally signed message part
Re: Coord cache and single par update
On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: Note that the job will be easier if stale caches are not covered up by the current overzealous full-screen refresh behaviour. I suggest getting rid of that first. The full refresh thing is due to the cursor bug. I will work on it as soon as I find some free time. Abdel. Are you sure? That would be great. - Martin signature.asc Description: This is a digitally signed message part
Re: Input of CJK characters is O.K. but view fails
On Tue, 2006-10-31 at 08:46 +0100, Georg Baum wrote: Add the proper encodings to lib/encodings and languages to lib/languages. Then you need to fix the frontend that all encodings from lib/encodings can be selected, currently the list is hardcoded in src/frontends/qt4/QDocumentDialog.C. I did it and I got PDF DVI with Croatian chars on my utf-8 locale. However, after running Lyx, I see: [EMAIL PROTECTED] ~/tmp $ /usr/local/bin/lyx Unknown encoding utf-8 The table passed to LyXLex is not sorted! Tell the developers to fix it! in console. What's missing? In case of segfaults, should I send backtraces here or to bugzilla? Sincerely, Gour
Re: small reorganization of graphics dialog
Edwin == Leuven, E [EMAIL PROTECTED] writes: Edwin JML à dit: Personally, I would put the show in LyX part at the bottom. Edwin i ended up putting it under the extra tab: Excellent. JMarc
Bug 2960: Inserting an URL cause latex/pdflatex failure
More lyx-1.5svn testing:
Insert a URL into the document, fill in the URL field with
http://www.free-firewall.org
Try view-pdflatex or view-latex,
get the error message
Undefined control sequence \url{http://www.free-firewall.org}
Re: LyX 1.5 translations
Lars Gullik Bjønnes wrote: Helge Hafting [EMAIL PROTECTED] writes: | Michael Gerz wrote: | Lars Gullik Bjønnes wrote: | | IMHO we should not merge translations from 1.4 at all. (or at most on | a case by case basis. And if translators want it (I don't want it for | NB f.ex.), msgmerge can be used for this.) | | Lars, I am a careful man :-) | | Right now, I am checking the state of the 1.4 and 1.5 translations | on a case-by-case basis. If the 1.4 translations are better (for | many languages they are significantly better!), I will remerge. | Otherwise, I won't. | | I will put nb.po on my black list. | Any particular problem with nb.po? Helge Hafting No. Only that it is missing translations and have a few fuzzy entries. I am working slowly on them help would be appreciated. I can look at it, like I did for 1.3. It should be simpler now, with only one frontend. Should I start with the nb.po that is in lyx1.5svn right now, or should I wait for some merge from 1.4? Helge Hafting
Re: small reorganization of graphics dialog
On Thursday 02 November 2006 1:31 pm, Leuven, E. wrote: moreover, this way we avoid clutter on the dialog (presenting too many options at once) while having the main output options (the ones we care about most) on the first tab. i think this makes sense in a common use context, and i like it opinions? (patch attached.) If no one shouts until tomorrow you can put in. -- José Abílio
Re: Alpha release until monday 6. November
On Thu, 2 Nov 2006, José Matos wrote: Sad to see that I couldn't infect the others with my enthusiasm, seem the developers of LyX are more boring and inflexible than I thought. You are young lad. :-) And how old are you? :-) (I'm 33 btw - is that old or young :-) Anyway, as I've been confused now... when was the planned released date? (I'm guessing Christmas of course) /C -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: My Big Fat (Greek?) Cursor
On Thu, Nov 02, 2006 at 12:58:32PM +0100, Helge Hafting wrote: You have a point. Ideally, we should use native widgets. But only if they are good enough for our use. If not, then rolling our own makes lyx better. The alternative to our own cursor then is not to use a bad widget, but to actually fix qt4. I find it hard to believe that we are so very special that the rich ability to use native widgets is not enough for us... regards john
RE: small reorganization of graphics dialog
José wrote: If no one shouts until tomorrow you can put in. ok, will do...
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Peter Kümmel wrote:
| | | A other solution is to somehow handle within the views which
| part
| | of the buffer is viewed.
| | | This is what we have already: Each LyXView (WorkArea really) has
| its
| | own unique BufferView which is a view of one part of the document.
| | Except for some cursor bug (the famous dEPM bug), this is working fine.
| ..except that metrics is shared between views.
|
| This should not be. Each BufferView now has its own CoordCache. If
| there's still something shared, this should be fixed.
|
|
| (And this fails miserably when the windows are of different widths.)
|
| The problem is different here. I believe that there's some cursor
| interaction problem that leads. This leads to crashes but most of the
| time, if you have two BufferView sharing the same Buffer, changing the
| geometry of one does not impact the other one (except if there's some
| editing that invalidated the cursor of the other BufferView).
Just try it for yourself and you will see.
As I said, the problem is not related to metrics but to a bad paragraph
model. More exactly this (in paragraph.h):
/// LyXText updates the rows using this access point
RowList rows() { return rows_; }
/// The painter and others use this
RowList const rows() const { return rows_; }
This is really, really _wrong_, a paragraph should not have any notion
of rows. By modifying the geometry of the windows (the BufferView) you
also modify the model (the Buffer) because the rows() information is not
valid any more.
rows is a RowList, that is a vector of row:
/**
* Each paragraph is broken up into a number of rows on the screen.
* This is a list of such on-screen rows, ordered from the top row
* downwards.
*/
typedef std::vectorRow RowList;
Georg is right, the LyX core is not ready for Multiple-view. There's too
much that needs to be re-designed. So either someone steps up and
cleanup that mess by putting the rows calculation outside of the Buffer
or we disable the multi-windows feature.
Abdel.
Re: Coord cache and single par update
Martin Vermeer wrote:
On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote:
Martin Vermeer wrote:
Note that the job will be easier if stale caches are not covered up by
the current overzealous full-screen refresh behaviour. I suggest getting
rid of that first.
The full refresh thing is due to the cursor bug. I will work on it as
soon as I find some free time.
Abdel.
Are you sure? That would be great.
Yes I'm sure. The attached patch fixes the full screen refresh on cursor
blinking.
Unfortunately, there are some bad side effects. As I explained earlier,
there is no backing pixmap any more as we draw directly on screen. This
is the reason why I need to back-up the cursor area in order to restore
it when the cursor is hidden (this is not yet working with this patch).
Because of this also, when the widget loose the focus, the screen is not
redrawn any more. This can be taken care of by caching the screen estate
when we catch a Focus Out event. But at this point there is too much
work to turn around the refresh problem. So the only pragmatic solution
is to restore the backing pixmap.
Abdel.
Index: GuiWorkArea.C
===
--- GuiWorkArea.C (revision 15685)
+++ GuiWorkArea.C (working copy)
@@ -39,7 +39,6 @@
#include QMimeData
#include QUrl
#include QDragEnterEvent
-#include QPixmap
#include QPainter
#include QScrollBar
@@ -50,8 +49,10 @@
// On windows-XP the UserGuide PageDown scroll test is faster without event
pruning (16 s)
// than with it (23 s).
#ifdef Q_WS_WIN
+int const CursorWidth = 2;
#define USE_EVENT_PRUNING 0
#else
+int const CursorWidth = 1;
#define USE_EVENT_PRUNING 0
#endif
@@ -181,7 +182,7 @@
GuiWorkArea::GuiWorkArea(int w, int h, int id, LyXView lyx_view)
- : WorkArea(id, lyx_view)
+ : WorkArea(id, lyx_view), exposed_(false)
{
cursor_ = new frontend::CursorWidget(this);
cursor_-hide();
@@ -596,7 +597,15 @@
}
//lyxerr real drawing endl;
- paintText(*buffer_view_, pain);
+ if (!exposed_) {
+ paintText(*buffer_view_, pain);
+ exposed_ = true;
+ }
+
+ if (!cursor_-on_) {
+ const QRect r = cursor_-geometry();
+ pain.drawPixmap(r.x(), r.y(), cursor_area_);
+ }
}
@@ -604,14 +613,16 @@
void GuiWorkArea::expose(int x, int y, int w, int h)
{
update(x, y, w, h);
+ exposed_ = false;
}
void GuiWorkArea::showCursor(int x, int y, int h, CursorShape shape)
{
- cursor_-setGeometry(x, y, 2, h);
+ cursor_-setGeometry(x, y, CursorWidth, h);
cursor_-shape_ = shape;
cursor_-on_ = true;
+ cursor_area_ = QPixmap::grabWidget(this, x, y, CursorWidth, h);
cursor_-show();
}
@@ -621,6 +632,7 @@
if (!qApp-focusWidget())
return;
cursor_-hide();
+ cursor_-on_ = false;
}
Index: GuiWorkArea.h
===
--- GuiWorkArea.h (revision 15680)
+++ GuiWorkArea.h (working copy)
@@ -23,6 +23,7 @@
#include QResizeEvent
#include QKeyEvent
#include QTimer
+#include QPixmap
#include queue
@@ -179,6 +180,10 @@
CursorShape cursor_shape_;
///
CursorWidget * cursor_;
+ ///
+ bool exposed_;
+ ///
+ QPixmap cursor_area_;
};
} // namespace frontend
Re: [Final PATCH] session/toolbar
Dear all, The session/toolbar patch have been committed to the trunk. Please test and comment. Features to test: 1. turn toolbar on/off, move it around, and see if session can restore them correctly. 2. view-toolbar toggle on/off, and in the math/table/review cases, toggle on/off/auto. You may notice that I do not actually intercept qt toolbar menu. As a result, toolbar right-click can not set 'auto' state, and the changes it triggers does not penetrate to view-toolbars. (view-toolbars does update toolbars). I do not see this as a big problem since we can tell users that toolbar right-click changes are sort of temporary, while view-toolbars can set advanced states like AUTO. That said, Qt4 developers can try to replace toolbar right-click menu with view-toolbars and solve the problem. I have no idea how that may be done. Another potential solution is that when view-toolbar says 'turn off toolbar', we remove the toolbar altogether so qt can not switch to it. As I have said, I will be on vacation starting Saturday so please bring up any issue before it. Cheers, Bo
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Georg is right, the LyX core is not ready for Multiple-view. There's too much that needs to be re-designed. So either someone steps up and cleanup that mess by putting the rows calculation outside of the Buffer or we disable the multi-windows feature. I would be really disappointed to see mutlti-view gone. It is the biggest feature I would like to have in 1.5.x. You see, if it does not come with 1.5.0, then it will be too big for 1.5.x and we have to wait till 1.6 ... People who knows lyx-core better please help. Bo
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Bo Peng wrote: Georg is right, the LyX core is not ready for Multiple-view. There's too much that needs to be re-designed. So either someone steps up and cleanup that mess by putting the rows calculation outside of the Buffer or we disable the multi-windows feature. I would be really disappointed to see mutlti-view gone. It is the biggest feature I would like to have in 1.5.x. You see, if it does not come with 1.5.0, then it will be too big for 1.5.x and we have to wait till 1.6 ... People who knows lyx-core better please help. If this is really wanted there's two solutions: 1) make sure that the two windows size (the BufferView) are exactly the same size. 2) Instead of multi-window we could implement the multi-workarea within one window using the TabWidget solution I have outlined earlier. Then, we will be sure that two BufferView of the same Buffer would have the exact same size. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
1) make sure that the two windows size (the BufferView) are exactly the same size. 2) Instead of multi-window we could implement the multi-workarea within one window using the TabWidget solution I have outlined earlier. Then, we will be sure that two BufferView of the same Buffer would have the exact same size. What is TabWidget? I will be satisfied with a split (vertical or horizontal) window option, even if there are at most two windows, and the split has to be half half. Bo
Re: [Final PATCH] session/toolbar
Bo Peng wrote: Dear all, http://www.lyx.org/trac/changeset/15688 As far as I can tell, I have solved the three state toolbar chaos completely by introducing this view-toolbar menu and LFUN_TOOLBAR_TOGGLE_STATE lfunc. If there is no objection, I will apply both patches tomorrow to attract more testing. Interested people can test the patches using svn merge -r 15686:15688 svn://svn.lyx.org/lyx/lyx-devel/branches/personal/bpeng If all goes well, I may be able to enjoy my vacation without thinking of lyx. :-) Bo The popup could be disabled by reimplementing createPopouMenu in GuiView.C http://doc.trolltech.com/4.2/qmainwindow.html#createPopupMenu You could try returning just a QMenu() or QWidget() to disbale the popup. -- Peter Kümmel
RE: General ideas and feedback.
Draciron wrote: Greetings... greetings Also excuse my breach in ettiquete. I'm not a patient man :) don't worry, neither are we (or me at least) ... (i will try to answer some of your questions, where i can) First is the editor won't let me use the enter key to create my own sense of formating. This is rather irritating. Very annoying actually. use word/openoffice/abiword? the basic philosophy behind lyx is to get rid of manual formatting and focus on content instead... Now I'm stuck in indent hell. Nor can I manually add a blank line between paragraphs. I am sure there is a formating option to do this ctrl+enter or File-Paragraph Settings but I disagree with the default design. what would you propose? I could not find a word count utility. update to 1.4 I do like the bookmarks concept. That is very important in a long document. we are glad you like them The built in Thesaurus is also a very essential and good idea. great The Index feature is also well done. i start to like your mail... Though I would love to use 2 different indexes, One a timeline index, the other a conventional index. i am not sure you might find a developer interested in your timeline (more on this below) I very much like the notes feature that you have. That is very well done. thanks The built in revision control is a nice feature thanks, it will be improved in 1.5 Now to explain what led me to try LyX. we're listening... When I write I don't know any more than the reader how the story ends. you write emails like that too? When I write it's like I open a window to a world and I'm doing my best to keep up with the events as they happen and translate enough shorthand to later go back and add in detail. are you doing drugs? I can pump out hundreds of pages of these in week. wow The detail side is tedious and takes months. In both cases a crucial part of the process is the timeline. If the story does not involve a very sequential series of events then it is quite easy to get out of synch. This can of course be very disconcerting to the reader if not corrected. Disconcerting to the author as well. The best example is one from a series of books most Linux users have probably read. The Lord of the Rings that is. i must admit that i've read it, although i was young at the time (i know, i know, it's no excuse...) Different authors use different means to deal with timelines. Some cover thier walls in giant structures of notes. (btw, lyx features a spellchecker) Most today use pen and paper, often creating folders which with many artifacts besides the timeline. Few do this on a computer today becuase there are few applications that do a very good timeline and no software actually supports built in timelines. it sounds really complicated and i can imagine that the market for this is rather small. unless a developer needs this himself and finds a way of implementing it in a clean way, i don't see this feature coming to lyx very soon... I dispise VI and Emacs. i understand, i am a notepad guy myself... I'm sorry I hate those two editors. that's okay. just let it out... Anyway I use Kedit since it's lightweight, has all the basic editing functions I need for my primary writing. ah I use little in the way of text formating. [snip] [snip] [snip] [snip] [snip] sorry, but you (i) kinda got lost in the details there... For me I'd rather have a row of tabs much like done in Kate or Firefox. it looks like this is going to be added to 1.5 which is in the works now, These would be the chapters or other customizable means of organization allowing you to group documents in one or more of the tabs. Then each tab would have a tab for each document in that chapter/group. but no nested tabs i am afraid... For me the ideal writing system [snip] [snip] For example in my first novel, a work of Fantasy, there is a critical battle that shapes the future of the hero of the story. sounds like my first time on lyx-devel... I refered back to that battle many times in the course of the book. and i kinda try to forget my battles The description of the village which the hero came from was another couple pages I constantly refered back too as was encounters with critical charactors, a 2nd battle much later in the book and the meeting of his true love. aha Formating is important and depending on what you are doing and who it is for that can vary. Many places want plain text. Some places only accept paper copies. Some will not even read formated text, some expect the formating to already be in there. Some want your text submited as Word files, some as plain text, some as Word Perfect, some as HTML and a few will accept a few formats including RTF. The lack of export support is a potential issue though I'm sure I could export to text then import in Abiword or Open Office. Might even be able to save the formating
Re: [Final PATCH] session/toolbar
The popup could be disabled by reimplementing createPopouMenu in GuiView.C This will be less confusing indeed. But do people in general agree to remove it? Bo
Re: Coord cache and single par update
On Thu, Nov 02, 2006 at 04:57:09PM +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: Note that the job will be easier if stale caches are not covered up by the current overzealous full-screen refresh behaviour. I suggest getting rid of that first. The full refresh thing is due to the cursor bug. I will work on it as soon as I find some free time. Abdel. Are you sure? That would be great. Yes I'm sure. The attached patch fixes the full screen refresh on cursor blinking. Confirmed, thanks. I suppose this will already help Bennett. Unfortunately, there are some bad side effects. As I explained earlier, there is no backing pixmap any more as we draw directly on screen. This is the reason why I need to back-up the cursor area in order to restore it when the cursor is hidden (this is not yet working with this patch). Because of this also, when the widget loose the focus, the screen is not redrawn any more. This can be taken care of by caching the screen estate when we catch a Focus Out event. But at this point there is too much work to turn around the refresh problem. So the only pragmatic solution is to restore the backing pixmap. Abdel. Hmmm. I see still that the whole screen is refreshed even for a character insert. I also notice that when I comment out the updateMetrics(false) call in WorkArea::redraw, this whole-screen refresh doesn't happen any more, which is good. But... the non-redrawn areas of the screen are blanked out. Are you saying this is due to the backing pixmap issue? Just trying to understand... - Martin pgp4ORldxfKKa.pgp Description: PGP signature
Re: Coord cache and single par update
Martin Vermeer wrote: On Thu, Nov 02, 2006 at 04:57:09PM +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote: Martin Vermeer wrote: Note that the job will be easier if stale caches are not covered up by the current overzealous full-screen refresh behaviour. I suggest getting rid of that first. The full refresh thing is due to the cursor bug. I will work on it as soon as I find some free time. Abdel. Are you sure? That would be great. Yes I'm sure. The attached patch fixes the full screen refresh on cursor blinking. Confirmed, thanks. I suppose this will already help Bennett. Well, this is not ready yet and I suspect that there's more work to make it run correctly than the work to go back to the backing pixmap solution. Unfortunately, there are some bad side effects. As I explained earlier, there is no backing pixmap any more as we draw directly on screen. This is the reason why I need to back-up the cursor area in order to restore it when the cursor is hidden (this is not yet working with this patch). Because of this also, when the widget loose the focus, the screen is not redrawn any more. This can be taken care of by caching the screen estate when we catch a Focus Out event. But at this point there is too much work to turn around the refresh problem. So the only pragmatic solution is to restore the backing pixmap. Abdel. Hmmm. I see still that the whole screen is refreshed even for a character insert. I also notice that when I comment out the updateMetrics(false) call in WorkArea::redraw, this whole-screen refresh doesn't happen any more, which is good. But... the non-redrawn areas of the screen are blanked out. Are you saying this is due to the backing pixmap issue? The screen refresh for a character insert is due to the missing singlePar update use case that you complained already; nothing to do with the pixmap issue. But the blanked out of the non-redrawn areas is indeed due the backing pixmap issue. Abdel.
Re: Let us remove the multi-window support ! (was Re: About New TabBar and Multiple-Windows)
Bo Peng wrote: 1) make sure that the two windows size (the BufferView) are exactly the same size. 2) Instead of multi-window we could implement the multi-workarea within one window using the TabWidget solution I have outlined earlier. Then, we will be sure that two BufferView of the same Buffer would have the exact same size. What is TabWidget? I will be satisfied with a split (vertical or horizontal) window option, even if there are at most two windows, and the split has to be half half. Here is some explanations that I wrote earlier: 1) The Model: Buffer The Buffer is the in-memory representation of a LyX file format. The Buffer does not (should not) have any information on what part of it is represented on screen. There is one unique Buffer per opened LyX file. 2) The Controller: BufferView/Painter The BufferView is a tool used by the view that translates a part of the Buffer contents into drawing routines. The BufferView asks each inset of the Buffer to draw itself onto the screen using the Painter. There is only Buffer loaded per BufferView. While there is the possibility to switch Buffer inside the BufferView, the goal is to instantiate a new BufferView on each Buffer switch. The Painter is just a virtual interface to formalize each kind of drawing routines (text, line, rectangle, etc). The BufferView also contains a Cursor which may or may not be visible on screen. The cursor is really just a bookmark to remember where the next Buffer insertion/deletion is going to take place. 3) The View: WorkArea (and it's qt4 specialisation GuiWorkArea) This contains the real screen area where the drawing is done by the Painter. One WorkArea holds one unique BufferView. While it could be possible that multiple WorkArea share one BufferView, this is not possible right now. The WorkArea also provide a scrollbar which position is translated into scrolling command to the inner BufferView. The WorkArea use the BufferView to translate each keyboard or mouse events into terms that the Buffer can understand: - insert/delete char - select char - etc. 4) The Window: LyXView (and its qt4 specialisation GuiView) This is a full window containing a menubar, toolbars, a tabbar and a WorkArea. One LyXView could in theory contain multiple WorkArea (ex: with split window) but this number is limited to one only for now. In any case, there would be only one WorkArea that gets the focus at a time. Now, concerning the TabBar versus TabWidget issue. Right now, there is only one WorkArea and the TabBar just used to tell the BufferView inside the WorkArea to switch to this another Buffer. With a TabWidget, each Tab would own its own WorkArea. Clicking on a tab would switch a WorkArea instead of a Buffer. That's all, I hope my English is clear enough and that helps some of you better understand the global picture. Back to my real work. Abdel.
Re: General ideas and feedback.
Leuven, E. wrote: Draciron wrote: Greetings... greetings Also excuse my breach in ettiquete. I'm not a patient man :) don't worry, neither are we (or me at least) Very funny post Edwin... you offered me 5 minutes of laughing and I needed that today :-) Abdel.
amsart-plain.layout and a question
Hi, I notice the following small bug in amsart-plain.layout: Input amsart.layout - Input amsdef.inc - Input ammsmath.inc Input amsmaths-plain.inc Thus both Theorem and Theorem* appear in the layout combobox, which is not useful, and if you choose both you get a LaTeX error as they define the same newtheorem*. Now my question. As I don't like very much the layout combobox, I wrote my own ui files containing all the layouts of the five main classes I generally use. Does there is a way to have active in the menus only the layouts which are in the class used by the document (and not all the layout appearing in the ui file)? Philippe Charpentier
Re: [Final PATCH] session/toolbar
Bo Peng wrote: This will be less confusing indeed. But do people in general agree to remove it? I do. I think the popup is just not suited for our needs, as opposed to your menu entry (apparently -- I didn't have time to have a look at it yet). Jürgen
Re: [Final PATCH] session/toolbar
The popup could be disabled by reimplementing createPopouMenu in GuiView.C http://doc.trolltech.com/4.2/qmainwindow.html#createPopupMenu You could try returning just a QMenu() or QWidget() to disbale the popup. OK. Peter, could you please remove this popup for me? It will take me much longer than you to do this. Also, if there is no other way to turn on/off toolbar than view-toolbar, Toolbar::Flags then reflects the true status of toolbars. View-Toolbar can then be made prettier. I will do that later. Cheers, Bo
Re: [Final PATCH] session/toolbar
OK. Peter, could you please remove this popup for me? It will take me much longer than you to do this. Yes, I could do it in the next days. Maybe I try to add the Auto option instead of removing the complete popup. Also, if there is no other way to turn on/off toolbar than view-toolbar, Toolbar::Flags then reflects the true status of toolbars. View-Toolbar can then be made prettier. I will do that later. When I evtl. add the Auto option, I will make sure that the menu is always up to date. Peter
Re: [Final PATCH] session/toolbar
When I evtl. add the Auto option, I will make sure that the menu is always up to date. Yes, just remember to update ToolbarBackend::Flags so MenuBackends::expandToolbars() can get the correct status. Thanks. Bo
Re: General ideas and feedback.
On Thursday 02 November 2006 2:53 pm, Draciron wrote: Useing the scrollwheel in file selections breaks the file selection box. I am using a Logictech trackball on FC3. Known problem with xforms, the qt-frontend does not have this problem. -- José Abílio
Re: [Final PATCH] session/toolbar
Yes, I could do it in the next days.
Maybe I try to add the Auto option instead of removing the complete
popup.
Since ToolbarBackend::Flags will always reflect the true toolbar
status, I have modified the view-toolbars display as
standard etc, two states:
on standard
off standard
review etc, three states
on review
off review
review (auto)
Committing now.
Bo
Index: src/lyxfunc.C
===
--- src/lyxfunc.C (revision 15691)
+++ src/lyxfunc.C (working copy)
@@ -573,6 +573,13 @@
break;
}
+ case LFUN_TOOLBAR_TOGGLE_STATE: {
+ ToolbarBackend::Flags flags =
lyx_view_-getToolbarState(to_utf8(cmd.argument()));
+ if (!(flags ToolbarBackend::AUTO))
+ flag.setOnOff(flags ToolbarBackend::ON);
+ break;
+ }
+
// this one is difficult to get right. As a half-baked
// solution, we consider only the first action of the sequence
case LFUN_COMMAND_SEQUENCE: {
@@ -635,7 +642,6 @@
case LFUN_BUFFER_PREVIOUS:
case LFUN_WINDOW_NEW:
case LFUN_WINDOW_CLOSE:
- case LFUN_TOOLBAR_TOGGLE_STATE:
// these are handled in our dispatch()
break;
Index: src/frontends/LyXView.h
===
--- src/frontends/LyXView.h (revision 15691)
+++ src/frontends/LyXView.h (working copy)
@@ -136,6 +136,8 @@
/// update the toolbar
void updateToolbars();
+ /// get toolbar state
+ ToolbarBackend::Flags getToolbarState(std::string const name);
/// toggle toolbar state
void toggleToolbarState(std::string const name);
/// update the menubar
Index: src/frontends/Toolbars.C
===
--- src/frontends/Toolbars.C(revision 15691)
+++ src/frontends/Toolbars.C(working copy)
@@ -129,6 +129,21 @@
}
+ToolbarBackend::Flags Toolbars::getToolbarState(string const name)
+{
+ ToolbarBackend::Toolbars::const_iterator cit = toolbarbackend.begin();
+ ToolbarBackend::Toolbars::const_iterator end = toolbarbackend.end();
+
+ for (; cit != end; ++cit) {
+ if (cit-name == name)
+ return cit-flags;
+ }
+
+ lyxerr[Debug::GUI] Toolbar::display: no toolbar named
+name endl;
+}
+
+
void Toolbars::toggleToolbarState(string const name)
{
ToolbarBackend::Toolbars::iterator cit = toolbarbackend.begin();
@@ -154,9 +169,11 @@
TurnOnFlag(ON);
}
cit-flags =
static_castlyx::ToolbarBackend::Flags(flags);
- break;
+ return;
}
}
+ lyxerr[Debug::GUI] Toolbar::display: no toolbar named
+name endl;
}
#undef TurnOnFlag
#undef TurnOffFlag
Index: src/frontends/LyXView.C
===
--- src/frontends/LyXView.C (revision 15691)
+++ src/frontends/LyXView.C (working copy)
@@ -305,6 +305,12 @@
}
+ToolbarBackend::Flags LyXView::getToolbarState(string const name)
+{
+ return toolbars_-getToolbarState(name);
+}
+
+
void LyXView::toggleToolbarState(string const name)
{
// it is possible to get current toolbar status like this,...
Index: src/frontends/Toolbars.h
===
--- src/frontends/Toolbars.h(revision 15691)
+++ src/frontends/Toolbars.h(working copy)
@@ -88,6 +88,9 @@
/// Show/hide the named toolbar.
void display(std::string const name, bool show);
+ /// get toolbar state (on/off/auto)
+ ToolbarBackend::Flags getToolbarState(std::string const name);
+
/// toggle the state of toolbars (on/off/auto)
void toggleToolbarState(std::string const name);
Index: src/MenuBackend.C
===
--- src/MenuBackend.C (revision 15691)
+++ src/MenuBackend.C (working copy)
@@ -768,17 +768,16 @@
int i = 1;
for (; cit != end; ++cit, ++i) {
docstring label = convertdocstring(i) + . + _(cit-name);
- // frontend does not update ToolbarBackend::flags when it
changes toolbar
- // Therefore, I can not tell from the flags if the toolbar is
on or off
- // it is then less confusing to say:
- // this is: always on/off/auto
- // frontend toolbar change is temporary.
+ // frontends are not supposed to turn on/off toolbars, if they
can not
+ // update ToolbarBackend::flags. That is to say,
ToolbarsBackend::flags
+ // should reflect the true state of toolbars.
//
- if
Status: 3 hopeless showstoppers + more
Hi, More bugs are being reported recently, and none of the old ones have been fixed. Thus, we are moving in the wrong direction. Showstoppers without hope: - Selection with the mouse. Does not work in math nor in tables. It kind of works in insets, although problems have been reported with this as well. To reproduce, make a formula or a table, type some text and try to select it with the mouse. We need a volunteer to investigate this. - Crashes with multiple windows open. It seems that Buffer contains Rows of paragraphs, and this is no good in a multiple view setting. Options: a) Rework Buffer to not have Rows (big change, risky), b) Disable multiple views completely for now, c) Disable multiple views of same document only. Seems to me option C would be safe and still provide some benefit to the user. - Cursor trouble: Full refresh on each blink. Abdel says it's a lot of work to fix this without the pixamp. Options a) Spend that time, b) Revert to old painting scheme. Given that the removal of the pixmap did not give us any noticable speed-up, I think we should revert this change which was done the last Monday of the meeting. Showstoppers with hope: - In math the cursor blinks at the start of the math inset and then seems to go the correct place afterwards. I suggest that Peter's patch which disables immediate cursor updates is applied, unless someone can track down the bug in the math code. Other problems without hope: - Mac is unusable because of poor performance, among other things. Options: a) Revert commit from 14th of July which disabled partial refresh. This is a little dangerous, since it is known that this might cause invalid coord cache entries. b) Do a), but also implement partial coord cache refresh to make it safe. c) Implement a caching painting scheme, such that only changed paint requests are done. - No UTF-8 support in LaTeX export. - Nice icons in change tracking missing. Other problems with hope: - Copy/paste using middle mouse button inserts musical notes. - Branches are not unicode clean. Reported by Helge. - URLs in documents causes LaTeX error. Reported by Helge. Change tracking is being worked on, and will be done before the 14th. The tab bar work is settling down. I think all other pending patches have all been applied, but it's difficult to keep track off. We have a bunch of problems without any hope. At the same time, people are getting too busy to work on LyX. So, the future does not look too bright for LyX. In other words, we are back in deep shit again. Therefore, I would suggest to freeze the code even more until progress has been made on the hopeless showstoppers. We have some difficult problems to solve, and those will require a concentrated effort to nail. The positive side to this is that each person who conquers a hopeless showstopper is instantly a hero. Regards, Asger
Re: [Final PATCH] session/toolbar
On Fri, Nov 03, 2006 at 10:13:47AM +1800, Bo Peng wrote: The session/toolbar patch have been committed to the trunk. Please test and comment. Good work, Bo ;-) Some comments: - The status of the toolbars can only be changed when a document is loaded. - Changing the status of a toolbar modifies the changed status of the document. - Maybe the toolbars should not be numerated in the menu and their first letter capitalized. - The position of the toolbars can be changed and session remembers the settings, but perhaps at least the minibuffer could appear at the bottom by default. I think you solved brilliantly the problem and I like it very much. -- Enrico
Re: [Final PATCH] session/toolbar
On Thu, Nov 02, 2006 at 09:00:45PM +0100, Enrico Forestieri wrote: - The status of the toolbars can only be changed when a document is loaded. - Changing the status of a toolbar modifies the changed status of the document. - Maybe the toolbars should not be numerated in the menu and their first letter capitalized. All of these, plus: When you first turn 'on' a toolbar it should turn on permanently. So the order should be: Off - On - Auto - Off It's very disconcerting to select a toolbar and not have it appear. But yes, great work... - The position of the toolbars can be changed and session remembers the settings, but perhaps at least the minibuffer could appear at the bottom by default. Is stuff in .ui ignored? It should default to bottom. regards john
Re: Status: 3 hopeless showstoppers + more
On Thu, Nov 02, 2006 at 08:28:45PM +0100, Asger Ottar Alstrup wrote: More bugs are being reported recently, and none of the old ones have been fixed. Thus, we are moving in the wrong direction. Or people have been doing some testing... regards john
mail size and attachments for the mailinglist
hello! two days ago i wrote a mail to the list with subject svg4lyx and i got it via the list, but it doesn't show up in the list archive and nobody answered to it. So i thought that maybe there was a problem because of the size of the mail (it contained some attached files). short about the (lost?) mail: i wrote some python scripts that utilize inkscape for converting svg images to eps, png, and psfrag latex code as well as an external inset template for lyx. did anybody get that mail? thanks bernhard
Re: Status: 3 hopeless showstoppers + more
Asger Ottar Alstrup wrote: Other problems without hope: - Nice icons in change tracking missing. I think we could just take some from the KDE classic iconset, where the other icons are taken from IIRC. Like the attached, for instance. Jürgen icons.tar.gz Description: GNU Zip compressed data
Re: mail size and attachments for the mailinglist
On Thursday 02 November 2006 8:56 pm, Bernhard Roider wrote: hello! Hello, two days ago i wrote a mail to the list with subject svg4lyx and i got it via the list, but it doesn't show up in the list archive and nobody answered to it. So i thought that maybe there was a problem because of the size of the mail (it contained some attached files). True, I have that mail marked as todo, but I had not the time to write back. I am sorry. :-( short about the (lost?) mail: i wrote some python scripts that utilize inkscape for converting svg images to eps, png, and psfrag latex code as well as an external inset template for lyx. did anybody get that mail? I did so I suppose the list got it. Certainly we are interested, I was expecting someone more knowledge to answer (Hello Georg, or Angus). :-) I are preparing an alpha release in a week or so. If you don't get an answer soon please poke us again, we are sometimes slow. :-) Thanks for your feedback Bernhard. :-) thanks bernhard -- José Abílio
Re: Alpha release until monday 6. November
On Thursday 02 November 2006 3:11 pm, [EMAIL PROTECTED] wrote: On Thu, 2 Nov 2006, José Matos wrote: Sad to see that I couldn't infect the others with my enthusiasm, seem the developers of LyX are more boring and inflexible than I thought. You are young lad. :-) And how old are you? :-) 35. :-) (I'm 33 btw - is that old or young :-) It depends. ;-) Anyway, as I've been confused now... when was the planned released date? (I'm guessing Christmas of course) There is no planned release date. In terms of wishes I would like to have the first beta - Tawny, three weeks after the alpha release -Ruby. I would like to have a new beta with a periodicity of three four weeks each. Notice that this is what I would like. In practical terms I would like to fix the details for the next release as soon as we do one, one release at a time that is. :-) /C -- José Abílio
Re: Status: 3 hopeless showstoppers + more
On Thursday 02 November 2006 10:04 pm, Juergen Spitzmueller wrote: Asger Ottar Alstrup wrote: Other problems without hope: - Nice icons in change tracking missing. I think we could just take some from the KDE classic iconset, where the other icons are taken from IIRC. Like the attached, for instance. Could you commit them, please? :-) Jürgen -- José Abílio
Re: Status: 3 hopeless showstoppers + more
Asger Ottar Alstrup wrote: Hi, More bugs are being reported recently, and none of the old ones have been fixed. Thus, we are moving in the wrong direction. Showstoppers without hope: - Selection with the mouse. Does not work in math nor in tables. It kind of works in insets, although problems have been reported with this as well. To reproduce, make a formula or a table, type some text and try to select it with the mouse. We need a volunteer to investigate this. This bug is fixed now. - Crashes with multiple windows open. It seems that Buffer contains Rows of paragraphs, and this is no good in a multiple view setting. Options: a) Rework Buffer to not have Rows (big change, risky), b) Disable multiple views completely for now, c) Disable multiple views of same document only. Seems to me option C would be safe and still provide some benefit to the user. - Cursor trouble: Full refresh on each blink. Abdel says it's a lot of work to fix this without the pixamp. Options a) Spend that time, b) Revert to old painting scheme. Given that the removal of the pixmap did not give us any noticable speed-up, I think we should revert this change which was done the last Monday of the meeting. Showstoppers with hope: - In math the cursor blinks at the start of the math inset and then seems to go the correct place afterwards. I suggest that Peter's patch which disables immediate cursor updates is applied, unless someone can track down the bug in the math code. Other problems without hope: - Mac is unusable because of poor performance, among other things. Options: a) Revert commit from 14th of July which disabled partial refresh. This is a little dangerous, since it is known that this might cause invalid coord cache entries. b) Do a), but also implement partial coord cache refresh to make it safe. c) Implement a caching painting scheme, such that only changed paint requests are done. - No UTF-8 support in LaTeX export. - Nice icons in change tracking missing. Other problems with hope: - Copy/paste using middle mouse button inserts musical notes. - Branches are not unicode clean. Reported by Helge. - URLs in documents causes LaTeX error. Reported by Helge. Change tracking is being worked on, and will be done before the 14th. The tab bar work is settling down. I think all other pending patches have all been applied, but it's difficult to keep track off. We have a bunch of problems without any hope. At the same time, people are getting too busy to work on LyX. So, the future does not look too bright for LyX. In other words, we are back in deep shit again. Therefore, I would suggest to freeze the code even more until progress has been made on the hopeless showstoppers. We have some difficult problems to solve, and those will require a concentrated effort to nail. The positive side to this is that each person who conquers a hopeless showstopper is instantly a hero. Regards, Asger -- Peter Kümmel
Re: New Mac Profile
Abdelrazak Younes [EMAIL PROTECTED] writes: Bennett Helm wrote: I'm now out of my depth. The official binary installs Qt as a bunch of Frameworks (Qt3Support.framework, QtAssistantClient.framework, QtCore.framework, etc), which are folders that include headers and largish (i.e., 3+MB) files named Qt3Support, QtAssistantClient, QtCore, etc.; they do not include any files named, e.g., libQtCore.a, which LyX looks for. So, I don't see how the binaries are going to help. I think these files are the libraries. Yep. Frameworks are folders, you can open them and will see what they contain. Usually QtCore.framework/QtCore should be the dynamic lib. There *might * be a static lib in QtCore.framework/Versions/Current/... but I doubt it. Frameworks are usually shared libs. We just need to update the autotools to look for them in addition to the more unix like libXXX.[so, a]. OMG, easier to switch to CMake. Why do you think they call it autohell ? ;-) But I don't know enought about autotools to help you with that. Maybe scons or CMake have some support for those Qt framework packages? CMake supports frameworks. I used CMake to compile LyX with a manually build Qt/Mac 4.2.1, but got linking errors because I didn't tell CMake to include the -framework ApplicationServices etc. switches. I'll try again soon. Some caveats: * unset QMAKESPEC before doing anything (set by /sw/bin/init.sh) * check in ccmake for undefined symbols and add them manually if needed * toggle advanced mode in ccmake to see all symbols /Andreas
Re: New Mac Profile
Andreas Vox wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: Bennett Helm wrote: I'm now out of my depth. The official binary installs Qt as a bunch of Frameworks (Qt3Support.framework, QtAssistantClient.framework, QtCore.framework, etc), which are folders that include headers and largish (i.e., 3+MB) files named Qt3Support, QtAssistantClient, QtCore, etc.; they do not include any files named, e.g., libQtCore.a, which LyX looks for. So, I don't see how the binaries are going to help. I think these files are the libraries. Yep. Frameworks are folders, you can open them and will see what they contain. Usually QtCore.framework/QtCore should be the dynamic lib. There *might * be a static lib in QtCore.framework/Versions/Current/... but I doubt it. Frameworks are usually shared libs. We just need to update the autotools to look for them in addition to the more unix like libXXX.[so, a]. OMG, easier to switch to CMake. Why do you think they call it autohell ? ;-) This is very good Andrea! I look forward to seeing your profile results ;-) Once you're done you could perhaps update Bennett's recipe for MacOSX? I am sure Peter (the author of the CMake support) would be happy to help you for any request you have. Thanks for the investigation, Abdel.
Re: [patch] new InsetCommandParams
On Thursday 02 November 2006 12:15 pm, Georg Baum wrote: Ozgur Ugras BARAN wrote: Oh, this is bad news, since I have almost completed the multiple indices stuff.. Do you have the code? :-) You can be lucky that the nomencl stuff is allowed at all. I am following the spirit of the law. If your code is small and self-contained I don't have a problem considering it. I am doing this since you have working in the list, you have announced it before, and showed some of it for comment. If for some reason it can be included then we should really focus on smaller development cycles, more focused. We are in good shape for 1.6 since we have a target there, xml file format. A 6 month development cycle would be ideal. Georg -- José Abílio
Re: Bug 2960: Inserting an URL cause latex/pdflatex failure
On Thursday 02 November 2006 2:13 pm, Helge Hafting wrote:
Try view-pdflatex or view-latex,
get the error message
Undefined control sequence \url{http://www.free-firewall.org}
There is a provides(url), or something like this, missing somewhere.
--
José Abílio
Re: Status: 3 hopeless showstoppers + more
On Thu, Nov 02, 2006 at 11:29:04PM +0100, Peter Kümmel wrote: Showstoppers without hope: - Selection with the mouse. Does not work in math nor in tables. It kind of works in insets, although problems have been reported with this as well. To reproduce, make a formula or a table, type some text and try to select it with the mouse. We need a volunteer to investigate this. This bug is fixed now. Afraid not, I've just updated and built, and things are actually a little worse. Insets like Note jump in size between screen-wide and shrink-sized, as well as all the previous selection troubles. regards john
Re: Status: 3 hopeless showstoppers + more
José Matos wrote: Could you commit them, please? :-) Yes, sure. However, I'm (far) away from my Desktop (and tree) now. I'll shove them in during the weekend if nobody objects. Jürgen
Re: Status: 3 hopeless showstoppers + more
On Thursday 02 November 2006 10:57 pm, Juergen Spitzmueller wrote: José Matos wrote: Could you commit them, please? :-) Yes, sure. However, I'm (far) away from my Desktop (and tree) now. I'll shove them in during the weekend if nobody objects. Thank you. This can wait until the weekend, I think. :-) Jürgen -- José Abílio
Re: Status: 3 hopeless showstoppers + more
John Levon wrote: On Thu, Nov 02, 2006 at 11:29:04PM +0100, Peter Kümmel wrote: Showstoppers without hope: - Selection with the mouse. Does not work in math nor in tables. It kind of works in insets, although problems have been reported with this as well. To reproduce, make a formula or a table, type some text and try to select it with the mouse. We need a volunteer to investigate this. This bug is fixed now. Afraid not, I've just updated and built, and things are actually a little worse. Insets like Note jump in size between screen-wide and shrink-sized, as well as all the previous selection troubles. regards john I don't see your strange bug here... Anyway, the patch is correct because before it the button parameter was completes disabled, see log: enable selection with the mouse for math and tables Qt doc for QMouseEvent::button(): Note that the returned value is always Qt::NoButton for mouse move events. so we must use buttons() instead because later on the code checks for the left button. The most recent commit was Abdel's revert to the pixmap painting strategy, maybe this is the reason for your broken notes. -- Peter Kümmel
Re: Status: 3 hopeless showstoppers + more
Asger Ottar Alstrup wrote:
- Crashes with multiple windows open. It seems that Buffer contains Rows
of paragraphs, and this is no good in a multiple view setting. Options:
a) Rework Buffer to not have Rows (big change, risky), b) Disable
multiple views completely for now, c) Disable multiple views of same
document only. Seems to me option C would be safe and still provide some
benefit to the user.
Option d) disable multi-window and implement multiple WorkArea within a
QTabWidget. This will allow to open two tabs showing different part of
the same document. This is a nice work-around of the bad Paragraph row
model as the two BufferView will have a fortiori the same dimensions.
- Cursor trouble: Full refresh on each blink. Abdel says it's a lot of
work to fix this without the pixamp. Options a) Spend that time, b)
Revert to old painting scheme. Given that the removal of the pixmap did
not give us any noticable speed-up, I think we should revert this change
which was done the last Monday of the meeting.
I have now restored the backing pixmap. -dbg painting will print at
the console which area is refreshed.
Showstoppers with hope:
- In math the cursor blinks at the start of the math inset and then
seems to go the correct place afterwards. I suggest that Peter's patch
which disables immediate cursor updates is applied, unless someone can
track down the bug in the math code.
Other problems without hope:
- Mac is unusable because of poor performance, among other things.
Options: a) Revert commit from 14th of July which disabled partial
refresh.
I am afraid this is not possible. The BufferView class has changed a
_lot_ since that time.
This is a little dangerous, since it is known that this might
cause invalid coord cache entries. b) Do a), but also implement partial
coord cache refresh to make it safe. c) Implement a caching painting
scheme, such that only changed paint requests are done.
I won't say this is without hope. This just needs some time to implement
the correct solution. This is for sure not a show-stopper
So, the future does not look too bright for LyX. In other words, we are
back in deep shit again.
Therefore, I would suggest to freeze the code even more until progress
has been made on the hopeless showstoppers. We have some difficult
problems to solve, and those will require a concentrated effort to nail.
What are you talking about? The way I see it, some People are hardly at
work finishing the new features.
The positive side to this is that each person who conquers a hopeless
showstopper is instantly a hero.
I am a hero then:
Author: younes
Date: Thu Nov 2 23:53:10 2006
New Revision: 15695
URL: http://www.lyx.org/trac/changeset/15695
Log:
- restore a backing pixmap painting strategy: the pixmap is drawn at
expose() time.
- the cursor is still a widget, the width is 2-pixel on Windows and
1-pixel on other platforms. The full screen refresh on blinking cursor
bug is now gone.
Modified:
lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C
lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.h
Modified: lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C?rev=15695
==
--- lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C (original)
+++ lyx-devel/trunk/src/frontends/qt4/GuiWorkArea.C Thu Nov 2 23:53:10 2006
@@ -39,7 +39,6 @@
#include QMimeData
#include QUrl
#include QDragEnterEvent
-#include QPixmap
#include QPainter
#include QScrollBar
@@ -50,8 +49,10 @@
// On windows-XP the UserGuide PageDown scroll test is faster without
event pruning (16 s)
// than with it (23 s).
#ifdef Q_WS_WIN
+int const CursorWidth = 2;
#define USE_EVENT_PRUNING 0
#else
+int const CursorWidth = 1;
#define USE_EVENT_PRUNING 0
#endif
@@ -120,7 +121,7 @@
CursorWidget(QWidget * parent)
: QWidget(parent)
{
- resize(2, 20);
+ resize(CursorWidth, 20);
}
void paintEvent(QPaintEvent *)
@@ -165,10 +166,16 @@
}
*/
}
- /// shown?
- bool on_;
///
CursorShape shape_;
+ ///
+ bool show_hcursor_;
+ ///
+ bool show_vcursor_;
+ ///
+ bool lshape_cursor_;
+ ///
+ QColor cursor_color_;
};
@@ -496,6 +503,7 @@
void GuiWorkArea::resizeEvent(QResizeEvent * ev)
{
cursor_-hide();
+ screen_ = QPixmap(ev-size().width(), ev-size().height());
verticalScrollBar()-setPageStep(viewport()-height());
QAbstractScrollArea::resizeEvent(ev);
resizeBufferView();
@@ -554,64 +562,45 @@
void GuiWorkArea::paintEvent(QPaintEvent * ev)
{
- /*
- lyxerr[Debug::GUI] BOOST_CURRENT_FUNCTION
-\n QWidget width\t this-width()
-\n QWidget height\t this-height()
-
Re: Status: 3 hopeless showstoppers + more
On Thursday 02 November 2006 7:28 pm, Asger Ottar Alstrup wrote: - No UTF-8 support in LaTeX export. What needs to be done here? I would like to help fixing it. Any pointers? -- José Abílio
Re: Status: 3 hopeless showstoppers + more
The way I see it, some People are hardly at work finishing the new features. Yeap. With my last update, bookmarks and toolbars should be working well. These features will never be show stoppers so I have no chance to become a hero. :-) I am a hero then: Indeed. Bo
Re: [Final PATCH] session/toolbar
- The status of the toolbars can only be changed when a document is loaded. - Changing the status of a toolbar modifies the changed status of the document. - Maybe the toolbars should not be numerated in the menu and their first letter capitalized. When you first turn 'on' a toolbar it should turn on permanently. So the order should be: Off - On - Auto - Off ALL fixed. - The position of the toolbars can be changed and session remembers the settings, but perhaps at least the minibuffer could appear at the bottom by default. This is where default ui plays a role. I think minibuffer is by default at the bottom right now. Bo
Re: Status: 3 hopeless showstoppers + more
Peter Kümmel wrote: John Levon wrote: On Thu, Nov 02, 2006 at 11:29:04PM +0100, Peter Kümmel wrote: Showstoppers without hope: - Selection with the mouse. Does not work in math nor in tables. It kind of works in insets, although problems have been reported with this as well. To reproduce, make a formula or a table, type some text and try to select it with the mouse. We need a volunteer to investigate this. This bug is fixed now. Afraid not, I've just updated and built, and things are actually a little worse. Insets like Note jump in size between screen-wide and shrink-sized, as well as all the previous selection troubles. I don't see your strange bug here... Me neither. The most recent commit was Abdel's revert to the pixmap painting strategy, maybe this is the reason for your broken notes. I don't think so. This is probably related to some change with regards to Notes widening... I remember someone working on that some time ago. Nothing to do with the painting strategy. Abdel.
