From: Florian J. <flo...@we...> - 2012-03-14 03:00:41
|
hi i just read that unity has a blacklist. see this page: https://bugs.launchpad.net/midori/%2Bbug/874334 it says that midori is blacklisted and so it doesn't do that unified-menubar-thingy maybe it's exactly that what we want? honestly i think it's impossible or at least pretty hard to make muse work properly with unity. unity just cannot distinguish whether the "outer" QMainWindow or the MDI-nested-QMainWindow is the one which should display its menu. asking the unity folks to blacklist muse seems to make it usable as under any other DE: with its own menu, and its own menu-sharing magic. i think, unity users can live with this (especially in contrast to using the -u unity workaround switch) greetings flo Am 09.03.2012 12:58, schrieb Florian Jung: > Am 08.03.2012 23:35, schrieb Tim E. Real: >> I added some heavy debug (-DD) printouts in app focusChanged(). >> >> They print the old and new focus objects, and the current active window. >> Can you observe and report what it does when the bug is present? >> >> I suspect there may be some infinite refocusing going on. >> If so, the printouts will be continuously printing out. (They shouldn't.) >> > tried it with latest release_2_0. there is NO infinite refocusing. > the output scrolled pretty fast, then stopped. after i clicked away > the "did you know?" dialog, again some lines scrolled pretty fast, > then stopped again. in the meantime, unity was flickering as wild. > > i've attached the output of muse -apiDD > > strange thing > > i still suspect that the problem is that unity cannot handle a window > with a menubar (even if it's empty and hidden, which does not mean it > doesn't exist!) which is a child of another window with a menubar. > exactly that's happening when we have mdi-subwins. and internally, the > "muse main window with the arranger" is actually "the muse main > window" with "the arranger view" as full-screened MDI subwin. > > also, unity seems to be unable to deal with changing menus (which is > actually unneeded as unity emulates that behaviour), but still. > when you turn off MDI-subwins, but still use menu-sharing (works by > manipulating the config AND default.med), then muse won't flicker, but > still not be usable. because then the proper menus aren't displayed. > > there are two valid situations: > > 1. each window has no menu at all. if you want to access it, you'd > need to focus the main window first. that would be correct > behaviour, according to what unity is supposed to do > 2. each window has his menu. this would proof that unity cannot > handle menuBar()->clear() properly, (and is actually wrong > according to what unity should do), but would make muse > perfectly usable (actually, this is equivalent to -u) > > what actually happens, is that the menubar displays some random menu, > changing windows does NOT change the main win's menu, and menu bars > are completely flawed. > > > some guy who speaks QT more fluently than me could try the following: > > 1. create a window which has NO menu bar (dialog, qwidget, > whatever), and embed one (only one) QMainWindow (which has a > filled menu bar) in it > 2. do the same, but embed more than one QMainWindow with filled > menubars in it > 3. repeat 1. and 2. but embed these QMainWindows into QMdiSubWins > which live in a QMdiArea inside the "toplevel" window (the one > without a menu bar) > 4. try a QMainWindow with a QMdiArea and menu-less QMdiSubWins > 5. try a QMainWindow with a QMdiArea and QMdiSubWins which own > QMainWindows which have a menu bar > > i expect 3 to do the same as 1 and 2; also i think 1 will work, 2 will > break, 4 will work, 5 will break. > > could someone try that please? > > > greetings > flo > > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > |