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): >>>>> >>>>> <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.
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: > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg160178.html Thanks. > >>> 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): http://wiki.lyx.org/Mac/LyXmodifierKeys >> >> 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 :-) Stephan
