From: Florian J. <flo...@we...> - 2012-02-26 14:13:04
|
Am 26.02.2012 09:36, schrieb Tim E. Real: > On February 25, 2012 7:59:44 PM Florian Jung wrote: > >> i tried ubuntu on a spare pc now, i can reproduce the bug. and i can say >> that i still hate ubuntu, and will start hating unity x_X >> >> my observations: >> while the menus are flickering (which is _definitely_ a bug in unity, >> not in muse. other windows are affected as well!), with some luck you >> can click on the "window configuration" menu. then unselect "is a >> subwin". once you moved the arranger out of the main win, the flickering >> stops. >> then uncheck "shares menu/toolbar" as well, then you have a completely >> usable muse. >> >> the following might fix the problem in a way the ubuntu folks can do: >> >> * change the default.med (and all other templates) so that the >> arranger is opened as free-floating window (not as subwindow of >> the mainwin), with toolbar sharing disabled >> * change the default MusE.cfg, so that no windows (especially not >> the arrangers) share menu or are subwins. >> * disable the menu entries "as subwin" and "shares tools/menu" (but >> not hardcoded, there are still users with sane WMs!) >> >> >> this will result in a pretty useless main window (only "save", "load", >> "help", "config" and stuff), but muse is usable at least. >> >> btw, another thing i observed: whenever running muse on ubuntu/unity >> with the -DD (heavyDebugMsg) option activated, the system becomes >> unusable (_really_ unusable: a ssh-session lags up to ten seconds!), and >> seems to run out of memory (i have still 200MB free. this is not much of >> course, but muse may not take 200MB in debug mode when it's content with >> few MB in normal mode). i even wasn't able to run 'top', 'htop', >> 'killall'! ("bash: fork failed. out of memory"). (ps ax and kill worked >> fortunately ;) ) >> >> will investigate further. >> >> >> >> question to you devs: >> shall WE include support for unity, for example an alternative set of >> templates and default config? (how could we do this?) >> or should we only tell the ubuntu folks what's the problem, how to work >> around it, and maybe a patch for the default config / templates? >> >> i'd frankly prefer the second solution. i think this is actually their >> problem and not ours, and by silently working around on ourselves, they >> never have an incentive to fix the actual problem. and WE have the work >> with keeping a normal and a ubuntu version around. >> when we only support them in fixing it themselves, they, well, get it >> fixed ;) >> >> what do you think? >> >> greetings >> flo >> > Question: Are we absolutely sure that it's not MusE's fault? > no. but qt offers to put arbitrary widgets (including QMainWindows) as children of other widgets. qt offers to clear the menu bar, and qt offers to add menu entries to the menu bar. qt offers to change parents of a widget. that's all we do (plus some focus black magic, but that cannot cause such flickering; it could only cause the wrong menu being displayed, but surely not screw up the whole desktop environment). so MusE behaves completely legal. in my opinion, it's not our fault. but of course we should be a bit diplomatic: not "hey, that's your fault, we demand that you fix it!" but "hey, there is $problem, which we think is not our fault (paste explanation above). is it possible that unity does some black magic causing the problem" > Has anyone tried other desktops? I'm using KDE. What are you guys using? > XFCE, using xfwm4 or openbox. both work fine. i assume KDE works for you as well, tim? (kde4 i assume?) > Geoff said Enlightenment I think. > > Also are other apps reporting these exact problems with Unity too? > i quickly googled it, found nothing similar to our particular problem. but different problems regarding the menu bar. > If it's Unity + other desktops + only MusE, then we got problems. > If it's only Unity + MusE + other apps, then I guess it's their problem. > If it's only Unity + MusE, well I dunno - a tossup? We use some sophisticated > stuff maybe nobody else is using thus has not revealed problems yet. Maybe > we can help them... But first, are we using these techniques correctly... > i think we do. let's try putting a QMainwindow with a menu inside another QMainWindow with a menu as well. if unity fails there as well, then it's definitely a unity problem. greetings flo > --- > Still working on focus stuff. Like wading through molasses. Slowly making > progress. Tried several techniques, turns out need them all to nail down the > canvas focusing. Muddy water: Toolbars can be dragged outside the menus! > Quiet now but hope to have something soon. > > Cheers. Tim. > > >> Am 22.02.2012 15:25, schrieb Florian Jung: >> >>> robert, would you please try editing your .config/MusE/MusE.cfg, so that >>> all tags containing "shares" are set to "0"? >>> see my last email for more details >>> >>> 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 > > |