Originally Posted by misiak

I don't know, sorry I'm waiting for my second device (I will have two N900s ), when it arrives, I will check window names with modified hildon-desktop and report back (it should happen this week).

Originally Posted by marmistrz

OK, I'll be patient
Just to make sure I'm writing clear: I'm blacklisting the right window name but it still rotates!

Originally Posted by misiak

Ok, I've modified hildon-desktop run some tests, the results were... strange. Hildon-home may be buggy.

First thing, while I still remember it and before I start describing my results: http://linuxtesting.org/compatibilit...at_report.html - can this list be usefull to you? (maybe you've seen it before?) It should help in completing missing libraries

So, back to the point: the hildon-desktop blackist check is quite inconsistent... My exact testing procedure (I'm writing it so any other interested programmer can do the same and check if results are reproducable):
1. Got my new N900
2. Installed updates to PR1.3.1
3. Installed CSSU stable, version: 21.2011.38-1Smaemo3, flavour: stable
4. On my ubuntu pc, in scratchbox, added deb and deb-src lines with stable community repo:

Code:

deb http://repository.maemo.org/community/ fremantle free non-free
deb-src http://repository.maemo.org/community/ fremantle free

then:

Code:

apt-get update
apt-get build-dep hildon-desktop
apt-get source hildon-desktop

then I applied changes to file src/mb/hd-comp-mgr.c - added logging to functions hd_com_mgr_is_whitelisted and hd_comp_mgr_is_blacklisted, the diff of source code can be found here: http://dev.miskiewicz.org/maemo/hild...42-19.diff.txt
Then I typed

Code:

./autogen.sh
fakeroot dpkg-buildpackage

and copied resulting deb to device. The deb compiled by me can be downloaded from http://dev.miskiewicz.org/maemo/hild...2-19_armel.deb (it has the same version as CSSU stable repo version).
5. On device, I installed it with

Code:

dpkg -i /path/to/hildon-desktop-package.deb

6. Installed "CSSU Features Configuration", only to change value in "Rotation" sectio: "Applications": "Auto(default)" and "Forced". Installed (via fapt-get) meecolay-core and libqtm-12. Downloaded 3 tar.bz2 files from http://marmistrz.net63.net/meecolay/data/ and extracted them to /opt/meecolay. note some users were having problems with extracting because it doesn't work with stock tar, it needs busybox-power's tar to untar them directly (without bunzip2ing them first), so your script to download them automagically is only for busybox-power.
7. After each change via CSSU Features Configuration, a reboot was made.
8. I opened xterm and runned

Code:

meecolay /opt/meecolay/ceneo/opt/ceneo/bin/ceneo

(that's where I extracted ceneo deb downloaded via my-meego.com using dpkg -x). Then I copied /tmp/hildon-blacklist-log.txt to MyDocs, uploaded to my server and analized.

Results:

1. "Rotation", "Applications" : "Auto (default)"
The log file was never created, the Ceneo app was rotating, it was displayed wrong when in portrait. Is it ok that hd_comp_mgr_is_blacklisted function is never called with this config? My transitions.ini for this setup is here: http://dev.miskiewicz.org/maemo/transitions.ini.auto

2. "Rotation", "Applications" : "Forced"
Funny thing here. transitions.ini is here: http://dev.miskiewicz.org/maemo/transitions.ini.forced . The log is here: http://dev.miskiewicz.org/maemo/hild...cklist-log.txt
The app was still rotating to portrait and displaying improperly, but the "funny" (buggy?) part is this: although log clearly states

Code:

[hd_comp_mgr_is_blacklisted][hint] blacklist=mediaplayer osso-xterm ceneo worldclock image-viewer camera-ui Calendar

note that ceneo IS there, some lines say:

Code:

[hd_comp_mgr_is_blacklisted][result] wname=ceneo	blacklisted=1

while some lines say

Code:

[hd_comp_mgr_is_blacklisted][result] wname=ceneo	blacklisted=0

What the hell? May that be a bug in hildon-desktop? It is clearly check

Code:

[hd_comp_mgr_is_blacklisted][1st check - file is on blacklist] wname=ceneo	g_strrstr(blacklist, wname) && !(c->portait_supported || c->portait_requested)=1

that fails. Why exactly is the part "!(c->portait_supported || c->portait_requested)" in there and why can it fail sometimes? (it's rather obvious that g_strrstr("... ceneo ... ", "ceneo") is always true... unless there may be some strage conditions when blacklist variable has different value in this line and different value few lines later when it is written to log?) I would like to hear some feedback from someone who knows hildon-desktop better than me Can it be related to calling the function from different contexts? (e.g. once when app is fullscreen and once when app is in app dashboard? It shouldn't make a difference... just wild guess)

[b]My thoughts totally unrelated to hildon-desktop[/code]
About the faulty rotation in portait - may that be caused by double rotation? I mean:
1st rotation is hildon-desktop rotation made by window manager
2nd rotation is Qt/QML's internal rotation? How is rotation i Harmattan's apps implemented? Maybe when the app gets the singnal that device is in portret mode, it changes layout to portrait (inside this app)? So when we rotate a window and it rotates view inside - that would explain why app is rotated by 90 degrees and view is cropped when device is in portrait mode - what do you think marmistrz? (and others, too)

Please discuss

Originally Posted by marmistrz

Thanks for testing.
It's true that qml apps rotate themselves. The rotation mechanism seems to be officious and rotates them too. The double rotation is a problem with all the qml apps. (I tried it with wolframalpha). The main difference is that butaca or wolframalpha which use org.maemo.fremantle namespace are properly blacklisted and hildon-desktop has no problem. Apps using com.nokia.meego have good window name but there's some bug which makes all the blacklisting in vain. I think it's a hildon-desktop bug but this may be a problem with qt components -10. It should be reported.

About g_something: I need to learn a bit more abt glib.

About script I'll look at it later

Originally Posted by misiak

No problem. I stopped my tests after one app, because they all behave same way when rotating and this one's log is descriptive enough - sometimes blacklist chceck succeds for meecolay apps (or maybe generally for qml apps) and sometimes it fails, probably due to "!(c->portait_supported || c->portait_requested)" check returning false (so either c->portrait_suppored or c->portrait_requested is true, or both are).

Did you see the list of libraries which are different between Maemo 5 and MeeGo Harmattan (my very first link)? Is it useful?

Originally Posted by marmistrz

Strange thing in the check

Code:

!(c->portait_supported || c->portait_requested)=1

is the =1 part, so anyway this should be true (as assigned to 1)

Originally Posted by marmistrz

About site: this may be a clue about the missing libs, but I think the libs should be added when some app needs it. It may be that a possibly incompatible library works.

=========

I'm quoting one of my other posts, from other thread, about MeeCoLay development

http://talk.maemo.org/showpost.php?p...5&postcount=39

Do you have any idea about this?

Originally Posted by misiak

The output formatting could be better, this output says that

Code:

(g_strrstr(blacklist, wname) && !(c->portait_supported || c->portait_requested))==1

but apparently the second part of this check sometimes is true, sometimes is false, which makes whole result of blacklist check to be sometimes true and sometimes false... either c->portrait_supported or c->portrait_requested gets changed during program runtime, I will debug further to check how this happens.

Originally Posted by misiak

Is it libaegis-crypto or libaegis-crypto1? In Meego, you have both libcrypto (version 0.9.8) and libcrypto1 (I guess it may be the same library but it has version 1.0.0), see the site which compares Fremantle to Harmattan I linked earlier. If libaegis-crypto1 is linked against libcrypto1 (judging by the name I suppose it can be), you should first backport libcrypto1 and link it against it, not against Fremantle's libcrypto (0.9.8) - did you do that? (or is it not linked against libcrypto at all?)

Originally Posted by misiak

Edit 1: And, again about that site - it is created by a company which makes quite detailed comparisons. You can see that even when there is "compatible" result for a library, they sometimes put notes in further columns (when e.g. Harmattan version exports more functions, has warnings, etc.), so I think we may trust them when they say "compatible" or "incompatible".

Originally Posted by misiak

Edit 2: They even compared libc ! you can see there are 8 problems and 25 warnings in columns "Backward binary compatibility problems"! If we fix them, stock calendar app should work with newer libc

Originally Posted by marmistrz

So... It's true only when:

• app is blacklisted
• it doesn't support portrait and doesn't requreset portrait!!

I wonder how it works at all!

Originally Posted by marmistrz

it's libaegis-crypto1
I just fetched the newest source from gitorious (newer than in the sdk)... And it compiles!!! I'll check it soon.

Originally Posted by marmistrz

It may be very useful. Thanks for the page! I underestimated the page at first, to be honest.

This should be posted in the GCC 4.6 for fremantle thread. I'll do it.

Thanks for your help again. I'll upload the libaegis-crypto1 to extras-devel soon. Edit: if it works

Originally Posted by misiak

Newer sources of libaegis-crypto1 or libcrypto1?

Ok, I posted it in gcc 4.6 thread by myself I hope it will work... And we will be able to replace libc with newer version with some next CSSU update