lyx.org down

[Jens Nöckel]

Hi,
another of those annoying outages has hit lyx.org and I thought I better let 
someone here know about it. It's happened before - but it always looks worrying 
when you can't get to the download page...

Jens

lyx.org down

[Jens Nöckel]

Hi,
another of those annoying outages has hit lyx.org and I thought I better let 
someone here know about it. It's happened before - but it always looks worrying 
when you can't get to the download page...

Jens

Possible bug with keyboard shortcut parsing

[Jens Nöckel]

Hi,
I just noticed a weird bug on Mac OS C with LyX 2.02. First I couldn't 
reproduce it, but now I think I have a recipe, and hopefully someone can 
confirm it. In some cases, the _sequence_ of Control-x and Control-s that emacs 
keybindings reserve for saving a document doesn't work. Instead, only the 
_last_ of the two (Control-s) is apparently captured and leads to the opening 
of the search dialog because the emacs keybinding for search is Control-s.

You probably don't have to do steps 1) - 4), but I did these steps very 
recently.

1)
Move ~/Library/Application Support/LyX-2.0 to the Desktop.

2)
Fresh download of 
LyX-2.0.2+qt4-cocoa.dmg
from www.lyx.org

3)
Move old LyX out of Application folder

4)
Install downloaded LyX and launch it

5)
In Preferences, I then chose the xemacs bind file, and checked the box Do not 
swap Apple and Control Keys

6)
Open a new document and type Hello or something like that, then save it. To 
save it with keyboard shortcuts, 

7)
Open the LyX User's Guide (or another document) from the Help menu (that took 
me some time to figure out). It opens in a tab.

8)
Go back to the first document, make some changes and try to save using the 
emacs keybinding Control-x Control-s. Now instead of saving, LyX opens the 
search dialog. This behavior doesn't go away if I close the User' Guide again. 
I have to restart LyX to recover.

This problem _doesn't_ appear when I open two of my own documents, either in 
separate windows or tabs. It on;y seems to appear when I also open Help 
documents!

Jens

Re: Possible bug with keyboard shortcut parsing

[Jens Nöckel]

On Feb 5, 2012, at 7:16 PM, Jens Nöckel wrote:

 Hi,
 I just noticed a weird bug on Mac OS C with LyX 2.02. First I couldn't 
 reproduce it, but now I think I have a recipe, and hopefully someone can 
 confirm it. In some cases, the _sequence_ of Control-x and Control-s that 
 emacs keybindings reserve for saving a document doesn't work. Instead, only 
 the _last_ of the two (Control-s) is apparently captured and leads to the 
 opening of the search dialog because the emacs keybinding for search is 
 Control-s.
 
 You probably don't have to do steps 1) - 4), but I did these steps very 
 recently.
 
 1)
 Move ~/Library/Application Support/LyX-2.0 to the Desktop.
 
 2)
 Fresh download of 
 LyX-2.0.2+qt4-cocoa.dmg
 from www.lyx.org
 
 3)
 Move old LyX out of Application folder
 
 4)
 Install downloaded LyX and launch it
 
 5)
 In Preferences, I then chose the xemacs bind file, and checked the box Do 
 not swap Apple and Control Keys
 
 6)
 Open a new document and type Hello or something like that, then save it. To 
 save it with keyboard shortcuts, 
 
 7)
 Open the LyX User's Guide (or another document) from the Help menu (that took 
 me some time to figure out). It opens in a tab.
 
 8)
 Go back to the first document, make some changes and try to save using the 
 emacs keybinding Control-x Control-s. Now instead of saving, LyX opens the 
 search dialog. This behavior doesn't go away if I close the User' Guide 
 again. I have to restart LyX to recover.
 
 This problem _doesn't_ appear when I open two of my own documents, either in 
 separate windows or tabs. It on;y seems to appear when I also open Help 
 documents!
 
 Jens
 
 
 

In point 6), I meant to say that the emacs shortcuts can be used without 
problems. 

In fact, all it takes for the bug to appear is that I open a help document and 
immediately close it again. 

Possible bug with keyboard shortcut parsing

[Jens Nöckel]

Hi,
I just noticed a weird bug on Mac OS C with LyX 2.02. First I couldn't 
reproduce it, but now I think I have a recipe, and hopefully someone can 
confirm it. In some cases, the _sequence_ of Control-x and Control-s that emacs 
keybindings reserve for saving a document doesn't work. Instead, only the 
_last_ of the two (Control-s) is apparently captured and leads to the opening 
of the search dialog because the emacs keybinding for search is Control-s.

You probably don't have to do steps 1) - 4), but I did these steps very 
recently.

1)
Move ~/Library/Application Support/LyX-2.0 to the Desktop.

2)
Fresh download of 
LyX-2.0.2+qt4-cocoa.dmg
from www.lyx.org

3)
Move old LyX out of Application folder

4)
Install downloaded LyX and launch it

5)
In Preferences, I then chose the xemacs bind file, and checked the box "Do not 
swap Apple and Control Keys"

6)
Open a new document and type "Hello" or something like that, then save it. To 
save it with keyboard shortcuts, 

7)
Open the LyX User's Guide (or another document) from the Help menu (that took 
me some time to figure out). It opens in a tab.

8)
Go back to the first document, make some changes and try to save using the 
emacs keybinding Control-x Control-s. Now instead of saving, LyX opens the 
search dialog. This behavior doesn't go away if I close the User' Guide again. 
I have to restart LyX to recover.

This problem _doesn't_ appear when I open two of my own documents, either in 
separate windows or tabs. It on;y seems to appear when I also open Help 
documents!

Jens

Re: Possible bug with keyboard shortcut parsing

[Jens Nöckel]

On Feb 5, 2012, at 7:16 PM, Jens Nöckel wrote:

> Hi,
> I just noticed a weird bug on Mac OS C with LyX 2.02. First I couldn't 
> reproduce it, but now I think I have a recipe, and hopefully someone can 
> confirm it. In some cases, the _sequence_ of Control-x and Control-s that 
> emacs keybindings reserve for saving a document doesn't work. Instead, only 
> the _last_ of the two (Control-s) is apparently captured and leads to the 
> opening of the search dialog because the emacs keybinding for search is 
> Control-s.
> 
> You probably don't have to do steps 1) - 4), but I did these steps very 
> recently.
> 
> 1)
> Move ~/Library/Application Support/LyX-2.0 to the Desktop.
> 
> 2)
> Fresh download of 
> LyX-2.0.2+qt4-cocoa.dmg
> from www.lyx.org
> 
> 3)
> Move old LyX out of Application folder
> 
> 4)
> Install downloaded LyX and launch it
> 
> 5)
> In Preferences, I then chose the xemacs bind file, and checked the box "Do 
> not swap Apple and Control Keys"
> 
> 6)
> Open a new document and type "Hello" or something like that, then save it. To 
> save it with keyboard shortcuts, 
> 
> 7)
> Open the LyX User's Guide (or another document) from the Help menu (that took 
> me some time to figure out). It opens in a tab.
> 
> 8)
> Go back to the first document, make some changes and try to save using the 
> emacs keybinding Control-x Control-s. Now instead of saving, LyX opens the 
> search dialog. This behavior doesn't go away if I close the User' Guide 
> again. I have to restart LyX to recover.
> 
> This problem _doesn't_ appear when I open two of my own documents, either in 
> separate windows or tabs. It on;y seems to appear when I also open Help 
> documents!
> 
> Jens
> 
> 
> 

In point 6), I meant to say that the emacs shortcuts can be used without 
problems. 

In fact, all it takes for the bug to appear is that I open a help document and 
immediately close it again. 

Re: Image Lifecycle (Create) Patch - Video

[Jens Nöckel]

To me it seems that this could be a great job for an external launcher utility 
or an operating system service, but not a feature that LyX should be 
responsible for. I guess Nautilus proves this point. Sorry to be so 
conservative about this, but for LyX to start shipping binary template files of 
a myriad other programs seems the wrong approach (not to mention all those 
hard-coded file extensions). 

How about creating a separate launcher application with all those templates and 
the mechanism for recognizing extensions. The user could (optionally) install 
it separately from LyX, and its presence could be detected by LyX at 
reconfigure time. Then at least one would have decoupled updating and 
development of LyX and this launcher application. 

I would imagine the following solution (probably needs corrections):

(a)
In the Graphics Insert dialog, the option to create a new file from a filename 
that doesn't point to an existing file would appear if the launcher application 
is also installed. 

(b)
Then, if the user says Yes, create a new file, LyX would send that filename 
(including absolute path) to the launcher application.

(c) 
The launcher application receives the filename, decides which external program 
to launch and which template to use. When it gets the result, it moves that to 
the specified filename at the specified absolute path. 

(d)
Finally, the launcher application sends the confirmation back to LyX, through 
the lyxpipe.in mechanism. Upon receiving this, if there was no error, LyX 
inserts the newly created file. 

So LyX only needs to implement the functionality to call the launcher 
application, and to receive the confirmation message in lyxpipe.in
The rest of the dirty work is done in the launcher application. This has the 
additional advantage that the launcher application could then potentially be 
re-used in other programs, depending on the creativity of the developer. All 
the customization you speak of could then be done in a directory outside of LyX 
responsibility.

Jens

On Jul 29, 2011, at 7:42 PM, Tommaso Cucinotta wrote:

 Il 29/07/2011 11:04, Pavel Sanda ha scritto:
 Tommaso Cucinotta wrote:
 I'd like to gather comments on this, whether it may be acceptable for the
 for the technical part i feel uncomfortable the we should ship bunch of
 empty binaries file and need to manage proper versions of them. if have
 older version of third party app which doesn't load it well? if the 
 conversion
 from older version has glitches? and so on...
 
 I understand your concerns, that's why I was also proposing to have
 maybe more versions of the same empty file type, corresponding to
 different versions of the file-format (and corresponding application),
 in order to be more compatible with possible old applications installed
 on a system.
 
 However, even without this addition, this feature would still be useful
 and work most of the times, and perhaps some times fail in creating
 a proper new file. In such a case the user can:
 -) go with the traditional LyX workflow, i.e., launch the external app
   independently, save the file to the proper place, then include it
   in the LyX doc
 -) customise LyX so as to have his/her own empty templates in the
.lyx/samples/ folder, which are matching the type and version of
the application he/she is using and so that would work 100% of
the times.
 
 On a related note, I just checked how it works on Nautilus (Gnome
 [right-click]-[Create Document] feature). There, the user is supposed
 to have a $HOME/Templates folder in which he/she places the
 template files to be used, then they show up in the right-click menu
 (so the whole feature relies on the user making an explicit configuration
 option -- that folder is normally empty).
 
 Also, on KDE, I found this package: Create-New-OpenOffice.org-Document,
 which contains templates and context menu entries for KDE and 
 OpenOffice.org3.
 Now you can right click in file manager or desktop and generate a new file.
 
 So, there seems to be a common need across different applications for
 creating new files from existing templates. Shipping each application distro
 with an empty file in a well-known folder such as /usr/share/templates
 would solve this problem, but unfortunately it doesn't happen.
 
 Still, the easiest thing to do seems to be shipping a few binary files (e.g.,
 one per supported file-format) with LyX itself.
 
T.
 

Re: Image Lifecycle (Create) Patch - Video

[Jens Nöckel]

To me it seems that this could be a great job for an external launcher utility 
or an operating system service, but not a feature that LyX should be 
responsible for. I guess Nautilus proves this point. Sorry to be so 
conservative about this, but for LyX to start shipping binary template files of 
a myriad other programs seems the wrong approach (not to mention all those 
hard-coded file extensions). 

How about creating a separate launcher application with all those templates and 
the mechanism for recognizing extensions. The user could (optionally) install 
it separately from LyX, and its presence could be detected by LyX at 
reconfigure time. Then at least one would have decoupled updating and 
development of LyX and this launcher application. 

I would imagine the following solution (probably needs corrections):

(a)
In the Graphics Insert dialog, the option to create a new file from a filename 
that doesn't point to an existing file would appear if the launcher application 
is also installed. 

(b)
Then, if the user says "Yes, create a new file", LyX would send that filename 
(including absolute path) to the launcher application.

(c) 
The launcher application receives the filename, decides which external program 
to launch and which template to use. When it gets the result, it moves that to 
the specified filename at the specified absolute path. 

(d)
Finally, the launcher application sends the confirmation back to LyX, through 
the lyxpipe.in mechanism. Upon receiving this, if there was no error, LyX 
inserts the newly created file. 

So LyX only needs to implement the functionality to call the launcher 
application, and to receive the confirmation message in lyxpipe.in
The rest of the "dirty work" is done in the launcher application. This has the 
additional advantage that the launcher application could then potentially be 
re-used in other programs, depending on the creativity of the developer. All 
the customization you speak of could then be done in a directory outside of LyX 
responsibility.

Jens

On Jul 29, 2011, at 7:42 PM, Tommaso Cucinotta wrote:

> Il 29/07/2011 11:04, Pavel Sanda ha scritto:
>> Tommaso Cucinotta wrote:
>>> I'd like to gather comments on this, whether it may be acceptable for the
>> for the technical part i feel uncomfortable the we should ship bunch of
>> empty binaries file and need to manage proper versions of them. if have
>> older version of third party app which doesn't load it well? if the 
>> conversion
>> from older version has glitches? and so on...
> 
> I understand your concerns, that's why I was also proposing to have
> maybe more versions of the same empty file type, corresponding to
> different versions of the file-format (and corresponding application),
> in order to be more compatible with possible old applications installed
> on a system.
> 
> However, even without this addition, this feature would still be useful
> and work most of the times, and perhaps some times fail in creating
> a proper new file. In such a case the user can:
> -) go with the traditional LyX workflow, i.e., launch the external app
>   independently, save the file to the proper place, then include it
>   in the LyX doc
> -) customise LyX so as to have his/her own empty templates in the
>.lyx/samples/ folder, which are matching the type and version of
>the application he/she is using and so that would work 100% of
>the times.
> 
> On a related note, I just checked how it works on Nautilus (Gnome
> [right-click]->[Create Document] feature). There, the user is supposed
> to have a "$HOME/Templates" folder in which he/she places the
> template files to be used, then they show up in the right-click menu
> (so the whole feature relies on the user making an explicit configuration
> option -- that folder is normally empty).
> 
> Also, on KDE, I found this package: "Create-New-OpenOffice.org-Document",
> which "contains templates and context menu entries for KDE and 
> OpenOffice.org3.
> Now you can right click in file manager or desktop and generate a new file."
> 
> So, there seems to be a common need across different applications for
> creating new files from existing templates. Shipping each application distro
> with an empty file in a well-known folder such as /usr/share/templates
> would solve this problem, but unfortunately it doesn't happen.
> 
> Still, the easiest thing to do seems to be shipping a few binary files (e.g.,
> one per supported file-format) with LyX itself.
> 
>T.
> 

Re: unicode glyph for 0xf061

[Jens Nöckel]

On Jun 29, 2011, at 1:35 PM, Kornel wrote:Hi, does someone know, if there exists some latexrepresentation of this symbol?Unfortunatelly I cannot use xelatex, because of bibtex references.	--  --	KornelI couldn't find a LaTeX command, but maybe this macro will do what you want (it uses an empty \framebox). You could also use the command \APLbox instead, which seems to be the closest LaTeX has to offer. But the \framebox lets you adjust the shape and baseline if necessary, since you seem to be looking for a thin rectangle.Jens

rectangle.lyx
Description: Binary data

Re: unicode glyph for 0xf061

[Jens Nöckel]

On Jun 29, 2011, at 3:12 PM, Kornel wrote:

 Am Mittwoch, 29. Juni 2011 schrieb Jens Nöckel:
  On Jun 29, 2011, at 1:35 PM, Kornel wrote:
   Hi, does someone know, if there exists some latex
   representation of this symbol?
   Unfortunatelly I cannot use xelatex, because of bibtex references.
   
 --  --
 
 Kornel
  
  I couldn't find a LaTeX command, but maybe this macro will do what you want
  (it uses an empty \framebox). You could also use the command \APLbox
  instead, which seems to be the closest LaTeX has to offer. But the
  \framebox lets you adjust the shape and baseline if necessary, since you
  seem to be looking for a thin rectangle.
  
  Jens
 
 Thanks for the answer Jens, unfortunatelly it is not what I am looking for.
 Looks more like the attached.
 
   Kornel
 
 Bildschirmfoto1.png

Ah, you fooled me with that unknown glyph (OK, I'm easy to fool). Is that a 
pencil in a box? Hard to say, because it's a private-use glyph. You'll probably 
have to draw that one by hand, maybe along the lines of the attached file. This 
time I'm using tikz to make the glyph, but it clearly needs some more work. 

Jens

Re: unicode glyph for 0xf061

[Jens Nöckel]

On Jun 29, 2011, at 7:33 PM, Jens Nöckel wrote:On Jun 29, 2011, at 3:12 PM, Kornel wrote:Am Mittwoch, 29. Juni 2011 schrieb Jens Nöckel: On Jun 29, 2011, at 1:35 PM, Kornel wrote:  Hi, does someone know, if there exists some latex  representation of this symbol?  Unfortunatelly I cannot use xelatex, because of bibtex references.	--  --  	  	Kornel  I couldn't find a LaTeX command, but maybe this macro will do what you want (it uses an empty \framebox). You could also use the command \APLbox instead, which seems to be the closest LaTeX has to offer. But the \framebox lets you adjust the shape and baseline if necessary, since you seem to be looking for a thin rectangle.  JensThanks for the answer Jens, unfortunatelly it is not what I am looking for.Looks more like the attached.	KornelBildschirmfoto1.pngAh, you fooled me with that unknown glyph (OK, I'm easy to fool). Is that a pencil in a box? Hard to say, because it's a private-use glyph. You'll probably have to draw that one by hand, maybe along the lines of the attached file. This time I'm using tikz to make the glyph, but it clearly needs some more work.JensAnd here is the attachment:

rectangle2.lyx
Description: Binary data

Re: unicode glyph for 0xf061

[Jens Nöckel]

On Jun 29, 2011, at 1:35 PM, Kornel wrote:Hi, does someone know, if there exists some latexrepresentation of this symbol?Unfortunatelly I cannot use xelatex, because of bibtex references.	-->  <--	KornelI couldn't find a LaTeX command, but maybe this macro will do what you want (it uses an empty \framebox). You could also use the command \APLbox instead, which seems to be the closest LaTeX has to offer. But the \framebox lets you adjust the shape and baseline if necessary, since you seem to be looking for a thin rectangle. Jens

rectangle.lyx
Description: Binary data

Re: unicode glyph for 0xf061

[Jens Nöckel]

On Jun 29, 2011, at 3:12 PM, Kornel wrote:

> Am Mittwoch, 29. Juni 2011 schrieb Jens Nöckel:
> > On Jun 29, 2011, at 1:35 PM, Kornel wrote:
> > > Hi, does someone know, if there exists some latex
> > > representation of this symbol?
> > > Unfortunatelly I cannot use xelatex, because of bibtex references.
> > > 
> > >   -->  <--
> > >   
> > >   Kornel
> > 
> > I couldn't find a LaTeX command, but maybe this macro will do what you want
> > (it uses an empty \framebox). You could also use the command \APLbox
> > instead, which seems to be the closest LaTeX has to offer. But the
> > \framebox lets you adjust the shape and baseline if necessary, since you
> > seem to be looking for a thin rectangle.
> > 
> > Jens
> 
> Thanks for the answer Jens, unfortunatelly it is not what I am looking for.
> Looks more like the attached.
> 
>   Kornel
> 
> 

Ah, you fooled me with that unknown glyph (OK, I'm easy to fool). Is that a 
pencil in a box? Hard to say, because it's a private-use glyph. You'll probably 
have to draw that one by hand, maybe along the lines of the attached file. This 
time I'm using tikz to make the glyph, but it clearly needs some more work. 

Jens

Re: unicode glyph for 0xf061

[Jens Nöckel]

On Jun 29, 2011, at 7:33 PM, Jens Nöckel wrote:On Jun 29, 2011, at 3:12 PM, Kornel wrote:Am Mittwoch, 29. Juni 2011 schrieb Jens Nöckel:> On Jun 29, 2011, at 1:35 PM, Kornel wrote:> > Hi, does someone know, if there exists some latex> > representation of this symbol?> > Unfortunatelly I cannot use xelatex, because of bibtex references.> > > > 	-->  <--> > 	> > 	Kornel> > I couldn't find a LaTeX command, but maybe this macro will do what you want> (it uses an empty \framebox). You could also use the command \APLbox> instead, which seems to be the closest LaTeX has to offer. But the> \framebox lets you adjust the shape and baseline if necessary, since you> seem to be looking for a thin rectangle.> > JensThanks for the answer Jens, unfortunatelly it is not what I am looking for.Looks more like the attached.	KornelAh, you fooled me with that unknown glyph (OK, I'm easy to fool). Is that a pencil in a box? Hard to say, because it's a private-use glyph. You'll probably have to draw that one by hand, maybe along the lines of the attached file. This time I'm using tikz to make the glyph, but it clearly needs some more work. JensAnd here is the attachment:

rectangle2.lyx
Description: Binary data

Re: lyx 2.0 crash

[Jens Nöckel]

On May 9, 2011, at 9:26 AM, Liviu Andronic wrote:

 On Mon, May 9, 2011 at 6:03 PM, John Kennan jken...@ssc.wisc.edu wrote:
 Hi:
 
 In Windows version (XP), using LyX 2.0.0 (April 29) I get a crash when I do
 this:
 
 Confirmed on Xubuntu 10.04, with 2.0.0.
 Liviu
 
The same thing happens on Mac OS X 10.6.7 with LyX 2.0.0 
Jens

Re: lyx 2.0 crash

[Jens Nöckel]

On May 9, 2011, at 9:26 AM, Liviu Andronic wrote:

> On Mon, May 9, 2011 at 6:03 PM, John Kennan  wrote:
>> Hi:
>> 
>> In Windows version (XP), using LyX 2.0.0 (April 29) I get a crash when I do
>> this:
>> 
> Confirmed on Xubuntu 10.04, with 2.0.0.
> Liviu
> 
The same thing happens on Mac OS X 10.6.7 with LyX 2.0.0 
Jens

Re: Feature request: the missing element in the LyX office suite

[Jens Nöckel]

On May 4, 2011, at 3:26 AM, Andrew Parsloe wrote:

 
 
 On 4/05/2011 9:59 p.m., Liviu Andronic wrote:
 On Wed, May 4, 2011 at 11:46 AM, Andrew Parsloeapars...@clear.net.nz  
 wrote:
 Yes, but it would be nice to be able to sum a table in LyX without having to
 fire up Gnumeric or Excel or whatever.
 
 It sure would.
 
 
 (To take matters to extremes, you
 could even fire up an external wordprocessor and create a pdf or latex
 document and import into LyX, but we don't. LyX is so much better and more
 fun to work in.)
 
 I understand your concern, but adding true spreadsheet capabilities to
 LyX would be a massive undertaking, and something to which some
 developers would object. LyX is by design a very flexible beast that
 allows you to interact with a huge (and growing) number of external
 tools: LaTeX, DocBook, BibTeX, R, Maxima, etc., etc.
 
 As far as I'm concerned, LyX does provide spreadsheet capabilities via
 the Gnumeric external material. It allows you to create and maintain
 your tables in a mature spreadsheet tool (something that LyX would
 never provide natively), and _dynamically_ import the results into
 your LyX documents. Personally I couldn't ask for more. (Think of it
 as graphics creation: you do not create them in LyX; you use some
 external tool to either create a final PDF and import into LyX, or to
 dynamically manage via external material).
 
 Cheers
 Liviu
 
 Actually I do create graphics in LyX (using PSTricks in a LyX document that 
 consists entirely of one sometimes big ERT inset). But I take your point. For 
 a computer with limited memory (1 GB seemed big when I bought it), where 
 there's a lot of disk activity with multiple programs running, being able to 
 work in LyX alone would be helpful.
 
 Regards,
 Andrew

The fact that 1 GB seems small nowadays is a sad reminder of how bloated some 
programs have become. 
Precisely for that reason I would not be in favor of an added spreadsheet tool 
in LyX. 
See also this link:
http://en.wikipedia.org/wiki/Feature_creep

Jens

Re: Goals for 2.1

[Jens Nöckel]

On May 4, 2011, at 10:14 AM, Stephan Witt wrote:

 Am 04.05.2011 um 18:57 schrieb Abdelrazak Younes:
 
 Wouldn't it be nice if you could generate the .app bundle right from within 
 XCode?
 
 Not really. I promised to provide the .app bundle as nightly build - by a 
 cron job.
 I don't know if it is possible to make that with XCode.
 
 The biggest win would be the fact the .app is created by the same tool chain 
 as used in the development phase.
 
 Stephan

I think it would be great if the app bundle could be built by using xcodebuild 
(that's a OS X shell command that comes with XCode for automatic builds, see 
the man page). 

Jens

Re: Feature request: the missing element in the LyX office suite

[Jens Nöckel]

On May 4, 2011, at 3:26 AM, Andrew Parsloe wrote:

> 
> 
> On 4/05/2011 9:59 p.m., Liviu Andronic wrote:
>> On Wed, May 4, 2011 at 11:46 AM, Andrew Parsloe  
>> wrote:
>>> Yes, but it would be nice to be able to sum a table in LyX without having to
>>> fire up Gnumeric or Excel or whatever.
>>> 
>> It sure would.
>> 
>> 
>>> (To take matters to extremes, you
>>> could even fire up an external wordprocessor and create a pdf or latex
>>> document and import into LyX, but we don't. LyX is so much better and more
>>> fun to work in.)
>>> 
>> I understand your concern, but adding true spreadsheet capabilities to
>> LyX would be a massive undertaking, and something to which some
>> developers would object. LyX is by design a very flexible beast that
>> allows you to interact with a huge (and growing) number of external
>> tools: LaTeX, DocBook, BibTeX, R, Maxima, etc., etc.
>> 
>> As far as I'm concerned, LyX does provide spreadsheet capabilities via
>> the Gnumeric external material. It allows you to create and maintain
>> your tables in a mature spreadsheet tool (something that LyX would
>> never provide natively), and _dynamically_ import the results into
>> your LyX documents. Personally I couldn't ask for more. (Think of it
>> as graphics creation: you do not create them in LyX; you use some
>> external tool to either create a final PDF and import into LyX, or to
>> dynamically manage via external material).
>> 
>> Cheers
>> Liviu
>> 
> Actually I do create graphics in LyX (using PSTricks in a LyX document that 
> consists entirely of one sometimes big ERT inset). But I take your point. For 
> a computer with limited memory (1 GB seemed big when I bought it), where 
> there's a lot of disk activity with multiple programs running, being able to 
> work in LyX alone would be helpful.
> 
> Regards,
> Andrew

The fact that 1 GB seems small nowadays is a sad reminder of how bloated some 
programs have become. 
Precisely for that reason I would not be in favor of an added spreadsheet tool 
in LyX. 
See also this link:
http://en.wikipedia.org/wiki/Feature_creep

Jens

Re: Goals for 2.1

[Jens Nöckel]

On May 4, 2011, at 10:14 AM, Stephan Witt wrote:

> Am 04.05.2011 um 18:57 schrieb Abdelrazak Younes:
> 
>> Wouldn't it be nice if you could generate the .app bundle right from within 
>> XCode?
> 
> Not really. I promised to provide the .app bundle as nightly build - by a 
> cron job.
> I don't know if it is possible to make that with XCode.
> 
> The biggest win would be the fact the .app is created by the same tool chain 
> as used in the development phase.
> 
> Stephan

I think it would be great if the app bundle could be built by using xcodebuild 
(that's a OS X shell command that comes with XCode for automatic builds, see 
the man page). 

Jens

Re: Simple Drawing Ability

[Jens Nöckel]

On Apr 19, 2011, at 3:06 PM, Tommaso Cucinotta wrote:

 Il 20/09/2009 15:10, Tommaso Cucinotta ha scritto:
 Just a simple button that creates an empty drawing copying a template
 from a folder (and opening an external editor on it) seems really the
 right way to go, it would solve your particular problem, it would leave
 you with the complete freedom to pick any already existing editor that
 you like, or just write a new one from scratch, if you prefer.
 
 AFAIK, after the thread
 
  http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg154697.html
 
 there was no actual implementation of this feature, for creating
 quickly empty external files over which to invoke an external editor.
 
 In the current trunk, you can specify a non-existent external file in
 the Insert - External Material... dialog, but when trying to externally
 edit you get a non-existent file error dialog.
 
 Is there anyone with a patch for this ? (i.e., a create button the
 Insert - External Material... dialog).
 
 Guess #3205 is the corresponding Trac entry (#5726 seems related as well).
 
 Thanks,
 
T.

Regarding the topic Simple Drawing Ability - just in case this was 
overlooked, let me mention that simple drawings can be made by copy and paste. 
It's so simple that you don't even need external material functionality. Here 
is the procedure:

(1)
In an external drawing program of your choice, make a drawing.

(2)
Put the drawing on the pasteboard (when speed is the main concern, I usually do 
a screenshot of a selected area, which generates a PNG representation on Mac OS 
X). 

(3) 
In LyX, go to the insertion point and paste the graphic (the LFUN is: paste 
png). 

If you organize your LyX file with all added material in a separate directory, 
then you can just let LyX choose the image name by pressing return. Of course, 
if you later edit the image in any drawing program, the updated image will 
appear in LyX too.

Jens

Re: Simple Drawing Ability

[Jens Nöckel]

On Apr 19, 2011, at 3:06 PM, Tommaso Cucinotta wrote:

> Il 20/09/2009 15:10, Tommaso Cucinotta ha scritto:
>> Just a simple button that creates an empty drawing copying a template
>> from a folder (and opening an external editor on it) seems really the
>> right way to go, it would solve your particular problem, it would leave
>> you with the complete freedom to pick any already existing editor that
>> you like, or just write a new one from scratch, if you prefer.
> 
> AFAIK, after the thread
> 
>  http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg154697.html
> 
> there was no actual implementation of this feature, for creating
> quickly empty external files over which to invoke an external editor.
> 
> In the current trunk, you can specify a non-existent external file in
> the Insert -> External Material... dialog, but when trying to externally
> edit you get a "non-existent file" error dialog.
> 
> Is there anyone with a patch for this ? (i.e., a "create" button the
> Insert -> External Material... dialog).
> 
> Guess #3205 is the corresponding Trac entry (#5726 seems related as well).
> 
> Thanks,
> 
>T.

Regarding the topic "Simple Drawing Ability" - just in case this was 
overlooked, let me mention that simple drawings can be made by copy and paste. 
It's so simple that you don't even need "external material" functionality. Here 
is the procedure:

(1)
In an external drawing program of your choice, make a drawing.

(2)
Put the drawing on the pasteboard (when speed is the main concern, I usually do 
a screenshot of a selected area, which generates a PNG representation on Mac OS 
X). 

(3) 
In LyX, go to the insertion point and paste the graphic (the LFUN is: paste 
png). 

If you organize your LyX file with all added material in a separate directory, 
then you can just let LyX choose the image name by pressing return. Of course, 
if you later edit the image in any drawing program, the updated image will 
appear in LyX too.

Jens

Re: Poll for the default icon theme in LyX 2.0

[Jens Nöckel]

libreoffice

Although I'll miss the old noun icon: it's the last samurai of the 8-bit 
world. 
Jens

Re: Poll for the default icon theme in LyX 2.0

[Jens Nöckel]

libreoffice

Although I'll miss the old "noun" icon: it's the last samurai of the 8-bit 
world. 
Jens

Re: aqua.bind

[Jens Nöckel]

On Mar 20, 2011, at 6:11 PM, Pavel Sanda wrote:

 Jens Nöckel wrote:
 I believe aqua.bind was an attempt to imitate Linux's ability to
 access the menus from the keyboard (albeit without the menus dropping
 down), whereas I know that mac.bind was designed to adhere to Mac
 standards as closely as possible. So they really serve different
 functions.
 
 I don't know if people are still using aqua.bind, but if there are,
 I'm sure they'd be unhappy to have it removed.
 
 BH
 
 Yes, I'm using aqua.bind together with xemacs.bind. For example, I got used 
 to its shortcuts for inserting citations, footnotes and similar...
 
 fine. is there something to be added as far as new features in 2.0 is 
 concerned?
 pavel

So far I haven't used any new LFUNs (I guess I had already reached a steady 
state in my LyX usage - and in software, that is pretty much my definition of 
perfection). But I'll try to look out for possible additions to the bind file.

Jens

Re: aqua.bind

[Jens Nöckel]

On Mar 20, 2011, at 6:11 PM, Pavel Sanda wrote:

> Jens Nöckel wrote:
>>> I believe aqua.bind was an attempt to imitate Linux's ability to
>>> access the menus from the keyboard (albeit without the menus dropping
>>> down), whereas I know that mac.bind was designed to adhere to Mac
>>> standards as closely as possible. So they really serve different
>>> functions.
>>> 
>>> I don't know if people are still using aqua.bind, but if there are,
>>> I'm sure they'd be unhappy to have it removed.
>>> 
>>> BH
>> 
>> Yes, I'm using aqua.bind together with xemacs.bind. For example, I got used 
>> to its shortcuts for inserting citations, footnotes and similar...
> 
> fine. is there something to be added as far as new features in 2.0 is 
> concerned?
> pavel

So far I haven't used any new LFUNs (I guess I had already reached a steady 
state in my LyX usage - and in software, that is pretty much my definition of 
perfection). But I'll try to look out for possible additions to the bind file.

Jens

Re: aqua.bind

[Jens Nöckel]

On Mar 20, 2011, at 3:56 PM, BH wrote:

 On Sun, Mar 20, 2011 at 1:59 PM, Pavel Sanda sa...@lyx.org wrote:
 mac people,
 what is the relation between mac.bind and aqua.bind. do we need both of them?
 pavel
 
 I believe aqua.bind was an attempt to imitate Linux's ability to
 access the menus from the keyboard (albeit without the menus dropping
 down), whereas I know that mac.bind was designed to adhere to Mac
 standards as closely as possible. So they really serve different
 functions.
 
 I don't know if people are still using aqua.bind, but if there are,
 I'm sure they'd be unhappy to have it removed.
 
 BH

Yes, I'm using aqua.bind together with xemacs.bind. For example, I got used to 
its shortcuts for inserting citations, footnotes and similar...

Jens

Re: aqua.bind

[Jens Nöckel]

On Mar 20, 2011, at 3:56 PM, BH wrote:

> On Sun, Mar 20, 2011 at 1:59 PM, Pavel Sanda  wrote:
>> mac people,
>> what is the relation between mac.bind and aqua.bind. do we need both of them?
>> pavel
> 
> I believe aqua.bind was an attempt to imitate Linux's ability to
> access the menus from the keyboard (albeit without the menus dropping
> down), whereas I know that mac.bind was designed to adhere to Mac
> standards as closely as possible. So they really serve different
> functions.
> 
> I don't know if people are still using aqua.bind, but if there are,
> I'm sure they'd be unhappy to have it removed.
> 
> BH

Yes, I'm using aqua.bind together with xemacs.bind. For example, I got used to 
its shortcuts for inserting citations, footnotes and similar...

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 19, 2010, at 12:02 AM, Pavel Sanda wrote:

 Jens Nöckel wrote:
 Another version of the patch is attached, this time hopefully readable by 
 everyone... 
 
 no its octet-stream now. next guess is .txt :)
 
Or using a different mailer, sigh.

 cant be this code:
 
 +// GUI_DONTSWAPCB_VISIBLE reveals checkbox for switching Ctrl and Meta on 
 Mac:  
   
 +#ifdef Q_WS_MACX
 +#if QT_VERSION  0x040600   
 +   connect(dontswapCB, SIGNAL(toggled(bool)),   
 +   this, SIGNAL(changed()));
 +#define GUI_DONTSWAPCB_VISIBLE true 
 +#endif 
 +#endif  
 +#ifndef GUI_DONTSWAPCB_VISIBLE  
 +   dontswapCB-setVisible(false);   
 +#endif
 
 
 written as:
 
 +   connect(dontswapCB, SIGNAL(toggled(bool)),   
 +   this, SIGNAL(changed()));
 +#ifdef Q_WS_MACX
 +#if QT_VERSION  0x040600   
 +   dontswapCB-setVisible(false);   
 +#endif  
 

No, this would be the wrong way around. If you really want even fewer #ifdef, 
one could say this:

+   connect(dontswapCB, SIGNAL(toggled(bool)),   
+   this, SIGNAL(changed()));
+   dontswapCB-setVisible(false);   
+#ifdef Q_WS_MACX
+#if QT_VERSION  0x040600   
+   dontswapCB-setVisible(true);   
+#endif  

But then the actual code on Mac would execute two calls to setVisible instead 
of one, which just seems slightly more  inelegant. 

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 19, 2010, at 8:25 AM, Pavel Sanda wrote:

 Jens Nöckel wrote:
 +   connect(dontswapCB, SIGNAL(toggled(bool)),   
 +   this, SIGNAL(changed()));
 +   dontswapCB-setVisible(false);   
 +#ifdef Q_WS_MACX
 +#if QT_VERSION  0x040600   
 +   dontswapCB-setVisible(true);   
 +#endif  
 
 But then the actual code on Mac would execute two calls to setVisible 
 instead of one, which just seems slightly more  inelegant. 
 
 i see. what you feel better with
 
 bool swapcb=false;
 
 #ifdef Q_WS_MACX
 #if QT_VERSION  0x040600
 swapcb=true;
 #endif
 
 dontswapCB-setVisible(swapcb);
 
 pavel


That's perfect - please feel free to modify my patch this way. 

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 19, 2010, at 3:03 PM, Pavel Sanda wrote:

 Jens Nöckel wrote:
 That's perfect - please feel free to modify my patch this way. 
 
 its in. perhaps you want to add oneliner into misc section of newinlyx20 
 wiki...
 pavel

Great! Could someone send me the WIki password? Then I'll add a line under 
Miscellaneous.

Thanks,
Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 19, 2010, at 12:02 AM, Pavel Sanda wrote:

> Jens Nöckel wrote:
>> Another version of the patch is attached, this time hopefully readable by 
>> everyone... 
> 
> no its octet-stream now. next guess is .txt :)
> 
Or using a different mailer, sigh.

> cant be this code:
> 
> +// GUI_DONTSWAPCB_VISIBLE reveals checkbox for switching Ctrl and Meta on 
> Mac:  
>   
> +#ifdef Q_WS_MACX
> +#if QT_VERSION > 0x040600   
> +   connect(dontswapCB, SIGNAL(toggled(bool)),   
> +   this, SIGNAL(changed()));
> +#define GUI_DONTSWAPCB_VISIBLE true 
> +#endif 
> +#endif  
> +#ifndef GUI_DONTSWAPCB_VISIBLE  
> +   dontswapCB->setVisible(false);   
> +#endif
> 
> 
> written as:
> 
> +   connect(dontswapCB, SIGNAL(toggled(bool)),   
> +   this, SIGNAL(changed()));
> +#ifdef Q_WS_MACX
> +#if QT_VERSION > 0x040600   
> +   dontswapCB->setVisible(false);   
> +#endif  
> 

No, this would be the wrong way around. If you really want even fewer #ifdef, 
one could say this:

+   connect(dontswapCB, SIGNAL(toggled(bool)),   
+   this, SIGNAL(changed()));
+   dontswapCB->setVisible(false);   
+#ifdef Q_WS_MACX
+#if QT_VERSION > 0x040600   
+   dontswapCB->setVisible(true);   
+#endif  

But then the actual code on Mac would execute two calls to setVisible instead 
of one, which just seems slightly more  inelegant. 

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 19, 2010, at 8:25 AM, Pavel Sanda wrote:

> Jens Nöckel wrote:
>> +   connect(dontswapCB, SIGNAL(toggled(bool)),   
>> +   this, SIGNAL(changed()));
>> +   dontswapCB->setVisible(false);   
>> +#ifdef Q_WS_MACX
>> +#if QT_VERSION > 0x040600   
>> +   dontswapCB->setVisible(true);   
>> +#endif  
>> 
>> But then the actual code on Mac would execute two calls to setVisible 
>> instead of one, which just seems slightly more  inelegant. 
> 
> i see. what you feel better with
> 
> bool swapcb=false;
> 
> #ifdef Q_WS_MACX
> #if QT_VERSION > 0x040600
> swapcb=true;
> #endif
> 
> dontswapCB->setVisible(swapcb);
> 
> pavel


That's perfect - please feel free to modify my patch this way. 

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 19, 2010, at 3:03 PM, Pavel Sanda wrote:

> Jens Nöckel wrote:
>> That's perfect - please feel free to modify my patch this way. 
> 
> its in. perhaps you want to add oneliner into misc section of newinlyx20 
> wiki...
> pavel

Great! Could someone send me the WIki password? Then I'll add a line under 
"Miscellaneous".

Thanks,
Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 17, 2010, at 3:48 PM, Pavel Sanda wrote:

 Stephan Witt wrote:
 So if I put Pavel's suggestion in, would my checkbox patch be acceptable? 
 As I said, I'd be OK without GUI, but I don't really think it will hurt 
 anyone to have it in there, with the default being not to change the key 
 mapping.
 
 I'd have no problem with that.
 
 +1

OK, here is the new patch for the current LyX 2.0 in svn trunk:


modifierKey-2.diff
Description: Binary data


The check box is added in Preferences  Editing  Keyboard/Mouse, but only if 
we're on MacOSX with Qt  4.6.0. The default setting is to leave everything as 
it is now. When the check box is set, the Mac control key will act as LyX Ctrl 
and the Mac Command key will act as LyX Meta (which is the reverse of the 
current default mapping, and is preferred by emacs users). No matter what the 
setting is, the MacOSX-specific commands for Quit, Hide and Preferences 
will be unchanged (i.e., they continue to use the Mac Command key).

Thanks,
Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 18, 2010, at 10:14 AM, Jens Nöckel wrote:

 
 On Sep 17, 2010, at 3:48 PM, Pavel Sanda wrote:
 
 Stephan Witt wrote:
 So if I put Pavel's suggestion in, would my checkbox patch be acceptable? 
 As I said, I'd be OK without GUI, but I don't really think it will hurt 
 anyone to have it in there, with the default being not to change the key 
 mapping.
 
 I'd have no problem with that.
 
 +1
 
 OK, here is the new patch for the current LyX 2.0 in svn trunk:
 modifierKey-2.diff
 
 The check box is added in Preferences  Editing  Keyboard/Mouse, but only if 
 we're on MacOSX with Qt  4.6.0. The default setting is to leave everything 
 as it is now. When the check box is set, the Mac control key will act as LyX 
 Ctrl and the Mac Command key will act as LyX Meta (which is the reverse of 
 the current default mapping, and is preferred by emacs users). No matter what 
 the setting is, the MacOSX-specific commands for Quit, Hide and 
 Preferences will be unchanged (i.e., they continue to use the Mac Command 
 key).

Another comment I forgot to add (but had mentioned earlier): the change takes 
effect only after restarting LyX (because the keynoard shortcuts in the menu 
bar have to be rebuilt).

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

Another version of the patch is attached, this time hopefully readable by everyone...There was one additional line in GuiApplication.cpp that I took out - it was commented out anyway and corresponded to the initial test I described inhttp://wiki.lyx.org/Mac/LyXmodifierKeys#sMac.LyXmodifierKeys_5(which is no longer the way I do things). It was put in by Stephan in rev. 34812.

modifierKey-3.patch
Description: Binary data
Below are some more responses:On Sep 18, 2010, at 12:48 PM, Pavel Sanda wrote:i would be happy if we can get rid of any additional #ifdefs. it needs to be testedbut i guess except this part:+	dontswapCB-setVisible(false);all other parts of code could be normally written and no GUI_DONTSWAPCB_VISIBLE needed.I took those two #ifdef out.+ stringDo not swap Meta and Control keys/stringadd something like "on MacOSX"...Since this text only shows up on Mac anyway, I just modified the text slightly and added your suggestion in a tooltip instead. void LyXRC::setDefaults() {+	mac_dontswap_ctrl_meta = false;concerning the default value - this is the current value lyx uses or are we changing defaults?also put this assignment more down between other rc settings concerning keyboard.Yes, the default _is_ to swap Apple and Ctrl keys. That's what makes this so annoying to emacs users. And by _not_ swapping these modifier keys we are changing the default. The check box unchecked when the default setting is desired. Basically I'm following the nomenclature as dictated by Qt's convoluted Mac behavior (their Attribute "MacDontSwapCtrlAndMeta" is false by default)... other parts looks fine. (dow we have already GPL statement from you?)Probably not - I'll send it in the next message.Jens

GPL statement

[Jens Nöckel]

Hi again,
sorry that my patch still appears to be encoded wrong... it opens fine for me 
but I'll see how I can change mime type next time. Anyway, here is the 
statement:

I hereby grant permission to license my contributions to LyX under the Gnu 
General Public Licence, version 2 or later.

Jens


 

Re: Please, verify the INSTALL on MacOSX document...

[Jens Nöckel]

On Sep 18, 2010, at 6:33 PM, BH wrote:
 
 That's it. Nice job with the clear documentation ... and nice work on
 LyX/Mac quite generally. It's coming along great!

Hi Bennett,
I agree the INSTALL.MacOSX is now much more comprehensive and useful!
I had to make some adjustments though, because I compiled on a machine where I 
use fink instead of MacPorts (our newest Mac uses MacPorts, but I'm not 
compiling LyX on that one... just to make life more interesting). 
So in my case, here is a summary of the steps, assuming you have autoconf, 
gettext and pkgconfig from fink:

1)
Compile qt-everywhere-opensource-src-4.6.3 (universal without Tiger) as in step 
1 of INSTALL.MacOSX. The download location for the source is 
ftp://ftp.qt.nokia.com/qt/source/ (which may be a little hard to find if you're 
following the link given in INSTALL.MacOSX)

2)
Then to build LyX from SVN, download the source using 
svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-devel

Set I the following flags (assuming bash syntax): 
export CFLAGS=-arch i386
export CXXFLAGS=-arch i386
export OBJCFLAGS=-arch i386
export LDFLAGS=-framework Carbon -framework AppKit -arch i386 
This differs from INSTALL.MacOSX because my version of pkgconfig wasn't clever 
enough to detect the framework dependencies automatically.

Next, in the lyx-devel directory, I did:
./autogen.sh
./configure --with-version-suffix=-2.0 --disable-stdlib-debug 
--prefix=PATH/TO/LyX.app --with-qt4-dir=/path/to/QT4 --with-libiconv-prefix=/usr
make
make install-strip

The libiconv prefix needed to be specified on the configure line to avoid 
loading an older version of that library installed by fink. 

That's how things worked for me.

Best,
Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 17, 2010, at 3:48 PM, Pavel Sanda wrote:

> Stephan Witt wrote:
>>> So if I put Pavel's suggestion in, would my checkbox patch be acceptable? 
>>> As I said, I'd be OK without GUI, but I don't really think it will hurt 
>>> anyone to have it in there, with the default being not to change the key 
>>> mapping.
>> 
>> I'd have no problem with that.
> 
> +1

OK, here is the new patch for the current LyX 2.0 in svn trunk:


modifierKey-2.diff
Description: Binary data


The check box is added in Preferences > Editing > Keyboard/Mouse, but only if 
we're on MacOSX with Qt > 4.6.0. The default setting is to leave everything as 
it is now. When the check box is set, the Mac control key will act as LyX Ctrl 
and the Mac Command key will act as LyX Meta (which is the reverse of the 
current default mapping, and is preferred by emacs users). No matter what the 
setting is, the MacOSX-specific commands for "Quit", "Hide" and "Preferences" 
will be unchanged (i.e., they continue to use the Mac Command key).

Thanks,
Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 18, 2010, at 10:14 AM, Jens Nöckel wrote:

> 
> On Sep 17, 2010, at 3:48 PM, Pavel Sanda wrote:
> 
>> Stephan Witt wrote:
>>>> So if I put Pavel's suggestion in, would my checkbox patch be acceptable? 
>>>> As I said, I'd be OK without GUI, but I don't really think it will hurt 
>>>> anyone to have it in there, with the default being not to change the key 
>>>> mapping.
>>> 
>>> I'd have no problem with that.
>> 
>> +1
> 
> OK, here is the new patch for the current LyX 2.0 in svn trunk:
> 
> 
> The check box is added in Preferences > Editing > Keyboard/Mouse, but only if 
> we're on MacOSX with Qt > 4.6.0. The default setting is to leave everything 
> as it is now. When the check box is set, the Mac control key will act as LyX 
> Ctrl and the Mac Command key will act as LyX Meta (which is the reverse of 
> the current default mapping, and is preferred by emacs users). No matter what 
> the setting is, the MacOSX-specific commands for "Quit", "Hide" and 
> "Preferences" will be unchanged (i.e., they continue to use the Mac Command 
> key).

Another comment I forgot to add (but had mentioned earlier): the change takes 
effect only after restarting LyX (because the keynoard shortcuts in the menu 
bar have to be rebuilt).

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

Another version of the patch is attached, this time hopefully readable by everyone... There was one additional line in GuiApplication.cpp that I took out - it was commented out anyway and corresponded to the initial test I described in http://wiki.lyx.org/Mac/LyXmodifierKeys#sMac.LyXmodifierKeys_5 (which is no longer the way I do things). It was put in by Stephan in rev. 34812.  

modifierKey-3.patch
Description: Binary data
Below are some more responses:On Sep 18, 2010, at 12:48 PM, Pavel Sanda wrote:i would be happy if we can get rid of any additional #ifdefs. it needs to be testedbut i guess except this part:+	dontswapCB->setVisible(false);all other parts of code could be normally written and no GUI_DONTSWAPCB_VISIBLE needed.I took those two #ifdef out.+ Do not swap Meta and Control keysadd something like "on MacOSX"...Since this text only shows up on Mac anyway, I just modified the text slightly and added your suggestion in a tooltip instead. void LyXRC::setDefaults() {+	mac_dontswap_ctrl_meta = false;concerning the default value - this is the current value lyx uses or are we changing defaults?also put this assignment more down between other rc settings concerning keyboard.Yes, the default _is_ to swap Apple and Ctrl keys. That's what makes this so annoying to emacs users. And by _not_ swapping these modifier keys we are changing the default. The check box unchecked when the default setting is desired. Basically I'm following the nomenclature as dictated by Qt's convoluted Mac behavior (their Attribute  "MacDontSwapCtrlAndMeta" is false by default)...   other parts looks fine. (dow we have already GPL statement from you?)Probably not - I'll send it in the next message.Jens

GPL statement

[Jens Nöckel]

Hi again,
sorry that my patch still appears to be encoded wrong... it opens fine for me 
but I'll see how I can change mime type next time. Anyway, here is the 
statement:

I hereby grant permission to license my contributions to LyX under the Gnu 
General Public Licence, version 2 or later.

Jens


 

Re: Please, verify the INSTALL on MacOSX document...

[Jens Nöckel]

On Sep 18, 2010, at 6:33 PM, BH wrote:
> 
> That's it. Nice job with the clear documentation ... and nice work on
> LyX/Mac quite generally. It's coming along great!

Hi Bennett,
I agree the INSTALL.MacOSX is now much more comprehensive and useful!
I had to make some adjustments though, because I compiled on a machine where I 
use fink instead of MacPorts (our newest Mac uses MacPorts, but I'm not 
compiling LyX on that one... just to make life more interesting). 
So in my case, here is a summary of the steps, assuming you have autoconf, 
gettext and pkgconfig from fink:

1)
Compile qt-everywhere-opensource-src-4.6.3 (universal without Tiger) as in step 
1 of INSTALL.MacOSX. The download location for the source is 
ftp://ftp.qt.nokia.com/qt/source/ (which may be a little hard to find if you're 
following the link given in INSTALL.MacOSX)

2)
Then to build LyX from SVN, download the source using 
svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-devel

Set I the following flags (assuming bash syntax): 
export CFLAGS="-arch i386"
export CXXFLAGS="-arch i386"
export OBJCFLAGS="-arch i386"
export LDFLAGS="-framework Carbon -framework AppKit -arch i386" 
This differs from INSTALL.MacOSX because my version of pkgconfig wasn't clever 
enough to detect the framework dependencies automatically.

Next, in the lyx-devel directory, I did:
./autogen.sh
./configure --with-version-suffix=-2.0 --disable-stdlib-debug 
--prefix=PATH/TO/LyX.app --with-qt4-dir=/path/to/QT4 --with-libiconv-prefix=/usr
make
make install-strip

The libiconv prefix needed to be specified on the configure line to avoid 
loading an older version of that library installed by fink. 

That's how things worked for me.

Best,
Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 16, 2010, at 11:24 PM, Stephan Witt wrote:

 Am 17.09.2010 um 07:57 schrieb Jens Nöckel:
 
 
 On Sep 16, 2010, at 10:30 PM, Stephan Witt wrote:
 
 Am 17.09.2010 um 06:31 schrieb Jens Nöckel:
 
 
 On Jun 5, 2010, at 7:40 PM, Jens Nöckel wrote:
 
 
 On Jun 5, 2010, at 2:37 PM, Jean-Marc Lasgouttes wrote:
 
 Le 05/06/2010 18:45, Jens Nöckel a écrit :
 So my question to the LyX dev team would be: could you add a preference 
 item that lets the user set some flag, so that the call
 setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
 can be made dependent on that flag? Maybe the simplest place to put 
 this in would be not in the Preferences, but in the Mac-only part of 
 the LyX menu. But on the other hand, that wouldn't look very consistent 
 - so the Preferences, under Keyboard/Mouse would perhaps be the most 
 logical location where to add such a flag. Any ideas on that would be 
 great - I'm sure it should be possible to add a little extra button 
 somewhere.
 
 This should be done in a way that does not break with qt  4.6.
 
 JMarc
 
 I've added a new boolean variable called lyxrc.mac_dontswap_ctrl_meta and 
 successfully connected it to a checkbox in the Keyboard Preferences. The 
 default value is false (meaning the current standard behavior - this 
 follows the nomenclature of Qt::MacDontSwapCtrlAndMeta). Then I added the 
 line
 
   
 setAttribute(Qt::AA_MacDontSwapCtrlAndMeta,lyxrc.mac_dontswap_ctrl_meta);
 
 in  GuiApplication::execBatchCommands()
 
 right after
 
 #ifdef Q_WS_MACX
 
 Everything is working great. I can set the preference and it gets applied 
 when the application is re-launched (maybe one could apply it 
 immediately, but I wasn't sure how I can then make sure that the menu 
 shortcuts are updated to display the correct modifier keys). If anyone 
 sees something wrong with this approach, please let me know.
 
 To avoid problems with earlier Qt versions, I will (but haven't yet) 
 enclose all my code in: 
 
 #if QT_VERSION  0x040600
 ...
 #endif
 
 and if it isn't already there, I'll also put in 
 #ifdef Q_WS_MACX
 ...
 #endif
 
 All my testing was done with the official lyx-1.6.1 source release, so my 
 next hurdle will be to get an SVN version to build. I haven't tried that 
 for several years, so I may have some  questions tomorrow... if all else 
 fails, I could perhaps just send the diffs to the official release.
 
 Jens
 
 
 
 Hi again,
 it's been a while, but now I have a patch for lyx-devel/trunk that 
 implements the customizable switching of Control and Modifier keys on Mac 
 OS X for LyX 2.0 with Qt 4.6.
 
 Hi Jens,
 
 I'm not the nestor here but I'd like to welcome you.
 
 Although I still have (at least) one open problem, maybe someone here 
 wants to try it out (I tested it and it works with the svn checkout):
 
 modifierKey.diff.zip
 
 As a brief explanation: By setting a preference, you decide whether Ctrl 
 and Meta are swapped next time LyX starts up (as is currently hard-coded 
 in LyX/Mac), or not (as many emacs users prefer).
 
 (Sorry, I should have raised my hand earlier.)
 
 I'm not a emacs user. So I wouldn't use that feature. In fact, I tried it 
 and decided I don't like it. 
 I don't know any application where you can swap Ctrl and Meta. Neither on 
 MacOSX nor on Windows or Linux.
 The option to do so with Qt4 makes me think that this shouldn't be done at 
 application level. 
 It should be a global Qt preference. That's my personal opinion. But of 
 course it's a matter of taste...
 Is there any other application using that feature (except emacs I guess)?
 
 My main question is still the following: 
 There is now a new checkbox in frontend/qt/ui/PrefInput.ui which 
 determines the role of Control and Apple keys, but this new UI element 
 will appear for all versions of Qt and all platforms, even though it has 
 an effect only with Qt = 4.6 (in the other files, my changes are only 
 applied when the right OS and version is detected). In order to make this 
 checkbox disappear when it's not needed, what is the best approach? Is 
 there a Qt or LyX directive for conditional UI elements that I could use 
 in PrefInput.ui (similar to compiler directives as in my previous post)? 
 My guess is that the answer is no. 
 
 I don't know, but I would look for a function to hide the UI element 
 conditionally.
 
 Perhaps it is enough to have that preference without UI at first, document 
 it and ask users later about the 
 acceptance and how urgent the UI is needed.
 
 An alternative would be to patch PrefInput.ui at the configure stage when 
 MacOSX is detected.
 
 This is not that nice. You have to move to something like PrefInput.ui.in 
 for SVN check-in and remove the real PrefInput.ui from VCS.
 Next you have to care for at least 3 build systems - autotools, cmake and 
 scons. I would strongly vote against that move.
 
 But there I would need advice from someone who knows the LyX build system.
 
 
 Two formal points:
 * You sent a patch of 4k size as zip file

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 17, 2010, at 3:53 AM, Pavel Sanda wrote:

 Stephan Witt wrote:
 
 ... its little bit hard to follow the thread when people dont kill the unused 
 top lines
 
 There is now a new checkbox in frontend/qt/ui/PrefInput.ui which determines 
 the role of Control and Apple keys, but this new UI element will appear for 
 all versions of Qt and all platforms, even though it has an effect only 
 with Qt = 4.6 (in the other files, my changes are only applied when the 
 right OS and version is detected). In order to make this checkbox disappear 
 when it's not needed, what is the best approach? Is there a Qt or LyX 
 directive for conditional UI elements that I could use in PrefInput.ui 
 (similar to compiler directives as in my previous post)? My guess is that 
 the answer is no. 
 
 I don't know, but I would look for a function to hide the UI element 
 conditionally.
 
 if you mean hide for other archs on solution would be to have normal rc 
 variable and in gui code put something like
 #ifndef MACOSX
 chanegBindingCB.setVisible(false);
 #endif

That's exactly what I was looking for! 
And regarding Stefan's observation that the prescription on the Wiki for a 
plist item for this Qt attribute doesn't work: yes, without patching Qt I can 
currently only see application-specific mechanisms for setting this dontSwap 
attribute. 
So if I put Pavel's suggestion in, would my checkbox patch be acceptable? As I 
said, I'd be OK without GUI, but I don't really think it will hurt anyone to 
have it in there, with the default being not to change the key mapping.

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 16, 2010, at 11:24 PM, Stephan Witt wrote:

> Am 17.09.2010 um 07:57 schrieb Jens Nöckel:
> 
>> 
>> On Sep 16, 2010, at 10:30 PM, Stephan Witt wrote:
>> 
>>> Am 17.09.2010 um 06:31 schrieb Jens Nöckel:
>>> 
>>>> 
>>>> On Jun 5, 2010, at 7:40 PM, Jens Nöckel wrote:
>>>> 
>>>>> 
>>>>> On Jun 5, 2010, at 2:37 PM, Jean-Marc Lasgouttes wrote:
>>>>> 
>>>>>> Le 05/06/2010 18:45, Jens Nöckel a écrit :
>>>>>>> So my question to the LyX dev team would be: could you add a preference 
>>>>>>> item that lets the user set some flag, so that the call
>>>>>>> setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
>>>>>>> can be made dependent on that flag? Maybe the simplest place to put 
>>>>>>> this in would be not in the Preferences, but in the Mac-only part of 
>>>>>>> the LyX menu. But on the other hand, that wouldn't look very consistent 
>>>>>>> - so the Preferences, under "Keyboard/Mouse" would perhaps be the most 
>>>>>>> logical location where to add such a flag. Any ideas on that would be 
>>>>>>> great - I'm sure it should be possible to add a little extra button 
>>>>>>> somewhere.
>>>>>> 
>>>>>> This should be done in a way that does not break with qt < 4.6.
>>>>>> 
>>>>>> JMarc
>>>>> 
>>>>> I've added a new boolean variable called lyxrc.mac_dontswap_ctrl_meta and 
>>>>> successfully connected it to a checkbox in the Keyboard Preferences. The 
>>>>> default value is false (meaning the current standard behavior - this 
>>>>> follows the nomenclature of Qt::MacDontSwapCtrlAndMeta). Then I added the 
>>>>> line
>>>>> 
>>>>>   
>>>>> setAttribute(Qt::AA_MacDontSwapCtrlAndMeta,lyxrc.mac_dontswap_ctrl_meta);
>>>>> 
>>>>> in  GuiApplication::execBatchCommands()
>>>>> 
>>>>> right after
>>>>> 
>>>>> #ifdef Q_WS_MACX
>>>>> 
>>>>> Everything is working great. I can set the preference and it gets applied 
>>>>> when the application is re-launched (maybe one could apply it 
>>>>> immediately, but I wasn't sure how I can then make sure that the menu 
>>>>> shortcuts are updated to display the correct modifier keys). If anyone 
>>>>> sees something wrong with this approach, please let me know.
>>>>> 
>>>>> To avoid problems with earlier Qt versions, I will (but haven't yet) 
>>>>> enclose all my code in: 
>>>>> 
>>>>> #if QT_VERSION > 0x040600
>>>>> ...
>>>>> #endif
>>>>> 
>>>>> and if it isn't already there, I'll also put in 
>>>>> #ifdef Q_WS_MACX
>>>>> ...
>>>>> #endif
>>>>> 
>>>>> All my testing was done with the official lyx-1.6.1 source release, so my 
>>>>> next hurdle will be to get an SVN version to build. I haven't tried that 
>>>>> for several years, so I may have some  questions tomorrow... if all else 
>>>>> fails, I could perhaps just send the diffs to the official release.
>>>>> 
>>>>> Jens
>>>>> 
>>>>> 
>>>> 
>>>> Hi again,
>>>> it's been a while, but now I have a patch for lyx-devel/trunk that 
>>>> implements the customizable switching of Control and Modifier keys on Mac 
>>>> OS X for LyX 2.0 with Qt 4.6.
>>> 
>>> Hi Jens,
>>> 
>>> I'm not the nestor here but I'd like to welcome you.
>>> 
>>>> Although I still have (at least) one open problem, maybe someone here 
>>>> wants to try it out (I tested it and it works with the svn checkout):
>>>> 
>>>> 
>>>> 
>>>> As a brief explanation: By setting a preference, you decide whether Ctrl 
>>>> and Meta are swapped next time LyX starts up (as is currently hard-coded 
>>>> in LyX/Mac), or not (as many emacs users prefer).
>>> 
>>> (Sorry, I should have raised my hand earlier.)
>>> 
>>> I'm not a emacs user. So I wouldn't use that feature. In fact, I tried it 
>>> and decided I don't like it. 
>>> I don't know any application where you can swap Ctrl and Meta.

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 17, 2010, at 3:53 AM, Pavel Sanda wrote:

> Stephan Witt wrote:
> 
> ... its little bit hard to follow the thread when people dont kill the unused 
> top lines
> 
>>> There is now a new checkbox in frontend/qt/ui/PrefInput.ui which determines 
>>> the role of Control and Apple keys, but this new UI element will appear for 
>>> all versions of Qt and all platforms, even though it has an effect only 
>>> with Qt >= 4.6 (in the other files, my changes are only applied when the 
>>> right OS and version is detected). In order to make this checkbox disappear 
>>> when it's not needed, what is the best approach? Is there a Qt or LyX 
>>> directive for conditional UI elements that I could use in PrefInput.ui 
>>> (similar to compiler directives as in my previous post)? My guess is that 
>>> the answer is no. 
>> 
>> I don't know, but I would look for a function to hide the UI element 
>> conditionally.
> 
> if you mean hide for other archs on solution would be to have normal rc 
> variable and in gui code put something like
> #ifndef MACOSX
> chanegBindingCB.setVisible(false);
> #endif

That's exactly what I was looking for! 
And regarding Stefan's observation that the prescription on the Wiki for a 
plist item for this Qt attribute doesn't work: yes, without patching Qt I can 
currently only see application-specific mechanisms for setting this "dontSwap" 
attribute. 
So if I put Pavel's suggestion in, would my checkbox patch be acceptable? As I 
said, I'd be OK without GUI, but I don't really think it will hurt anyone to 
have it in there, with the default being not to change the key mapping.

Jens

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 16, 2010, at 10:30 PM, Stephan Witt wrote:

 Am 17.09.2010 um 06:31 schrieb Jens Nöckel:
 
 
 On Jun 5, 2010, at 7:40 PM, Jens Nöckel wrote:
 
 
 On Jun 5, 2010, at 2:37 PM, Jean-Marc Lasgouttes wrote:
 
 Le 05/06/2010 18:45, Jens Nöckel a écrit :
 So my question to the LyX dev team would be: could you add a preference 
 item that lets the user set some flag, so that the call
 setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
 can be made dependent on that flag? Maybe the simplest place to put this 
 in would be not in the Preferences, but in the Mac-only part of the LyX 
 menu. But on the other hand, that wouldn't look very consistent - so the 
 Preferences, under Keyboard/Mouse would perhaps be the most logical 
 location where to add such a flag. Any ideas on that would be great - I'm 
 sure it should be possible to add a little extra button somewhere.
 
 This should be done in a way that does not break with qt  4.6.
 
 JMarc
 
 I've added a new boolean variable called lyxrc.mac_dontswap_ctrl_meta and 
 successfully connected it to a checkbox in the Keyboard Preferences. The 
 default value is false (meaning the current standard behavior - this 
 follows the nomenclature of Qt::MacDontSwapCtrlAndMeta). Then I added the 
 line
 
 
 setAttribute(Qt::AA_MacDontSwapCtrlAndMeta,lyxrc.mac_dontswap_ctrl_meta);
 
 in  GuiApplication::execBatchCommands()
 
 right after
 
 #ifdef Q_WS_MACX
 
 Everything is working great. I can set the preference and it gets applied 
 when the application is re-launched (maybe one could apply it immediately, 
 but I wasn't sure how I can then make sure that the menu shortcuts are 
 updated to display the correct modifier keys). If anyone sees something 
 wrong with this approach, please let me know.
 
 To avoid problems with earlier Qt versions, I will (but haven't yet) 
 enclose all my code in: 
 
 #if QT_VERSION  0x040600
 ...
 #endif
 
 and if it isn't already there, I'll also put in 
 #ifdef Q_WS_MACX
 ...
 #endif
 
 All my testing was done with the official lyx-1.6.1 source release, so my 
 next hurdle will be to get an SVN version to build. I haven't tried that 
 for several years, so I may have some  questions tomorrow... if all else 
 fails, I could perhaps just send the diffs to the official release.
 
 Jens
 
 
 
 Hi again,
 it's been a while, but now I have a patch for lyx-devel/trunk that 
 implements the customizable switching of Control and Modifier keys on Mac OS 
 X for LyX 2.0 with Qt 4.6.
 
 Hi Jens,
 
 I'm not the nestor here but I'd like to welcome you.
 
 Although I still have (at least) one open problem, maybe someone here wants 
 to try it out (I tested it and it works with the svn checkout):
 
 modifierKey.diff.zip
 
 As a brief explanation: By setting a preference, you decide whether Ctrl and 
 Meta are swapped next time LyX starts up (as is currently hard-coded in 
 LyX/Mac), or not (as many emacs users prefer).
 
 (Sorry, I should have raised my hand earlier.)
 
 I'm not a emacs user. So I wouldn't use that feature. In fact, I tried it and 
 decided I don't like it. 
 I don't know any application where you can swap Ctrl and Meta. Neither on 
 MacOSX nor on Windows or Linux.
 The option to do so with Qt4 makes me think that this shouldn't be done at 
 application level. 
 It should be a global Qt preference. That's my personal opinion. But of 
 course it's a matter of taste...
 Is there any other application using that feature (except emacs I guess)?
 
 My main question is still the following: 
 There is now a new checkbox in frontend/qt/ui/PrefInput.ui which determines 
 the role of Control and Apple keys, but this new UI element will appear for 
 all versions of Qt and all platforms, even though it has an effect only with 
 Qt = 4.6 (in the other files, my changes are only applied when the right OS 
 and version is detected). In order to make this checkbox disappear when it's 
 not needed, what is the best approach? Is there a Qt or LyX directive for 
 conditional UI elements that I could use in PrefInput.ui (similar to 
 compiler directives as in my previous post)? My guess is that the answer is 
 no. 
 
 I don't know, but I would look for a function to hide the UI element 
 conditionally.
 
 Perhaps it is enough to have that preference without UI at first, document it 
 and ask users later about the 
 acceptance and how urgent the UI is needed.
 
 An alternative would be to patch PrefInput.ui at the configure stage when 
 MacOSX is detected.
 
 This is not that nice. You have to move to something like PrefInput.ui.in for 
 SVN check-in and remove the real PrefInput.ui from VCS.
 Next you have to care for at least 3 build systems - autotools, cmake and 
 scons. I would strongly vote against that move.
 
 But there I would need advice from someone who knows the LyX build system.
 
 
 Two formal points:
 * You sent a patch of 4k size as zip file - so you make it impossible to view 
 it inline. 
  I had the patch to save and unpack to read

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Sep 16, 2010, at 10:30 PM, Stephan Witt wrote:

> Am 17.09.2010 um 06:31 schrieb Jens Nöckel:
> 
>> 
>> On Jun 5, 2010, at 7:40 PM, Jens Nöckel wrote:
>> 
>>> 
>>> On Jun 5, 2010, at 2:37 PM, Jean-Marc Lasgouttes wrote:
>>> 
>>>> Le 05/06/2010 18:45, Jens Nöckel a écrit :
>>>>> So my question to the LyX dev team would be: could you add a preference 
>>>>> item that lets the user set some flag, so that the call
>>>>> setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
>>>>> can be made dependent on that flag? Maybe the simplest place to put this 
>>>>> in would be not in the Preferences, but in the Mac-only part of the LyX 
>>>>> menu. But on the other hand, that wouldn't look very consistent - so the 
>>>>> Preferences, under "Keyboard/Mouse" would perhaps be the most logical 
>>>>> location where to add such a flag. Any ideas on that would be great - I'm 
>>>>> sure it should be possible to add a little extra button somewhere.
>>>> 
>>>> This should be done in a way that does not break with qt < 4.6.
>>>> 
>>>> JMarc
>>> 
>>> I've added a new boolean variable called lyxrc.mac_dontswap_ctrl_meta and 
>>> successfully connected it to a checkbox in the Keyboard Preferences. The 
>>> default value is false (meaning the current standard behavior - this 
>>> follows the nomenclature of Qt::MacDontSwapCtrlAndMeta). Then I added the 
>>> line
>>> 
>>> 
>>> setAttribute(Qt::AA_MacDontSwapCtrlAndMeta,lyxrc.mac_dontswap_ctrl_meta);
>>> 
>>> in  GuiApplication::execBatchCommands()
>>> 
>>> right after
>>> 
>>> #ifdef Q_WS_MACX
>>> 
>>> Everything is working great. I can set the preference and it gets applied 
>>> when the application is re-launched (maybe one could apply it immediately, 
>>> but I wasn't sure how I can then make sure that the menu shortcuts are 
>>> updated to display the correct modifier keys). If anyone sees something 
>>> wrong with this approach, please let me know.
>>> 
>>> To avoid problems with earlier Qt versions, I will (but haven't yet) 
>>> enclose all my code in: 
>>> 
>>> #if QT_VERSION > 0x040600
>>> ...
>>> #endif
>>> 
>>> and if it isn't already there, I'll also put in 
>>> #ifdef Q_WS_MACX
>>> ...
>>> #endif
>>> 
>>> All my testing was done with the official lyx-1.6.1 source release, so my 
>>> next hurdle will be to get an SVN version to build. I haven't tried that 
>>> for several years, so I may have some  questions tomorrow... if all else 
>>> fails, I could perhaps just send the diffs to the official release.
>>> 
>>> Jens
>>> 
>>> 
>> 
>> Hi again,
>> it's been a while, but now I have a patch for lyx-devel/trunk that 
>> implements the customizable switching of Control and Modifier keys on Mac OS 
>> X for LyX 2.0 with Qt 4.6.
> 
> Hi Jens,
> 
> I'm not the nestor here but I'd like to welcome you.
> 
>> Although I still have (at least) one open problem, maybe someone here wants 
>> to try it out (I tested it and it works with the svn checkout):
>> 
>> 
>> 
>> As a brief explanation: By setting a preference, you decide whether Ctrl and 
>> Meta are swapped next time LyX starts up (as is currently hard-coded in 
>> LyX/Mac), or not (as many emacs users prefer).
> 
> (Sorry, I should have raised my hand earlier.)
> 
> I'm not a emacs user. So I wouldn't use that feature. In fact, I tried it and 
> decided I don't like it. 
> I don't know any application where you can swap Ctrl and Meta. Neither on 
> MacOSX nor on Windows or Linux.
> The option to do so with Qt4 makes me think that this shouldn't be done at 
> application level. 
> It should be a global Qt preference. That's my personal opinion. But of 
> course it's a matter of taste...
> Is there any other application using that feature (except emacs I guess)?
> 
>> My main question is still the following: 
>> There is now a new checkbox in frontend/qt/ui/PrefInput.ui which determines 
>> the role of Control and Apple keys, but this new UI element will appear for 
>> all versions of Qt and all platforms, even though it has an effect only with 
>> Qt >= 4.6 (in the other files, my changes are only applied when the right OS 
>> and version is detected). In order to make this checkbox disappear when it's 
>> not needed, w

No scroll wheel in LyX/Qt 4.6.2 on Mac

[Jens Nöckel]

Hi, 
while testing LyX 1.6.6.1 with Qt 6.6.2 on Mac OS X Snow Leopard, I noticed 
that the scroll wheel on my mouse doesn't work (same for laptop trackpads). I 
then tried lyx 2.0.0 from the lyx-devel SVN repository, and found the same 
behavior (compiled against the same Qt). 
I had compiled Qt 4.6.2 by following the instructions in INSTALL.MacOSX without 
any modifications. To compile LyX, I only set CXXFLAGS and CFLAGS to -arch 
i386.  On the LyX ./configure command line I also added that flag (I also added 
a --with-libiconv-prefix option to specify which libiconv to use, but that 
should be irrelevant). I made no changes to the sources.

Can anyone reproduce this issue?  

Jens

No scroll wheel in LyX/Qt 4.6.2 on Mac

[Jens Nöckel]

Hi, 
while testing LyX 1.6.6.1 with Qt 6.6.2 on Mac OS X Snow Leopard, I noticed 
that the scroll wheel on my mouse doesn't work (same for laptop trackpads). I 
then tried lyx 2.0.0 from the lyx-devel SVN repository, and found the same 
behavior (compiled against the same Qt). 
I had compiled Qt 4.6.2 by following the instructions in INSTALL.MacOSX without 
any modifications. To compile LyX, I only set CXXFLAGS and CFLAGS to -arch 
i386.  On the LyX ./configure command line I also added that flag (I also added 
a --with-libiconv-prefix option to specify which libiconv to use, but that 
should be irrelevant). I made no changes to the sources.

Can anyone reproduce this issue?  

Jens

Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

Hi,
there finally is a solution in sight for the long-standing issue that some Mac 
users have with the swapped role of the Meta and Control keys in Qt. I have 
summarized my preliminary ideas on the LyX Wiki page dedicated to this topic,
http://wiki.lyx.org/Mac/LyXmodifierKeys#sMac.LyXmodifierKeys_5

There is no need to patch Qt, only a small change to LyX is needed as described 
above. 

So my question to the LyX dev team would be: could you add a preference item 
that lets the user set some flag, so that the call  
setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
can be made dependent on that flag? Maybe the simplest place to put this in 
would be not in the Preferences, but in the Mac-only part of the LyX menu. But 
on the other hand, that wouldn't look very consistent - so the Preferences, 
under Keyboard/Mouse would perhaps be the most logical location where to add 
such a flag. Any ideas on that would be great - I'm sure it should be possible 
to add a little extra button somewhere. 

That would finally give users a choice how to use command and control keys in 
LyX on the Mac - and I know that this is a problem people are struggling with, 
because I have received emails thanking me for the patched binaries that I have 
been posting at the LyX Wiki (the modifier key switch was up to now done by 
patching Qt itself, but this new proposal would finally go beyond the hacking 
stage...)

Thanks
Jens
 

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Jun 5, 2010, at 2:37 PM, Jean-Marc Lasgouttes wrote:

 Le 05/06/2010 18:45, Jens Nöckel a écrit :
 So my question to the LyX dev team would be: could you add a preference item 
 that lets the user set some flag, so that the call
 setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
 can be made dependent on that flag? Maybe the simplest place to put this in 
 would be not in the Preferences, but in the Mac-only part of the LyX menu. 
 But on the other hand, that wouldn't look very consistent - so the 
 Preferences, under Keyboard/Mouse would perhaps be the most logical 
 location where to add such a flag. Any ideas on that would be great - I'm 
 sure it should be possible to add a little extra button somewhere.
 
 This should be done in a way that does not break with qt  4.6.
 
 JMarc

I've added a new boolean variable called lyxrc.mac_dontswap_ctrl_meta and 
successfully connected it to a checkbox in the Keyboard Preferences. The 
default value is false (meaning the current standard behavior - this follows 
the nomenclature of Qt::MacDontSwapCtrlAndMeta). Then I added the line


setAttribute(Qt::AA_MacDontSwapCtrlAndMeta,lyxrc.mac_dontswap_ctrl_meta);

in  GuiApplication::execBatchCommands()

right after

#ifdef Q_WS_MACX

Everything is working great. I can set the preference and it gets applied when 
the application is re-launched (maybe one could apply it immediately, but I 
wasn't sure how I can then make sure that the menu shortcuts are updated to 
display the correct modifier keys). If anyone sees something wrong with this 
approach, please let me know.

To avoid problems with earlier Qt versions, I will (but haven't yet) enclose 
all my code in: 

#if QT_VERSION  0x040600
...
#endif

and if it isn't already there, I'll also put in 
#ifdef Q_WS_MACX
...
#endif

All my testing was done with the official lyx-1.6.1 source release, so my next 
hurdle will be to get an SVN version to build. I haven't tried that for several 
years, so I may have some  questions tomorrow... if all else fails, I could 
perhaps just send the diffs to the official release.

Jens

Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

Hi,
there finally is a solution in sight for the long-standing issue that some Mac 
users have with the swapped role of the Meta and Control keys in Qt. I have 
summarized my preliminary ideas on the LyX Wiki page dedicated to this topic,
http://wiki.lyx.org/Mac/LyXmodifierKeys#sMac.LyXmodifierKeys_5

There is no need to patch Qt, only a small change to LyX is needed as described 
above. 

So my question to the LyX dev team would be: could you add a preference item 
that lets the user set some flag, so that the call  
setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
can be made dependent on that flag? Maybe the simplest place to put this in 
would be not in the Preferences, but in the Mac-only part of the LyX menu. But 
on the other hand, that wouldn't look very consistent - so the Preferences, 
under "Keyboard/Mouse" would perhaps be the most logical location where to add 
such a flag. Any ideas on that would be great - I'm sure it should be possible 
to add a little extra button somewhere. 

That would finally give users a choice how to use command and control keys in 
LyX on the Mac - and I know that this is a problem people are struggling with, 
because I have received emails thanking me for the patched binaries that I have 
been posting at the LyX Wiki (the modifier key switch was up to now done by 
patching Qt itself, but this new proposal would finally go beyond the hacking 
stage...)

Thanks
Jens
 

Re: Solving the Meta/Control key swap problem on Mac OS X

[Jens Nöckel]

On Jun 5, 2010, at 2:37 PM, Jean-Marc Lasgouttes wrote:

> Le 05/06/2010 18:45, Jens Nöckel a écrit :
>> So my question to the LyX dev team would be: could you add a preference item 
>> that lets the user set some flag, so that the call
>> setAttribute(Qt::AA_MacDontSwapCtrlAndMeta);
>> can be made dependent on that flag? Maybe the simplest place to put this in 
>> would be not in the Preferences, but in the Mac-only part of the LyX menu. 
>> But on the other hand, that wouldn't look very consistent - so the 
>> Preferences, under "Keyboard/Mouse" would perhaps be the most logical 
>> location where to add such a flag. Any ideas on that would be great - I'm 
>> sure it should be possible to add a little extra button somewhere.
> 
> This should be done in a way that does not break with qt < 4.6.
> 
> JMarc

I've added a new boolean variable called lyxrc.mac_dontswap_ctrl_meta and 
successfully connected it to a checkbox in the Keyboard Preferences. The 
default value is false (meaning the current standard behavior - this follows 
the nomenclature of Qt::MacDontSwapCtrlAndMeta). Then I added the line


setAttribute(Qt::AA_MacDontSwapCtrlAndMeta,lyxrc.mac_dontswap_ctrl_meta);

in  GuiApplication::execBatchCommands()

right after

#ifdef Q_WS_MACX

Everything is working great. I can set the preference and it gets applied when 
the application is re-launched (maybe one could apply it immediately, but I 
wasn't sure how I can then make sure that the menu shortcuts are updated to 
display the correct modifier keys). If anyone sees something wrong with this 
approach, please let me know.

To avoid problems with earlier Qt versions, I will (but haven't yet) enclose 
all my code in: 

#if QT_VERSION > 0x040600
...
#endif

and if it isn't already there, I'll also put in 
#ifdef Q_WS_MACX
...
#endif

All my testing was done with the official lyx-1.6.1 source release, so my next 
hurdle will be to get an SVN version to build. I haven't tried that for several 
years, so I may have some  questions tomorrow... if all else fails, I could 
perhaps just send the diffs to the official release.

Jens