It still doesn't support unicode input, at least it garbage any non-ascii character if entered via keyboard (no such effect on copy-paste). Example: "Это пример того как Опера искривляет юникод" -- copy-pasted. Russian. Same entered by keyboard - this is valid arabic alphabet, as far as I see, even right-to-left: ۼ۔ۏ ېےۉۍۅے ۔ۏۇۏ, ۋہۋ ۯېۅےہ ۉۓۋےۉۗیۑۅ۔ ۀێۉۋۏۄ Maybe if I'll write arabic, it will write in Russian, I dunno =) Please, hardmask it, as it's breaking user profiles (it's not using ~/.opera) and not working for big part of humanity, who don't speak only English ;)
Confirmed. I have posted bugreport to opera devs, maybe they will figure something out. However, hardmask is not an option - many guys don't need Russian, e.g. I also use Finnish, and it works fine.
Hm... Xlib-don't-know-about-russian, again? =) Hardmask, imo, needed anyway: 1) It's still in some kind of alpha/beta stage - not stable by design 2) It's not using "normal" configuration directory - it's creating new one in every dir you'd started it. May be overridden, but that's not an option 3) It still crashes and hangs and eats memory too often to consider it even 'unstable' 4) Everyone, who still think that it's ok for 'unstable' arch, may have it unmasked permanently (as I have). IMO, ~arch != broken. And it's broken. For a big part of community, at least.
Sorry for duplicate comment, I agree, it should be masked. But what was it about xlib? Was there any fix for that? PS: It does not seem to hog RAM on my machine... And flash works MUCH faster. So it has some advantages.
Right, it has. But, under some circumstances it may still fail or crash. I've posted already 4 bugs into opera desktop team. There is a dozen more, I suppose, as I don't use many of it's features. xlib - yes, it was old bug about missing alias for russian unicode locates. It's invalid now. It maybe also gtk+ which is used by default, if you have it installed.
(In reply to comment #0) > Please, hardmask it, as it's breaking user profiles (it's not using ~/.opera) > and not working for big part of humanity, who don't speak only English ;) Um, so it isn't breaking user profiles since it isn't using ~/.opera ... Anyway, I just kept forgetting to update the package.mask entry. I have no idea what this "hardmask" thing is that people keep go on about[1], but I assume you meant package.mask anyway. I widened the mask to include anything 10.50 yesterday: 07 Feb 2010; Jeroen Roovers <jer@gentoo.org> package.mask: Make www-client/opera mask wider. # Jeroen Roovers <jer@gentoo.org> (5 Dec 2008) # Snapshot, labs and alpha releases but not betas and RCs of Opera =www-client/opera-10.20_pre4744 =www-client/opera-10.50* [1] We have perfectly applicable technical terms for the different types of masking we use, and none of them use the "hard" prefix.
Forgot to assign.
BTW, it's nice to get some feedback about these issues without having to skim through thousands of (mostly me-too) comments on the desktopteam blog, so thanks for reporting, people!
Created attachment 218951 [details] opera's depth 4 deptree resulting in bug happening. OK, regarding useful info: Current packages opera depends on with their versions and useflags dumped into attached file. It's kinda huge, but I hope useful in combination with grep=) It's just depth 4 otherwise it grows like hell.
Comment on attachment 218951 [details] opera's depth 4 deptree resulting in bug happening. I have no idea what that file is supposed to tell me, and it certainly should be no part of this bug report.
