If we will install opera with portage, opera will brake and will not use gtk or qt. opera stared from unpacked tar uses gtk for me. Opera bin installed with portage but started from dir where we unpacked package will use gtk to. Reproducible: Always Steps to Reproduce: 1.emerge opera 2.run opera 3. Actual Results: Opera isnt using qt or/and gtk. Expected Results: Opera using qt.
The current alpha builds only support the GTK+ backend, as far as I am aware, and only to display the file dialog and nothing else. A KDE backend for the same purpose should be provided in the future. In the Known Issues listing in the announcement for the latest build[1] as of now (called 10.50_pre6219 in the tree) this is described as: * No KDE integration Other than that, I don't see the "breakage" that you do - the GTK+ backend works fine for me. [1] http://my.opera.com/desktopteam/blog/2010/02/11/windows-beta-released-and-more
Created attachment 219813 [details] gtk screen Not only for file dialog. It uses is as it should for backend. On left you see opera /usr/bin/opera started from unpacked tar. On the right opera started from other localtion. Lef one uses gtk-engines-qtcurve. Style that i use for gtk(im kde user).
The thing is, Opera Software doesn't support installing these alpha builds at all, only the "unpack and run directly" from $HOME/opera/* method, if you could call these builds "supported" at all, that is. Without hacking the binaries we install to use a new path ( /opt/opera/ can't be run at all, so we have to break the filesystem directives already by putting everything in /usr to get it running. So I understand your problem but I cannot possibly begin to fix it, unless you find the flaw in the /usr/bin/opera script, because we can patch that one. You know the workaround already, so I suggest you do that until Opera fixes Unix support for 10.50. It's not even something you can ask them to fix at this point since we're basically installing the 10.50's in a way Opera Software disapproves of (so I am closing as CANTFIX instead of UPSTREAM).
line 108 -LD_LIBRARY_PATH="$PWD/usr/lib/opera${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" +LD_LIBRARY_PATH="/usr/lib/opera${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" :) you asked for it:) Dont know if i didnt brake something, but this fixes my bug.
and some more -then - OPERA_PERSONALDIR="$PWD/profile" - export OPERA_PERSONALDIR -fi then + OPERA_PERSONALDIR="$HOME/profile" export OPERA_PERSONALDIR fi and /opt killer if [ -z "$OPERA_DIR" ] then - OPERA_DIR="$PWD/usr/share/opera" fi export OPERA_DIR if [ -z "$OPERA_DIR" ] then + OPERA_DIR="/usr/share/opera" fi export OPERA_DIR
Created attachment 219915 [details, diff] pwd fixes and cleaned adobe paths im using this localy... Now this bug can be closed.
(In reply to comment #6) > Created an attachment (id=219915) [details] > pwd fixes and cleaned adobe paths > > im using this localy... Now this bug can be closed. If your only goal was to resolve your personal problem, then why did you ever open this bug report in the first place?
(In reply to comment #7) > (In reply to comment #6) > > Created an attachment (id=219915) [details] [details] > > pwd fixes and cleaned adobe paths > > > > im using this localy... Now this bug can be closed. > > If your only goal was to resolve your personal problem, then why did you ever > open this bug report in the first place? > Its not my personal problem, all users/testers are afected with it and it realy brakes GTK. Problem was found, pwd stuff can be removed and no tests needed because its simple thing. Even patch was added to make you more happy and not to mess it with hand. What you want more? You said it works for you, strange because it should not (or maybe you are starting opera from /?). I opened this bug to solve problem for all and i didnt think it will be so simple. Other thing is that if you bump package, add it to portage it should be done right not just count number of commits. This looks like you added this package to count commits on cia and get rid of people asking where is that build of opera. Its standalone package as you said, and it should not be installed, so if it gets to portage it should get more care or not get there. Its not about to make people get ebuild so you can say its in gentoo. Its about to make it right, to make it work so good as it should. Dont say its hard masked bla bla bla. Mainteiner works is hard and I think you had bad day when you added this comment, so sory, fix it and forget.
(In reply to comment #8) > > > im using this localy... Now this bug can be closed. I simply didn't understand what you mean by the above, that's all.
The patch is applied in _pre6225. Please test and reopen if it doesn't quite fix the issue yet.
