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