Re: GuiApplication.cpp: compile error

Am 27.05.2008 um 01:34 schrieb Bennett Helm: On Mon, May 26, 2008 at 5:47 PM, Stefan Schimanski <[EMAIL PROTECTED]> wrote: However, the graphic does not display in LyX. It does not? Which OmniGraffle version? Here it work(ed) fine. Have to test again, maybe something broken during all the

Re: [Cvslog] r25108 - in /lyx-devel/trunk/src/frontends/qt4: GuiComple...

[EMAIL PROTECTED] schrieb: Author: broider Date: Wed Jun 4 00:00:47 2008 New Revision: 25108 URL: http://www.lyx.org/trac/changeset/25108 Log: Fix item delegate for qt 4.2: In the completion-listbox rtl-Text does not work like it does for newer qt and icons are not displayed for math symbols.

Re: [PATCH] GuiCompeter problems with qt 4.2.x

Bernhard, will you commit it? I don't see a problem at the moment. Then Dov can work on top of that with the RTL patch. Stefan Am 01.06.2008 um 21:29 schrieb Bernhard Roider: Dov Feldstern schrieb: Bernhard Roider wrote: Hello Stefan, today i finally found some time to investigate the pro

Re: Time for beta 3

On Tuesday 03 June 2008 20:12:00 José Matos wrote: > Hi, > > I will the procedure for the release, so please hold further commits > until > further notice. I missed the verb: drive OK, with the same warnings as beta 2, the new release can be found in the same place. http://www.ly

Time for beta 3

Hi, after considering all that happened and the feedback from the list I have decided to release a new beta 3 today. I do this because all the commits after the beta 2 tagging had the purpose of fixing obvious bugs in beta 2. This will be the last time I will follow this methodo

Re: Beta 2 (private announcement)

On Tuesday 03 June 2008 13:53:39 Pavel Sanda wrote: > for example today is so beautiful sunny day that i can even smell beta3 in > the air don't you think? :)) > pavel I do. :-) I will expand this in a new thread. -- José Abílio

Re: Beta 2 (private announcement)

On Tuesday 03 June 2008 14:17:56 Jean-Marc Lasgouttes wrote: > > > > 2) sounds good as it also convey the information as a "mini-freeze". > > +1 Fair enough. I will try this for the next release. :-) > JMarc -- José Abílio

Re: Beta 2 (private announcement)

On Tue, Jun 3, 2008 at 12:50 PM, Bennett Helm <[EMAIL PROTECTED]> wrote: > On Tue, Jun 3, 2008 at 12:29 PM, Bennett Helm <[EMAIL PROTECTED]> wrote: > >> On Mon, Jun 2, 2008 at 5:02 PM, Konrad Hofbauer <[EMAIL PROTECTED]> >> wrote: >> >>> P.S. I copied the attached script section by section into Te

Re: Beta 2 (private announcement)

On Tue, Jun 3, 2008 at 12:29 PM, Bennett Helm <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 5:02 PM, Konrad Hofbauer <[EMAIL PROTECTED]> > wrote: > >> P.S. I copied the attached script section by section into Terminal. When >> executing or source'ing the script, for some reason configure rep

Re: Beta 2 (private announcement)

On Tue, Jun 3, 2008 at 12:32 PM, Anders Ekberg <[EMAIL PROTECTED]> wrote: > Btw there's one more mall quirk: When opening a new document the top line > is partly hidden by the toolbar, i.e. the crolling i wrong. I think I > remember this being mentioned before, but can't find it in bugzilla. > ht

Re: Beta 2 (private announcement)

On 3 jun 2008, at 18.20, Bennett Helm wrote: - In the tutorial there are some button-figures missing I don't see this. Is it just that the graphics aren't displaying for you? Strange, now it works... Before some figures where replaced by black squares, but now it's fine. Anyway no big deal

Re: Beta 2 (private announcement)

On Mon, Jun 2, 2008 at 5:02 PM, Konrad Hofbauer <[EMAIL PROTECTED]> wrote: > P.S. I copied the attached script section by section into Terminal. When > executing or source'ing the script, for some reason configure reported some > errors. > It seems there were some stray invisible characters in th

Re: An advice for Lyx to support CJK.

Jürgen Spitzmüller-2 wrote: > > steadycookie wrote: >> OK. I understand now. If the CJK commands can be customized to be >> \begin{CJK*}{font} and \end{CJK*}, I think it is OK. This is what I want. >> In Chinese, generally, there is no blanks between characters, even >> between >> chinese chara

Re: Beta 2 (private announcement)

On Tue, Jun 3, 2008 at 12:02 PM, Anders Ekberg <[EMAIL PROTECTED]> wrote: > On 3 jun 2008, at 16.15, Bennett Helm wrote: > > On Tue, Jun 3, 2008 at 9:58 AM, Konrad Hofbauer <[EMAIL PROTECTED]> >> wrote: >> >> Bennett Helm wrote: >>> >>> I can now confirm that it also works on PPC-10.4. >>>

Re: Beta 2 (private announcement)

On 3 jun 2008, at 16.15, Bennett Helm wrote: On Tue, Jun 3, 2008 at 9:58 AM, Konrad Hofbauer <[EMAIL PROTECTED] > wrote: Bennett Helm wrote: I can now confirm that it also works on PPC-10.4. Good. That was with the version that YOU built on 10.5? Yes. I've posted a Mac package here:

Re: Platform-dependent Menu Structure ?

> Except that this is 'info-insert', it works that way indeed. Still, the > possibility to correct/modify the argument should be allowed IMO. A bit like > it is done for the math macro. This feature was designed for document maintainers, so userfriendliness was not among the design goals. >> I d

Re: Platform-dependent Menu Structure ?

Bo Peng wrote: AFAICS, it is not possible to select something inside and InsetInfo. It is also not possible to modify the argument of the InsetInfo. When I type 'inset-insert' in the command buffer followed by enter, I see a red box 'Unknown Info: ' and the cursor is left outside. You sho

Re: Platform-dependent Menu Structure ?

> AFAICS, it is not possible to select something inside and InsetInfo. It is > also not possible to modify the argument of the InsetInfo. When I type > 'inset-insert' in the command buffer followed by enter, I see a red box > 'Unknown Info: ' and the cursor is left outside. You should type things

Re: Platform-dependent Menu Structure ?

Bo Peng wrote: Right. I think InsetInfo should generate this LateX code directly. The intermediate LyX format is not really necessary. It only makes sense for this particular type of InsetInfo. For others, InsetInfo produces a sequences of readonly text and insets so users can select and c

Re: LyX Menu Structure

On Tue, Jun 3, 2008 at 9:55 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > Bo Peng wrote: >> I do not see any trouble in this approach. > > Except that it makes maintenance a bit more difficult, if every new function > will have to be added to 3 menu files. Even with our two files now, new > f

Re: Beta 2 (private announcement)

On Tue, Jun 3, 2008 at 10:41 AM, Konrad Hofbauer <[EMAIL PROTECTED]> wrote: > Bennett Helm wrote: > >> Yes. I've posted a Mac package here: >> >> LyX-1.6.0b2-Mac-Univ..> < >> http://edisk.fandm.edu/bennett.helm/LyX/LyX-1.6.0b2-Mac-Universal.dmg> >> >> Konrad and Anders, could you both test it -- r

Re: Platform-dependent Menu Structure ?

> Right. I think InsetInfo should generate this LateX code directly. The > intermediate LyX format is not really necessary. It only makes sense for this particular type of InsetInfo. For others, InsetInfo produces a sequences of readonly text and insets so users can select and copy part of the co

Re: Platform-dependent Menu Structure ?

Bo Peng wrote: Not necessarily. We can add Painter::icon() method to the painter interface. The magic behind InsetInfo is that 1. This inset holds which information to display 2. During InsetInfo::update(), InsetInfo produces the right LyX structure (text or other insets). 3. These genera

Re: Platform-dependent Menu Structure ?

>> The gain is that the file is determined at runtime. When the ui >> changes (with icon change), there is no need to update our documents >> for it. >> > > This is independent from the inset solution. Our documents use InsetGraphics with files such as ../images/math/matrix.xpm. This is platform

Re: LyX Menu Structure

Bo Peng wrote: > I do not see any trouble in this approach. Except that it makes maintenance a bit more difficult, if every new function will have to be added to 3 menu files. Even with our two files now, new features have often been forgotten to be added to classic.ui. So it only works if thes

Re: Platform-dependent Menu Structure ?

> Not necessarily. We can add Painter::icon() method to the painter interface. The magic behind InsetInfo is that 1. This inset holds which information to display 2. During InsetInfo::update(), InsetInfo produces the right LyX structure (text or other insets). 3. These generated text and insets a

Re: An advice for Lyx to support CJK.

steadycookie wrote: > OK. I understand now. If the CJK commands can be customized to be > \begin{CJK*}{font} and \end{CJK*}, I think it is OK. This is what I want. > In Chinese, generally, there is no blanks between characters, even between > chinese characters and english ones. Could you rephrase

Re: Platform-dependent Menu Structure ?

Bo Peng wrote: I think that if we do that, then there is no gain with this inset. The gain is that the file is determined at runtime. When the ui changes (with icon change), there is no need to update our documents for it. This is independent from the inset solution. Either we ma

Re: Beta 2 (private announcement)

Bennett Helm wrote: Yes. I've posted a Mac package here: LyX-1.6.0b2-Mac-Univ..> Konrad and Anders, could you both test it -- running the installer as well -- to see if it works for you? Works fine here on Intel Mac OS

Re: Platform-dependent Menu Structure ?

> I think that if we do that, then there is no gain with this inset. The gain is that the file is determined at runtime. When the ui changes (with icon change), there is no need to update our documents for it. > Either we manage to display natively the icon through InsetInfo > (meaning it is fast

Re: Platform-dependent Menu Structure ?

Jean-Marc Lasgouttes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: Side note: this is one of my older todo list item but Menu and Toolbar items should someday be unified. There is an Action class already that is used indifferently by Menus and Toolbars, we should generalize this conce

Re: LyX Menu Structure

Bo Peng wrote: 1) Platform-dependent 2) A compromise (=mix) between different HIG 3) Stick to one platform HIG, give a sh.. about the others 4) Do nothing. Each has pros and cons. I would be for 1) if somebody is willing to create the necessary infrastructure in terms of documentation, an for 2

Re: Platform-dependent Menu Structure ?

Bo Peng wrote: I am in the process of adding INFO_SHORTCUTS, adding INFO_ICON should be straightforward. Except that the icon shall be displayed as a graphics, a bit like what InsetGraphics does, but without the delayed loading (especially if we can get the QImage from the toolbar code).

Re: LyX Menu Structure

> 1) Platform-dependent > 2) A compromise (=mix) between different HIG > 3) Stick to one platform HIG, give a sh.. about the others > 4) Do nothing. > > Each has pros and cons. > > I would be for 1) if somebody is willing to create the necessary > infrastructure in terms of documentation, an for 2)

Re: Platform-dependent Menu Structure ?

"Bo Peng" <[EMAIL PROTECTED]> writes: > We are inserting something to the LyX document, so InsetGraphics has > to be used. What we need to do is insert > /usr/local/share/lyx/images/blah.png (platform dependent) when > InsetInfo::update() is called. I think that if we do that, then there is no ga

Re: LyX Menu Structure

Konrad Hofbauer wrote: 1) Platform-dependent 2) A compromise (=mix) between different HIG 3) Stick to one platform HIG, give a sh.. about the others 4) Do nothing. ... > I do not think 2) is users-list-wise such a big issue as long as we keep the names of the menu-entries the same (e.g. "Reco

Re: Platform-dependent Menu Structure ?

>> I am in the process of adding INFO_SHORTCUTS, adding INFO_ICON should >> be straightforward. > > Except that the icon shall be displayed as a graphics, a bit like what > InsetGraphics does, but without the delayed loading (especially if we > can get the QImage from the toolbar code). We are ins

Re: Platform-dependent Menu Structure ?

Abdelrazak Younes <[EMAIL PROTECTED]> writes: > Side note: this is one of my older todo list item but Menu and Toolbar > items should someday be unified. There is an Action class already that > is used indifferently by Menus and Toolbars, we should generalize this > concept and provified an unifie

Re: Beta 2 (private announcement)

Bennett Helm wrote: > If so, that means that you can (and should) build the release > version yourself again, right? > > > Yes, at least to the "can" part. ... And "should" because of the following reason. > That might also solve the crash occurring with George. > > > I hope so. I'm

Re: Platform-dependent Menu Structure ?

"Bo Peng" <[EMAIL PROTECTED]> writes: >> This mechanism exists in 1.6 for bindings and menus. It would be nice >> to know how well it works in practice, though. What is still missing >> is icons. > > What would you use to specify an ICON? I guess InsetInfo::INFO_ICON lfunc? Yes. And make sure it

Re: Beta 2 (private announcement)

On Tue, Jun 3, 2008 at 9:58 AM, Konrad Hofbauer <[EMAIL PROTECTED]> wrote: > Bennett Helm wrote: > >> I can now confirm that it also works on PPC-10.4. >> > > Good. That was with the version that YOU built on 10.5? Yes. I've posted a Mac package here: LyX-1.6.0b2-Mac-Univ..>

Re: Platform-dependent Menu Structure ?

Bo Peng wrote: This mechanism exists in 1.6 for bindings and menus. It would be nice to know how well it works in practice, though. What is still missing is icons. What would you use to specify an ICON? I guess InsetInfo::INFO_ICON lfunc? I am in the process of adding INFO_SHORTCUTS, addi

Re: LyX Menu Structure

Jürgen Spitzmüller wrote: I don't think a mix of different guidelines is what we want. In such a case, rather change it to the Mac HIG for the Mac people, and leave it for Linux as is. I have a rather strong believe that we have four exclusive options and should decide on one and strictly fol

Re: Remove BOOST

Abdelrazak Younes <[EMAIL PROTECTED]> writes: > By the way, I think we should also remove boost from our source and > just say that we depend on boost >= 1.34.0 which is already one year > old. I checked the svn logs and we have no internal patch applied > since boost was upgraded, only some compi

Re: Patch to remove hardcoded Header file locations

Abdelrazak Younes <[EMAIL PROTECTED]> writes: > We should remove it. Windows builds use external intl already, so > should other platforms IMHO. I meant all the m4 infrastructure. I believe that the new way is to let autotools copy this, and avoid keeping stuff in svn, but I'll have to check. JM

Re: Remove BOOST (was Re: Patch to remove hardcoded Header file locations)

Pavel Sanda wrote: Abdelrazak Younes wrote: By the way, I think we should also remove boost from our source and just say that we depend on boost >= 1.34.0 which is already one year old. I checked the svn logs and we have no internal patch applied since boost was upgraded, only some compiler

Re: Platform-dependent Menu Structure ?

> This mechanism exists in 1.6 for bindings and menus. It would be nice > to know how well it works in practice, though. What is still missing > is icons. What would you use to specify an ICON? I guess InsetInfo::INFO_ICON lfunc? I am in the process of adding INFO_SHORTCUTS, adding INFO_ICON shou

Re: Remove BOOST (was Re: Patch to remove hardcoded Header file locations)

Abdelrazak Younes wrote: > By the way, I think we should also remove boost from our source and just > say that we depend on boost >= 1.34.0 which is already one year old. I > checked the svn logs and we have no internal patch applied since boost was > upgraded, only some compiler warning fixes.

Remove BOOST (was Re: Patch to remove hardcoded Header file locations)

Jean-Marc Lasgouttes wrote: Konrad Hofbauer <[EMAIL PROTECTED]> writes: Dear developers, in two files a path to some system header files is hard-coded with /System/Library/Frameworks/CoreFoundation.framework/Headers The source of the problem is of course in gettext.m4, from which con

Re: Beta 2 (private announcement)

Bennett Helm wrote: I can now confirm that it also works on PPC-10.4. Good. That was with the version that YOU built on 10.5? If so, that means that you can (and should) build the release version yourself again, right? That might also solve the crash occurring with George. /Konrad

Re: An advice for Lyx to support CJK.

Jürgen Spitzmüller-2 wrote: > > steadycookie wrote: >> But I prefer you remove the codes to generate the commands to invoke a >> language package as I mentioned above. :) Maybe in next release version? > > We cannot just remove these commands. This is very complicated and it took > us > a lon

Re: Patch to remove hardcoded Header file locations

Jean-Marc Lasgouttes wrote: Konrad Hofbauer <[EMAIL PROTECTED]> writes: Dear developers, in two files a path to some system header files is hard-coded with /System/Library/Frameworks/CoreFoundation.framework/Headers The source of the problem is of course in gettext.m4, from which con

Re: Patch to remove hardcoded Header file locations

Konrad Hofbauer <[EMAIL PROTECTED]> writes: > Dear developers, > > in two files a path to some system header files is hard-coded with > /System/Library/Frameworks/CoreFoundation.framework/Headers The source of the problem is of course in gettext.m4, from which configure is generated. It seems t

Re: An advice for Lyx to support CJK.

steadycookie wrote: > But I prefer you remove the codes to generate the commands to invoke a > language package as I mentioned above. :) Maybe in next release version? We cannot just remove these commands. This is very complicated and it took us a long time to get it right, especially when it com

Re: Another lfun namings

Jean-Marc Lasgouttes wrote: > Pavel Sanda <[EMAIL PROTECTED]> writes: > > > Jean-Marc Lasgouttes wrote: > >> I guess this one is going to be killed anyway if break-paragraph-skip > >> goes. > > > > what you exactly mean by 'goes'? > > goes... away? > goes... down the drain? > goes... to hell? :D

Re: LyX Menu Structure

Bennett Helm wrote: > Seriously, if there's no agreement on changing the status quo here, the > status quo wins. And vice versa, of course. I'm just stating my personal options. Jürgen

Re: Another lfun namings

Pavel Sanda <[EMAIL PROTECTED]> writes: > Jean-Marc Lasgouttes wrote: >> I guess this one is going to be killed anyway if break-paragraph-skip >> goes. > > what you exactly mean by 'goes'? goes... away? goes... down the drain? goes... to hell? JMarc

Re: Beta 2 (private announcement)

On Mon, Jun 2, 2008 at 10:25 PM, Bennett Helm <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 5:02 PM, Konrad Hofbauer <[EMAIL PROTECTED]> > wrote: > >> Bennett, Anders, >> >> please find at >> >> a universal binary built

Re: Another lfun namings

Pavel Sanda wrote: Jean-Marc Lasgouttes wrote: I guess this one is going to be killed anyway if break-paragraph-skip goes. what you exactly mean by 'goes'? He means: If it is removed. I.e., if the one is removed then the other should be, too. rh

Re: Another lfun namings

Jean-Marc Lasgouttes wrote: > I guess this one is going to be killed anyway if break-paragraph-skip > goes. what you exactly mean by 'goes'? p

Re: An advice for Lyx to support CJK.

Jürgen Spitzmüller-2 wrote: > > steadycookie wrote: >> Has file a bug report. And uploaded a testcase. Sorry for the delay. >> See http://bugzilla.lyx.org/show_bug.cgi?id=4913 > > I've fixed the problem in trunk: > http://www.lyx.org/trac/changeset/25093 > > A fix for 1.5.6svn is on bugzilla.

Re: LyX Menu Structure

On Tue, Jun 3, 2008 at 8:20 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > Bennett Helm wrote: > > Naturally all of these suggestions won't be > > acceptable precisely because, as you say, Linux and Windows users have > > different guidelines. But I think it's worth looking at it and thinking

Re: Beta 2 (private announcement)

Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> 2) change the configure.ac to the release tag, and works for some >> days in that state before reverting to svn after tagging the >> release. > > 2) sounds good as it also convey the information as a "mini-freeze". +1 JMarc

Re: Unicode and Index Entries

Anders Ekberg wrote: On 3 jun 2008, at 12.16, Jean-Marc Lasgouttes wrote: rgheck <[EMAIL PROTECTED]> writes: We still need to do quite a bit of work on the conversion--reversion routines connected with the InsetIndex changes. One of the main things that need doing is providing a list of conve

Re: LyX Menu Structure

Bennett Helm wrote: * Shouldn't bundling/compression menu items go with save menu items? There's actually a bug report about this somewhere. rh

Re: Platform-dependent Menu Structure ? [Was: LyX Menu Structure]

Jürgen Spitzmüller wrote: Konrad Hofbauer wrote: I fully agree to that. And it is the same with Shell vs. GNOME vs. KDE vs. Windows vs. Mac vs. ... And I believe that in a menu structure discussion most likes and dis-likes would be because what one is used to on "his" platform. Agreed.

Re: Beta 2 (private announcement)

Abdelrazak Younes wrote: >>> Would it be worth to release beta 3 with this problem fixed or should we >>> publically announce beta 2 remarking the known problems? >>> >> >> i would vote for beta 3 if you are able to prepare it very soon. >> otherwise next development bring new bugs we will ne

Re: Beta 2 (private announcement)

Pavel Sanda wrote: José Matos wrote: On Tuesday 03 June 2008 12:40:10 Pavel Sanda wrote: José Matos wrote: The green light will be given based on the feedback that we get in the developers list. ok, and what do you plan now :) ? pavel The only glaring remaining

About the filename combo in the cross-reference dialog

Hi, We should either get rid of it or implement the support for the xr package. As I suppose nobody's willing to implement that, I think we should eliminate that confusing combo; or at least make it invisible up until the xr package is supported. Opinions? Abdel.

Re: Beta 2 (private announcement)

José Matos wrote: > On Tuesday 03 June 2008 12:40:10 Pavel Sanda wrote: > > José Matos wrote: > > > The green light will be given based on the feedback that we get in the > > > developers list. > > > > ok, and what do you plan now :) ? > > pavel > > The only glaring remaining problem was the updat

Re: Beta 2 (private announcement)

José Matos wrote: On Tuesday 03 June 2008 13:05:58 Jean-Marc Lasgouttes wrote: OK, so what you could have tried is to package some rX revision, let people try it, and tag beta2 from it if there are no brown paper bag issues. OK, the only issue is that the default options change if

Re: Beta 2 (private announcement)

On Tuesday 03 June 2008 12:40:10 Pavel Sanda wrote: > José Matos wrote: > > The green light will be given based on the feedback that we get in the > > developers list. > > ok, and what do you plan now :) ? > pavel The only glaring remaining problem was the update problem from lyx2lyx. This was fi

Re: Beta 2 (private announcement)

On Tuesday 03 June 2008 13:05:58 Jean-Marc Lasgouttes wrote: > OK, so what you could have tried is to package some rX revision, > let people try it, and tag beta2 from it if there are no brown paper > bag issues. OK, the only issue is that the default options change if we are using a beta or

Re: Platform-dependent Menu Structure ? [Was: LyX Menu Structure]

On Tue, Jun 3, 2008 at 5:08 AM, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > Konrad Hofbauer wrote: > >> Another careful inquiry on people's opinion (and to find out how much work >> would be involved). >> >> Jürgen Spitzmüller wrote: >> >>> Also, we should not follow our intuition alone, but so

Re: Another lfun namings

Pavel Sanda <[EMAIL PROTECTED]> writes: >> All entries satisfy this, except for LFUN_DELETE_BACKWARD_SKIP. I > > heh what about LFUN_CHAR_DELETE_BACKWARD X LFUN_CHAR_BACKWARD_SELECT. > don't you think this is inconsitency? I see select as a modifier for the lfun (actually, I'd like to remove thes

Re: LyX Menu Structure

Bennett Helm wrote: > Naturally all of these suggestions won't be > acceptable precisely because, as you say, Linux and Windows users have > different guidelines. But I think it's worth looking at it and thinking > about changes nonetheless. I don't think a mix of different guidelines is what we w

Re: [Cvslog] r25098 - /lyx-devel/trunk/src/LyXAction.cpp

Pavel Sanda <[EMAIL PROTECTED]> writes: >> I think we should, but of course this will cause problems on bind >> files. > > no problem, i care about these. Sorry, I meant "on users' own bind files". JMarc

Re: Another lfun namings

Jean-Marc Lasgouttes wrote: > Pavel Sanda <[EMAIL PROTECTED]> writes: > > > hi, > > > > i see another inconsitencies we have wrt lfun naming: > > LFUN_DELETE_BACKWARD_SKIP > > LFUN_CHAR_DELETE_BACKWARD > > LFUN_CHAR_BACKWARD_SELECT > > LFUN_CHAR_RIGHT_SELECT > > LFUN_WORD_FIND_BACKWARD > > > > i t

Re: [Cvslog] r25098 - /lyx-devel/trunk/src/LyXAction.cpp

Jean-Marc Lasgouttes wrote: > Pavel Sanda <[EMAIL PROTECTED]> writes: > > > i will also rename delete-back/forward->char-delete-back/forward > > unless somebody screams. > > I think we should, but of course this will cause problems on bind > files. no problem, i care about these. pavel

Re: [Cvslog] r25098 - /lyx-devel/trunk/src/LyXAction.cpp

Pavel Sanda <[EMAIL PROTECTED]> writes: > i will also rename delete-back/forward->char-delete-back/forward > unless somebody screams. I think we should, but of course this will cause problems on bind files. JMarc

Re: Another lfun namings

Pavel Sanda <[EMAIL PROTECTED]> writes: > hi, > > i see another inconsitencies we have wrt lfun naming: > LFUN_DELETE_BACKWARD_SKIP > LFUN_CHAR_DELETE_BACKWARD > LFUN_CHAR_BACKWARD_SELECT > LFUN_CHAR_RIGHT_SELECT > LFUN_WORD_FIND_BACKWARD > > i think we should unifify whether is first direction or

Re: LyX Menu Structure

On Tue, Jun 3, 2008 at 2:35 AM, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > rgheck wrote: > > There are no fundamental code changes here, so it's not too late in > > principle. > > Note, however, that all documentation needed to be rewritten in such a case > (as long as we do not have a Menu I

Re: Beta 2 (private announcement)

José Matos <[EMAIL PROTECTED]> writes: > On Monday 02 June 2008 17:39:34 Jean-Marc Lasgouttes wrote: >> In the future, I think you should tag a betaXrc1 before tagging >> betaX, as stupid as it may seem (or just package a particular svn >> revision). > > In the past we have never announced beta

Re: [Cvslog] r25098 - /lyx-devel/trunk/src/LyXAction.cpp

[EMAIL PROTECTED] wrote: > Author: sanda > Date: Tue Jun 3 13:41:27 2008 > New Revision: 25098 > > URL: http://www.lyx.org/trac/changeset/25098 > + * \var lyx::FuncCode lyx::LFUN_CHAR_DELETE_BACKWARD > + * \li Syntax: delete-backward > + * \var lyx::FuncCode lyx::LFUN_CHAR_DELETE_FORWARD > + * \l

Re: Beta 2 (private announcement)

José Matos wrote: > The green light will be given based on the feedback that we get in the > developers list. ok, and what do you plan now :) ? pavel

Re: Unicode and Index Entries

On 3 jun 2008, at 12.16, Jean-Marc Lasgouttes wrote: rgheck <[EMAIL PROTECTED]> writes: We still need to do quite a bit of work on the conversion--reversion routines connected with the InsetIndex changes. One of the main things that need doing is providing a list of conversions between LaTe

Re: Beta 2 (private announcement)

On Tuesday 03 June 2008 01:10:49 Pavel Sanda wrote: > no, this means that it is ok to build beta2 wininstaller and announce it on > _devel_ list even before the green light. Yes. > with annoucements for users should arch builders wait for green light from > Jose (which is the message in the annou

Another lfun namings

hi, i see another inconsitencies we have wrt lfun naming: LFUN_DELETE_BACKWARD_SKIP LFUN_CHAR_DELETE_BACKWARD LFUN_CHAR_BACKWARD_SELECT LFUN_CHAR_RIGHT_SELECT LFUN_WORD_FIND_BACKWARD i think we should unifify whether is first direction or action. my opinion is that direction should be the last. o

Re: Beta 2 (private announcement)

On Tuesday 03 June 2008 11:40:10 Jean-Marc Lasgouttes wrote: > Yes, as far as possible (in particular for bugs that affect all > architectures). Architecture dependent fixes are acceptable. > > JMarc Yes and yes. :-) -- José Abílio

Re: Beta 2 (private announcement)

On Monday 02 June 2008 17:39:34 Jean-Marc Lasgouttes wrote: > In the future, I think you should tag a betaXrc1 before tagging > betaX, as stupid as it may seem (or just package a particular svn > revision). In the past we have never announced beta versions in the users list. This sort of announ

Re: Beta 2 (private announcement)

Konrad Hofbauer <[EMAIL PROTECTED]> writes: > But in any case: I assume the arch builds should be based on José's > official tar-balls, without any additional patches applied (or > otherwise be termed 1.6.0svnx), correct? Yes, as far as possible (in particular for bugs that affect all archite

Re: Platform-dependent Menu Structure ?

Jean-Pierre Chrétien <[EMAIL PROTECTED]> writes: > If the ui dir should be populated, first of all the same text should > be used for the various occurrences (classic and default are currently > inconsistent) and some mechanism should be found to introduce > the menu description symbolically in th

Re: Unicode and Index Entries

rgheck <[EMAIL PROTECTED]> writes: > We still need to do quite a bit of work on the conversion--reversion > routines connected with the InsetIndex changes. One of the main things > that need doing is providing a list of conversions between LaTeX > representations like "\'a" and the corresponding U

Re: Beta 2 (private announcement)

José Matos wrote: as discussed during the weekend and in order to fix the problems that appeared with beta 1 I have tagged a new release (beta 2). Windows binaries are available at http://www.lyx.org/~joost/ Joost

Re: Platform-dependent Menu Structure ? [Was: LyX Menu Structure]

Konrad Hofbauer <[EMAIL PROTECTED]> writes: [...] > > So my big question is: > > *** Should the menu stucture be platform-specific ? *** > > *** PROS *** > + Consistency accross different applications. > + Things are where the user expects them. > + LyX can better conform to the platform HIG. >

Re: Beta 2 (private announcement)

Same result her on PPC 10.4. Could the UserGuide-problems be due to: http://bugzilla.lyx.org/show_bug.cgi?id=3938 Anders On 2 jun 2008, at 23.02, Konrad Hofbauer wrote: José Matos wrote: as discussed during the weekend and in order to fix the problems that appeared with beta 1 I have tagged

Re: LyX Menu Structure

Abdelrazak Younes wrote: > Well InsetInfo::MENU_INFO _is_ available, it is just that it is not used > (yet). I see. Great. Jürgen

Re: Platform-dependent Menu Structure ? [Was: LyX Menu Structure]

Konrad Hofbauer wrote: > I fully agree to that. And it is the same with Shell vs. GNOME vs. KDE > vs. Windows vs. Mac vs. ... And I believe that in a menu structure > discussion most likes and dis-likes would be because what one is used to > on "his" platform. Agreed. > So my big question is: > >

Re: LyX Menu Structure

Jürgen Spitzmüller wrote: Konrad Hofbauer wrote: Note, however, that all documentation needed to be rewritten in such a case True. (as long as we do not have a Menu Inset Info). I do not understand what this means/involves. An inset that can automatically display

Re: Platform-dependent Menu Structure ? [Was: LyX Menu Structure]

Konrad Hofbauer wrote: - Non-uniform appearance of LyX accross platforms We could make this user-configurable in the preferences (default to platform), for those people that switch between platforms and want the same menus. Other points to add? Opinions? Personally, I do not have a stron

  1   2   >