Am 17.09.2010 um 08:49 schrieb 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:
>>>>> 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.
>>>>> 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, 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.

A better option would be to create it hidden and make it visible only when it 
is sensible.

>>>> 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.
>>> Hi Stephan,
>>> it would be OK with me to just have a preference without UI, but I wanted 
>>> to explore the UI because Pavel already gave me a nice starting point for 
>>> how to do it (earlier in this thread). 
>> I can understand you very good.
>> (I cannot see Pavels E-Mails in this thread - but that's not the point, 
>> non-relevant).
> For completeness, here's the missing passage:


>>> Anyway, about the philosophical reasons for why this is an issue in need of 
>>> fixing, see the LyX Wiki (the discussion goes back many years, so I can't 
>>> repeat it all here):
>> I took a quick look. And had the idea to make the default for the new RC 
>> variable dynamic. It can depend on the keyboard binding.
>> When mac.bind is used make it false, for emacs.bind make it true.
> In principle that sounds interesting because mac.bind would be really weird 
> with the switched modifiers. But what if a user has a custom bind file (e.g., 
> I have a custom xemacs.bind)? The naming of bind files is arbitrary and 
> therefore shouldn't be the basis for a dynamic adjustment of the RC variable. 
> But what about extending that idea a little: if the bind file name is not 
> emacs.bind or xemacs.bind, it would most likely be including one or the 
> other, so we could search the file for "\bind_file (x)emacs.bind" ... 
> The more I think about it, the more it seems like a hack though. There should 
> be an explicit declaration of whether the switch is desired, LyX probably 
> shouldn't try to guess what the user wants.

You're right. My proposal was not thought to the end.
But I can imagine to make it three-state: No, Yes, Auto.
When "Yes" then swap, when "No" then don't swap, when "Auto" then check the 
bindings for some emacs like usage.
But it remains guessing... 

When reading the wiki I got the impression the "common" emacs user wants to 
swap the modifiers.

>>> Regarding a global Qt option: can that work if the libs are included as a 
>>> private framework?
>> I don't know if global Qt options exist and how they work if any. But, I'd 
>> guess the storage of that would be some plist file in your home dir.
>> In that sense with global I meant global for the user - not the machine.
>>> In the standalone LyX, there is no system-wide Qt that is being used, so 
>>> any Qt setting would have to be done at the application level, right?
>> I have to check Qt4 at first to answer that.
>> In general that's a question for packaging of LyX. I think LyX should work 
>> with Qt4 frameworks. Then a private framework should be provided as option 
>> for machines with no or with the wrong Qt version. Currently there is no 
>> mechanism to decide that. That's why I package LyX with private Qt4 
>> frameworks only.
>> Stephan
> OK, that would be great if you find something out - I'll also look around in 
> the Qt docs some more. 

In the wiki there is the manipulation of 
~/Library/Preferences/.GlobalPreferences.plist explained.
But it doesn't work for me... the Qt4 developers didn't implement that feature 


Reply via email to