Re: menu structure

Konrad Hofbauer <[EMAIL PROTECTED]> writes: >> For example, LyX users are used to >> having a Document->Settings... Item. They will be disturbed if they have >> to look for one of the most important menu items. > > IMO - no, no, no. If we start to care about legacy, nothing good will > come out.

Re: menu structure

leuven edwin <[EMAIL PROTECTED]> writes: >> I did not know that, I see know. It should not be like this >> (i.e. Inset states should be independent in multiple views >> IMO), but this is another topic... > > collapsed status is also saved in the document (like it or not), so > i have put this in

Re: menu structure

leuven edwin wrote: i like this myself (if I can say that..) I don't. Which HIG does it follow? /Konrad

RE: menu structure

>> collapsed status is also saved in the document (like it or not), so >> i have put this in the file menu for now > > I would not do that. File menu is more for physical state of the > document (so I guess Compressed can belong there). If you do that, why > not put "Insert Table Float" too???

Re: menu structure

leuven edwin <[EMAIL PROTECTED]> writes: >>> collapsed status is also saved in the document (like it or not), so >>> i have put this in the file menu for now >> >> I would not do that. File menu is more for physical state of the >> document (so I guess Compressed can belong there). If you do that,

Re: [patch] bug 1747: fix alignment in fixed width multicolumn cells

On Tuesday 16 September 2008 16:44:58 Jürgen Spitzmüller wrote: > Here's one. Fixes bug 448: > http://bugzilla.lyx.org/show_bug.cgi?id=448 > > Jürgen As soon as you are content with the testing this can go in. -- José Abílio

Preparing for rc3

We are approaching now of the time to have a new release. I am satisfied with a 3/4 weeks period between releases as the testing by users that usually just take a released version is not too far from the trunk head. Asking a user to test if a problem remains one or two weeks later on the new

Re: Handling undo in inset-apply

Pavel Sanda <[EMAIL PROTECTED]> writes: > btw i would be grateful if you can add some commentaries to undo.h, > my question was how recordUndo should be used - the current > commentary says 'prepare' undo as if something should be done to > finish it and the commentary on finishUndo didn't help :)

Re: XML structure thoughts

On Monday 15 September 2008 22:11:12 rgheck wrote: > I don't think so. The existing parser is used to parse InsetTabular > stuff, and that all has an XML format. So the existing parser CAN parse > XML. Not that it's the best choice, but it would do in a pinch. Although I do not have details at

RE: Re: menu structure

> > Maybe, it is a HIG interpretation thing, but I'm seriously doubting > > that the HIG says that content-related stuff like the "Document settings..." > > must be in the File menu. > > Correct. (but I still think it is the right place) > > > Things like page setup do not influence the

RE: menu structure

> - it is very sneaky to remove the View menu again.. Moving all items > from the Window menu into the View menu would ALSO be an option... not sneaky, i just moved the 2 items in the view menu. the window menu was much fuller so i makes sense not to name it view. of course we could

Re: menu structure

Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has "Properties" in File. Both of

Re: menu structure

Konrad Hofbauer wrote: Jean-Marc Lasgouttes wrote: Can you point to a program where _all_ document-level settings are in File menu? We shall not over-interpret the HIG. I do not have much to compare to by hand, only OO 2.3 and Word 2003. Word 2003 has the Page Setup in File, OO has

Re: menu structure

Konrad Hofbauer <[EMAIL PROTECTED]> writes: > Word 2003 has the Page Setup in File, OO has "Properties" in File. > Both of them don't have a Document menu. Both have (a Windows-HIG) > Tools menu. > What is the difference between file and document in the first place ??? In OO File>Properties is

Re: menu structure

[EMAIL PROTECTED] wrote: leuven edwin <[EMAIL PROTECTED]> writes: collapsed status is also saved in the document (like it or not), so i have put this in the file menu for now I would not do that. File menu is more for physical state of the document (so I guess Compressed can belong there). If

Re: menu structure

Konrad Hofbauer <[EMAIL PROTECTED]> writes: >> I only followed the discussion with an eye. Could some nice soul point >> me to the relevant HIG part? > > That is my job ;-) It would be nice to start a wiki page with links to the apple (or vista or...) HIGs for the different parts of the menus.

Re: menu structure

Jean-Marc Lasgouttes wrote: Konrad Hofbauer <[EMAIL PROTECTED]> writes: Word 2003 has the Page Setup in File, OO has "Properties" in File. Both of them don't have a Document menu. Both have (a Windows-HIG) Tools menu. What is the difference between file and document in the first place ???

Re: menu structure

"Vincent van Ravesteijn - TNW" <[EMAIL PROTECTED]> writes: > What if the HIG doesn't have the correct place for these items...? You remove the feature. JMarc

Re: menu structure

Konrad Hofbauer <[EMAIL PROTECTED]> writes: > Forgot (sorry for the noise): > And both don't have any more document-level settings, as far as I can see. Not a Format>Page, by chance? A tools>Language? JMarc

Re: menu structure

On Wed, Sep 17, 2008 at 06:49:05PM +0200, Jean-Marc Lasgouttes wrote: > > And about the discussion if we should merge View and Window - menu: > > Every application I seen on my desktop, all Apple apps, all Mozilla > > apps, OpenOffice, Word 2003 (on XP), ... have a View AND a WINDOW > > menu, and

Re: menu structure

Vincent van Ravesteijn - TNW wrote: Well, I just wanted to make a distinction between content-related and content-unrelated items. (And I chose Document, because LyX has already a Document menu and I do care about legacy, see below) The name "Document" does not really transport the notion of

RE: Re: menu structure

> And I disklike a document-menu: > It breaks the cross-platform HIG concept of File - View - > Window menus, and I do not understand what is the difference > between a file and a document. You may dislike it. I never said it has to be a Document menu; never said that it is very common to have a

Re: menu structure

Jean-Marc Lasgouttes wrote: Konrad Hofbauer <[EMAIL PROTECTED]> writes: Forgot (sorry for the noise): And both don't have any more document-level settings, as far as I can see. Not a Format>Page, by chance? A tools>Language? In that sense, yes, you are right. The question is what we learn

Re: Preparing for rc3

José Matos wrote: > We are approaching now of the time to have a new release. I am satisfied > with a 3/4 weeks period between releases as the testing by users that > usually just take a released version is not too far from the trunk head. > > Asking a user to test if a problem remains one or

Re: menu structure

Vincent van Ravesteijn - TNW wrote: I only reasoned that some of the items did not belong to the place they were put according to the HIG. And to propose something else, I found a common factor and I remembered having a menu in LyX where they might fit in. Sure. Please, be welcome to

RE: Re: menu structure

> Sorry (really), can you please tell me (again) which items you don't see fit? These could be in Document/Tools: [Edit] Spellcheck [Edit] Thesaurus [Edit] Change tracking [File] Statistics This one Document/Format: [File] Document Settings Somewhere else in the File menu: [File] New Window

Re: menu structure

Konrad Hofbauer wrote: > For example, LyX users are used to having a Document->Settings... Item. >They will be disturbed if they have to look for one of the most important menu items. IMO - no, no, no. If we start to care about legacy, nothing good will come out. And it is worth

Re: menu structure

Vincent van Ravesteijn - TNW wrote: > Somewhere else in the File menu: > [File] New Window > [File] Close Window The HIG do not really specify this (I only took that from Firefox and Safari). One could also argue that these two should be in Window. These could be in Document/Tools: [Edit]

Re: menu structure

Konrad Hofbauer wrote: >> Can you point to a program where _all_ document-level settings are in >> File menu? We shall not over-interpret the HIG. > > I do not have much to compare to by hand, only OO 2.3 and Word 2003. > > Word 2003 has the Page Setup in File, OO has "Properties" in File. > Both

Re: menu structure

Pavel Sanda wrote: just to give some feedback the file/document distinction to me as a user is quite clear Can you please (honestly) explain this distinction to me (or define)? I feel like I am missing something here ... and adding the items into file menu looks pretty messy. That is

Re: On tabs and multiple views/windows.

Konrad Hofbauer wrote: Something relevant for the menus, but not quite clear to me (and I believe in parts a bit buggy/inconsistent). Maybe somebody can explain. What I think we should have (conceptually): a) "Files" (=documents) and b) "Views" onto the file (one or more, in various windows

Re: r26432 - /lyx-devel/trunk/src/insets/InsetLabel.cpp

[EMAIL PROTECTED] wrote: Author: lasgouttes Date: Wed Sep 17 18:28:33 2008 New Revision: 26432 URL: http://www.lyx.org/trac/changeset/26432 Log: Fix bug 2746: http://bugzilla.lyx.org/show_bug.cgi?id=2746 References autoupdate is not undone during UNDO operation * InsetLabel.cpp

Re: r26432 - /lyx-devel/trunk/src/insets/InsetLabel.cpp

* InsetLabel.cpp (updateCommand): record undo for each of the label changes (and put everything in a group to make sure it will be undone in one step). That's very nice. Thanks :) Are you aware of other places where this would be needed? What I have to do now is look at

Re: menu structure

Le 17 sept. 08 à 20:27, Konrad Hofbauer a écrit : P.S. On accusing me of fraud / cover up: Have you really worked through to be able to say so ??? I think it should be enough to support my claims once with a proper reference, and

Re: On tabs and multiple views/windows.

Abdelrazak Younes wrote: Konrad Hofbauer wrote: Something relevant for the menus, but not quite clear to me (and I believe in parts a bit buggy/inconsistent). Maybe somebody can explain. What I think we should have (conceptually): a) "Files" (=documents) and b) "Views" onto the file (one or

Re: menu structure

Jean-Marc Lasgouttes wrote: Le 17 sept. 08 à 20:27, Konrad Hofbauer a écrit : P.S. On accusing me of fraud / cover up: Have you really worked through to be able to say so ??? I think it should be enough to support my claims once with

Re: menu structure

Konrad Hofbauer wrote: > Pavel Sanda wrote: >> just to give some feedback the file/document distinction to me as a user >> is >> quite clear > > Can you please (honestly) explain this distinction to me (or define)? > I feel like I am missing something here ... i will try. when i go to the file,

Re: menu structure

Jean-Marc Lasgouttes wrote: > Le 17 sept. 08 ? 20:27, Konrad Hofbauer a écrit : >> P.S. On accusing me of fraud / cover up: Have you really worked through >> >> to be able to say so ??? I think it should be enough to support my claims >>

Re: r26432 - /lyx-devel/trunk/src/insets/InsetLabel.cpp

Jean-Marc Lasgouttes wrote: * InsetLabel.cpp (updateCommand): record undo for each of the label changes (and put everything in a group to make sure it will be undone in one step). That's very nice. Thanks :) Are you aware of other places where this would be needed? I'll try

Re: r26432 - /lyx-devel/trunk/src/insets/InsetLabel.cpp

What I have to do now is look at each of the recordUndoFullDocument and kill them. We need a recordUndoDocumentParams instead. Yes, that would be nice. Backing up the whole document whenever the _view_ of a document changes (counter, etc) is not very clever :-) Where do we do that? I am

Re: Preparing for rc3

On Wed, Sep 17, 2008 at 11:36 AM, José Matos <[EMAIL PROTECTED]> wrote: > We are approaching now of the time to have a new release. I am satisfied > with > a 3/4 weeks period between releases as the testing by users that usually > just > take a released version is not too far from the trunk head.

Re: r26432 - /lyx-devel/trunk/src/insets/InsetLabel.cpp

Jean-Marc Lasgouttes wrote: What I have to do now is look at each of the recordUndoFullDocument and kill them. We need a recordUndoDocumentParams instead. Yes, that would be nice. Backing up the whole document whenever the _view_ of a document changes (counter, etc) is not very clever :-)

RE: [patch] Solving selection painting bugs

> About the new selection painting with your patch: I realize now that > we are back to 1.5 style. The goal in the previous painting was to be > able to differentiate betwen row break and new paragraph within a > selection. > Anyone thinks this has potential (see attachment) ? Or has other

Re: [patch] Solving selection painting bugs

Vincent van Ravesteijn - TNW wrote: About the new selection painting with your patch: I realize now that we are back to 1.5 style. The goal in the previous painting was to be able to differentiate betwen row break and new paragraph within a selection. Anyone thinks this has potential

RE: [patch] Solving selection painting bugs

> We also need to fix the selection painting within Inset. and *of* insets themselves. f.e. if you change the color of selected text to white in preferences you will see that say the numbers of sections stay black (whereas we would then like them white). it would be nice if this type of stuff

RE: [patch] Solving selection painting bugs

> > Anyone thinks this has potential (see attachment) ? > > > > I do :-) > In that case, I added an extra boolean to the Row class saying whether there is an end of paragraph end or a normal end of line. Now, we can experiment with different kinds of painting. Maybe the Apple HIG says

Re: menu structure

Pavel Sanda wrote: i will try. when i go to the file, i'm usually looking for something which has something a) to do with files generally (ie it does not have anything to do with this in file particular. for example open another file.) b) or has something to do with this file - but it

Re: Handling undo in inset-apply

Jean-Marc Lasgouttes wrote: > Pavel Sanda <[EMAIL PROTECTED]> writes: > > sorry for this; when i was implementing graphics groups i have asked > > for the undo stuff and particularly that line you are refering now. > > finally i put there recordUndoFullDocument since the comments in > > undo.h

RE: [patch] Solving selection painting bugs

> > We also need to fix the selection painting within Inset. > > and *of* insets themselves. > > f.e. if you change the color of selected text to white in > preferences you will see that say the numbers of sections > stay black (whereas we would then like them white). it > would be nice if

Re: r26432 - /lyx-devel/trunk/src/insets/InsetLabel.cpp

Le 17 sept. 08 à 22:44, Abdelrazak Younes a écrit : IIUC, whenever BufferParams is changed after touching the Document Settings, the whole document contents is saved because recordUndoFullDocument() is called, isn't it? Yes, it is one of the points I want to look at. I thought you were

Re: [patch] Solving selection painting bugs

Vincent van Ravesteijn - TNW wrote: Anyone thinks this has potential (see attachment) ? I do :-) In that case, I added an extra boolean to the Row class saying whether there is an end of paragraph end or a normal end of line. Now, we can experiment with different kinds

Re: Handling undo in inset-apply

Jean-Marc Lasgouttes wrote: > Pavel Sanda <[EMAIL PROTECTED]> writes: > > btw i would be grateful if you can add some commentaries to undo.h, > > my question was how recordUndo should be used - the current > > commentary says 'prepare' undo as if something should be done to > > finish it and the

Re: [patch] Solving selection painting bugs

Vincent van Ravesteijn - TNW wrote: We also need to fix the selection painting within Inset. and *of* insets themselves. f.e. if you change the color of selected text to white in preferences you will see that say the numbers of sections stay black (whereas we would then like them

Re: Handling undo in inset-apply

i can't remember exactly, maybe it was http://bugzilla.lyx.org/show_bug.cgi?id=5002 this bug seems to be different issue though. Yes, it seems to be different. But what got me started was someone complanigng that LyX was chewing memory with each replace-all operation on a big file. This one

Re: [patch] Solving selection painting bugs

Vincent van Ravesteijn - TNW wrote: Anyone thinks this has potential (see attachment) ? I do :-) In that case, I added an extra boolean to the Row class saying whether there is an end of paragraph end or a normal end of line. Now, we can experiment with different kinds of painting.

Re: [patch] Solving selection painting bugs

We really need transparent colors then. Then compute a selection color for each Inset based on their background color and the selection color. That could be difficult. I'd say it's OK if we loose the initial background color... at least for now... There was a time where insets could have a

Re: Handling undo in inset-apply

Le 17 sept. 08 à 23:14, Pavel Sanda a écrit : Sure. JMarc

RE: [patch] Solving selection painting bugs

>>> We really need transparent colors then. Then compute a selection >>> color for each Inset based on their background color and the >>> selection color. >> That could be difficult. I'd say it's OK if we loose the initial >> background color... at least for now... > >There was a time where

Re: Preparing for rc3

Bennett Helm wrote: > A couple quick and easy changes for mac.bind and the lyxeditor script in the > Mac bundle should go in (attached). (Note that g is the Mac default for > "search again".) its in. pavel

Re: unicode in math

On Wed, Sep 17, 2008 at 03:52:24PM +0200, G. Milde wrote: > On 16.09.08, Enrico Forestieri wrote: [...] > > Note that in math mode TeX (and even XeTeX) doesn't support anything > > outside the ASCII set, > > This limitation seems more due to technical restrictions than to a > design decision. At

RE: [patch] Solving selection painting bugs

>>> We also need to fix the selection painting within Inset. In your >>> example, the inset should have a blue background, regardless off end >>> of paragraph. That's also to be fixed for mathed. >>> >> >> We really need transparent colors then. Then compute a selection color >> for

RE: Re: menu structure

> I think that either we build something based on likes/dislikes, > or something based on HIGs. In the later case, I am happy to be > involved, in the earlier case I will not be involved very much > (but just as happy). You're right, but: - In the thread it was also mentioned that we would like

Re: menu structure

Vincent van Ravesteijn - TNW wrote: I think that either we build something based on likes/dislikes, or something based on HIGs. In the later case, I am happy to be involved, in the earlier case I will not be involved very much (but just as happy). You're right, but: What follow are all very

Re: Preparing for rc3

On Wed, Sep 17, 2008 at 5:29 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote: > Bennett Helm wrote: > > A couple quick and easy changes for mac.bind and the lyxeditor script in > the > > Mac bundle should go in (attached). (Note that g is the Mac default > for > > "search again".) > > its in. Thanks!

Re: Preparing for rc3

On Wednesday 17 September 2008 18:13:30 Neal Becker wrote: > How is support for XeLaTeX? Absent? :-) -- José Abílio

Re: [patch] Solving selection painting bugs

> Well, that's a pity. Look at Captions, Ragged-Line-Breaks, > LyxMenuSeparators (in the User's guide). They are all painted crappy > (when moving your mouse around them), because they have no color > specified and they do not inherit their parent's color. This means > that > the area cannot be

Re: menu structure

John Levon wrote: > - what the biggest problems are with the current structure Some statistics : first figure is the number of menu items, the second number the total menu + sub-menus + sub-sub-menus items LyX svn blank document with a table File : 17 ; 53 Edit : 17 ; 79 View : 19 ; 55 Insert

RE: [patch] Solving selection painting bugs

>> Well, that's a pity. Look at Captions, Ragged-Line-Breaks, >> LyxMenuSeparators (in the User's guide). They are all painted crappy >> (when moving your mouse around them), because they have no color >> specified and they do not inherit their parent's color. This means >> that the area

Re: menu structure

On Thu, Sep 18, 2008 at 01:03:38AM +0200, [EMAIL PROTECTED] wrote: > 1) The number of items is very big. Do we have any room to grow ? Oowriter > interface is a clone of the old Word interface that was considered a > > 3) There is IMHO useless complexity, like the 7 different preview formats. >

Re: menu structure

Konrad Hofbauer wrote: > Not sure how we proceed from here. hmm if we are in black hole, then lets try to get little back in the discussion. what was the reason to the menu change? imho the fact that users(=we) are discontent with the current menu. so the first thing, the end result has to be

<    1   2