On Jul 26, 2006, at 12:13 AM, Georg Baum wrote:
Jens Noeckel wrote:
Hi,
with the help of Bennett's install instructions, I compiled LyX 1.4.2
on my Intel Mac using gcc 4.0 and Qt 3.3.6.
Great. When the problems are resolved it would be very nice if you
couild
provide an installer for intel macs.
Thanks for the quick response! Yes, in fact Bennett has already put
it into an installer package, but obviously I'd like to fix the
binary before it's ready for public consumption. However, if anyone
wants to try the Mac Intel binary package as it is now, let me know.
It would be interesting to clarify if A.S.Hodel's analogous problem
happened on the PPC or on the Intel platform. I hope someone can help
narrow down the source of this weirdness... I've looked at the
standard.ui interface file and it seems to define all the menu items
properly. Somehow the mapping of the user input to the lyx function
is scrambled. Since the menus themselves look OK (e.g., Quit appears
where it should, with the Command-Q shortcut displayed next to it),
I'd suspect that this isn't directly a Qt issue.
This may have something to do with some ugly tricks we are playing
to stop
qt to rearrange the menus. See src/frontends/qt2/QLMenubar.C and
src/frontends/qt2/lyx_gui.C (search for code inside #ifdef
Q_WS_MACX). Does
it work if you disable the special mac menu code?
First to answer Bennett's question about when the scrambled
translation from menu into lyx function occurs:
Yes, it persisted when I tried for a new user. The lyx functions that
the menu is supposed to call work fine if I invoke them from the lyx
command line: e.g. "show-dialog prefs " works fine even when neither
the Command-, shortcut NOR the mouse-interaction with the pull-down
menu work for the Preferences item under the LyX menu.
Some more "phenomenology": In my case, the scrambled menu translation
happened reproducibly WITHOUT my having to first export or view
anything from lyx (BTW, those functions all work fine, too).
Since the menu mapping is shifted by one in the upward direction, I
get the About Box when choosing the preferences. Of course that
raises the question what happens when I choose the top-most menu item
(the About Box). Shudder. After overcoming the hesitation, I clicked
"About Box" and found that LyX now wants to send my Document as a
FAX! So the menu spills over into another one! What happens is that
KDEprintfax (under X11 on my system) starts up... very funny if
you're expecting an About Box.
As Georg suggested, I tried to remove the LyX menu stuff from the
above files by hand, and re-compiled. In fact, I found another place
that (according to the Changelog) needs to be changed (I think):
QLPopupMenu.C
Unfortunately, no matter what I tried (different combinations of what
to erase), it causes LyX to crash on startup. I probably didn't
remove enough (or too much?) of the Mac specific stuff. Here is what
I commented out in src/frontends/qt2/lyx_gui.C:
Line 188:
// #ifdef Q_WS_MACX
// These translations are meant to break Qt/Mac menu merging
// algorithm on some entries. It lists the menu names that
// should not be moved to the LyX menu
// QTranslator aqua_trans(0);
// aqua_trans.insert(QTranslatorMessage("QMenuBar",
"Setting", 0,
//
"do_not_merge_me"));
// aqua_trans.insert(QTranslatorMessage("QMenuBar",
"Config", 0,
//
"do_not_merge_me"));
// aqua_trans.insert(QTranslatorMessage("QMenuBar",
"Options", 0,
//
"do_not_merge_me"));
// aqua_trans.insert(QTranslatorMessage("QMenuBar",
"Setup", 0,
//
"do_not_merge_me"));
// qApp->installTranslator(&aqua_trans);
// #endif
And here is what I commented out in src/frontends/qt2/QLMenubar.C
Line 33:
// #ifdef Q_WS_MACX
// , menubar_(new QMenuBar)
// #endif
Line 44:
// #ifdef Q_WS_MACX
// this is the name of the menu that contains our special
entries
// menubackend_.specialMenu("LyX");
// make sure that the special entries are added to the first
// menu even before this menu has been opened.
// name_map_[mbe.getMenubar().begin()->submenuname()]-
>showing();
// #endif
Finally, in src/frontends/qt2/QLPopupMenu.C:
Line 96:
// #ifdef Q_WS_MACX
//if (index >= indexOffset) {
// MenuItem mi = owner_->backend().getMenu("LyX")[index
- indexOffset];
// owner_->view()->activated(mi.func());
//} else
Line 166:
//#ifdef Q_WS_MACX
/* The qt/mac menu code has a very silly hack that
moves some menu entries that it recognizes by name
(e.g. "Preferences...") to the "LyX" menu. This
feature can only work if the menu entries are
always available. Since we build menus on demand,
we add some dummy contents to one of the menus (JMarc)
*/
// static QLPopupMenu * themenu = this;
// if (themenu == this && owner_->backend().hasMenu
("LyX")) {
// Menu special = owner_->backend().getMenu
("LyX");
// Menu::const_iterator end = special.end();
// Menu::size_type i = 0;
// for (Menu::const_iterator cit = special.begin
();
// cit != end ; ++cit, ++i)
// insertItem(toqstr(cit->label()),
indexOffset + i);
// }
//#endif
These GUI hacks are not at all transparent to me, so I think someone
else (maybe Georg or JMarc) should have a look at this. Apart from
the LyX menu, everything else works perfectly (as far as I can tell).
There was this additional suggestion quoted below - but I couldn't
find any menubar_mac.cpp in my lyx source tree, so I'm not sure how
to try this suggestion. Maybe you can point me to where that function
"qt_mac_set_no_menubar_merge" should be defined?
I'll post some more information about how I compiled on Intel in my
next mail (trying to keep the subjects separate).
Jens
On Jul 26, 2006, at 4:16 AM, Andreas Vox wrote:
Georg Baum <[EMAIL PROTECTED]> writes:
This may have something to do with some ugly tricks we are playing
to stop
qt to rearrange the menus. See src/frontends/qt2/QLMenubar.C and
src/frontends/qt2/lyx_gui.C (search for code inside #ifdef
Q_WS_MACX). Does
it work if you disable the special mac menu code?
Hi all!
Maybe using this function in qmenubar_mac.cpp would avoid the side
effects?
static bool qt_mac_no_menubar_merge = FALSE;
void qt_mac_set_no_menubar_merge(bool b) {
qt_mac_no_menubar_merge = b;
} //back door to disable merging
