Re: Building a package for armel only
On 07/12/2011 09:44 AM, gregor herrmann wrote: > Oh, and > https://garage.maemo.org/builder/fremantle/neverball_1.5.5-1/results/neverball_1.5.5-1.dsc > has "Architecture: any" (not "armel"), and a build dependency on > "libgles1-sgx-img-dev | libgl-dev" Specifying "armel" architecture for all packages did the trick, thanks! Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Building a package for armel only
Hi all, is there a way to tell the community autobuilder that my package should be built for Armel only? The i386 build fails, and I have no time (and interested) to make it work, also given the fact that the compilation takes ages. I tried adding "Architecture: armel" in the debian/control file, but that didn't seem to help: https://garage.maemo.org/builder/fremantle/neverball_1.5.5-1/ Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Bringing up the accounts UI using DBus
On 07/10/2011 02:30 AM, Jamie Thompson wrote:
> I'm trying to bring up the Accounts UI using DBus in a Qt application:
>> const char * NOKIA_SERVICE_ACCOUNTS_UI("com.nokia.AccountsUI");
>> const char * NOKIA_PATH_ACCOUNTS_UI("/com/nokia/AccountsUI");
>> const char * NOKIA_IFACE_ACCOUNTS_UI("com.nokia.Accounts");
>>
>> QDBusInterface nokiaAccountsUI(NOKIA_SERVICE_ACCOUNTS_UI,
>> NOKIA_PATH_ACCOUNTS_UI, NOKIA_IFACE_ACCOUNTS_UI);
[...]
> ...but it doesn't seem to work properly.
I'm not sure what the problem is, but maybe QDBusInterface isn't happy
with the result of the introspection.
Try not using QDbusInterface, and just send the method on QDBusConnection.
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QTBUG-18720
On 05/04/2011 11:12 AM, Benoît HERVIER wrote: I've pass many time to look which commit bring the error. But without success, this is why i post this email, maybe some talented dev of the community have time to look ? I'll also have a look. First, it would be interesting to see if the bug is also reproducible with Qt 4.7.2 on top on PR1.3. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt homescreen widgets not working with CSSU?
Hi Timur,
On 05/01/2011 11:14 PM, Timur Kristóf wrote:
> As it turns out, the raster graphics system is totally borked on it, and
> some stuff simply doesn't work on it well. This issue may be related to
> the already known bugs.
Your hint was extremely precious! Indeed, adding this just at the
beginning of main() does the trick:
if (qstrcmp(qVersion(), "4.7.2") == 0) {
QApplication::setGraphicsSystem("native");
syslog(LOG_DEBUG, "Using native graphicssystem");
}
Guess it's time for a new release. :-)
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt homescreen widgets not working with CSSU?
On 05/01/2011 11:14 PM, Timur Kristóf wrote: Hello Alberto, Thanks for your help! I had a look at sticky notes, but I see that you are not using the "standard" qmaemo5homescreenadaptor; why? Because it doesn't allow for some of the features that Sticky Notes has - for example having multiple instances of the same widget. It does; my widget uses it, and seems to work fine: http://blog.mardy.it/2011/05/oculo-dynamic-web-content-to-your-n900.html Anyway, I'm attaching a minimal version of the source code which exhibits the problem. You can see the text "Please configure the widget", but the background is not painted, and the only the top window border appears. I will look at it and see what I can figure out. Thanks! Note that the Community SSU packs a newer version of Qt, 4.7.2, which hasn't been officially tested on Maemo at all. As it turns out, the raster graphics system is totally borked on it, and some stuff simply doesn't work on it well. This issue may be related to the already known bugs. Ah, that might be the issue then! So, unless we find a workaround, I'll probably have to add a "Conflicts:" line to my package and not allow it to be installed when that version of Qt is installed. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt homescreen widgets not working with CSSU?
Hi Timur, On 05/01/2011 05:06 PM, Kristóf Timur wrote: > Hi Alberto, > > Sticky Notes (which is also Qt-based) still works with the CSSU. > If you give me a URL to your widgets' source, I may be able to figure > out what's wrong. Thanks for your help! I had a look at sticky notes, but I see that you are not using the "standard" qmaemo5homescreenadaptor; why? Anyway, I'm attaching a minimal version of the source code which exhibits the problem. You can see the text "Please configure the widget", but the background is not painted, and the only the top window border appears. I noticed that if I set the Qt::WA_PaintOnScreen attribute then the widget is fully visible, but it's not transparent and it visibly flickrs when it's painted. Please let me know if you have any ideas, I tried a bit of everything but I didn't get anywhere. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! testwidget.tar.gz Description: GNU Zip compressed data ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Qt homescreen widgets not working with CSSU?
On 05/01/2011 11:51 AM, Alberto Mardegan wrote: > I wonder if it could be related to some mis-handling of translucent > widgets; I sent a modified version to a user, which has translucency > disabled, and I'm waiting to hear the result. Got the result: with translucency disabled, the widget appears just as a black square. :-( Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt homescreen widgets not working with CSSU?
Hi all! Some users running CSSU reported that my homescreen widget (written in Qt) does not appear in their homescreen. I did a quick search on the forums, and found that the issue affects also some other widget: http://talk.maemo.org/showthread.php?p=998003 Does anyone have any ideas of what could be wrong? It seems that the widget loads and works properly, but it's simply invisible. I wonder if it could be related to some mis-handling of translucent widgets; I sent a modified version to a user, which has translucency disabled, and I'm waiting to hear the result. Suppose that the widget works with that change; how can I detect at run-time that the CSSU is installed and not enable the translucency then? If there is some (configuration) file added by the CSSU only, I could test for its existance. TIA, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: code review process for community SSU
On 02/07/2011 02:24 PM, Andrew Flegg wrote: For example, Gitorious is _supposed_ to allow effective code review: http://blog.gitorious.org/2009/11/06/awesome-code-review/ I added one section on "How to contribute" here: http://wiki.maemo.org/Community_SSU/Development It's just the first draft, I'm sure we can improve it a lot (and if anyone has time, please do so :-) ). I didn't mention any rules for maintainers (the "rule" that I'd like to add is "wait a few days before merging a merge request into master"): I'd first wait to see how this discussion evolves, and get some agreement about it. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: code review process for community SSU
On 02/07/2011 02:24 PM, Andrew Flegg wrote: Surely these are solved and/or solvable? Your preference may be for the ML, but I would suspect that's a personal preference. For example, Gitorious is _supposed_ to allow effective code review: http://blog.gitorious.org/2009/11/06/awesome-code-review/ I'd find it hard for you to find a problem with that which wouldn't affect an email! I don't find it that hard. :-) You cannot put inline comments when the diff is big (it's some problem in jQuery, it I understood correctly). But I actually don't mind if the community decides to settle on gitorious code reviews. We might miss some of the expertise we have in maemo-developers, but if it eases contributions, why not. What is important is to have code reviews *before merge requests are accepted*. I don't want to force a troublesome process, but for instance a recommendation of waiting a couple of days before pulling merge requests into the master branch would be pretty reasonable. People in maemo-developers. I'd be one, for sure. Besides, as I wrote before, there are several gurus there who have always been helpful and that happen to be the original writers of that software. Occasionally looking at a commit is different to committing (no pun intended) to review every change so that there's not a bottleneck. Sure, they are different things indeed. But both are better than nothing. Well, going back to 80s style code review on a mailing list is a big change in effort IMHO. However, as noted on the wiki, development processes are one of the many things to define. "Going back"? If you consider that at the moment we have nothing, I would rather call it "going forward". If then people find gitorious review system easier to work with, then let's go for it, and call it "going forward further". :-) Currently I think the second is primarily happening, with Mohammad acting as reviewer and maintainer for all the packages. Whether or not his standards correspond to yours is a different question as to whether or not code review is happening ;-) True. I'd just like to have code reviews as widely public as possible. I frankly didn't know about gitorious e-mail notifications [0], I just found this link by googling while replying to this e-mail. If it works fine then we could recommend it to every CSSU developer/reviewer. Ciao, Alberto [0]: http://gitorious.org/favorites -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: code review process for community SSU
Hi Andrew, 2011/2/6 Andrew Flegg : As to be expected, as this is a *testing* release to start defining processes and get more involved. Indeed. But I would stress that the more stable it is, the more people will get involved with that. The fact that I am a developer myself doesn't help me in trying the CSSU: if it screws things up, I'm as troubled as any other user. Therefore, if the N900 is my primary phone, I won't use the community SSU. I don't think it's critical at all. Certainly not compared with the community-ssu-enabler postinst bug before the announcement which required editing /var/lib/dpkg/community-ssu-enabler.postinst to do the upgrade. Sorry, I didn't weight my words correctly: I didn't mean to write "critical" in the sense of "makes the phone unusable", I just meant something affecting many users. But the point is that with the current situation, much more dangerous bugs can emerge. > This was my bad: the fix was in gitorious but not in the repo. However, I'd say this is the purpose of having a testing repo; and the clear warnings both at install time and on the Community_SSU page which say that currently it's only for those "willing to risk a reflash." That's fine as a disclaimer, but I insist that one thing is being honest and clear with your users, and another thing is having more community support on the CSSU. The first we have, more or less (the wiki page is not that clear about it being potentially dangerous software, though). Also the latter started well, I think, given the number of users who started using it, but I'm afraid many users will stop using it soon. > My own thought is that a comprehensive set of test scripts can cover the main bases before something gets pushed to the stable repo. These can be crowdsourced at both writing and testing: No, here I have to disagree completely -- I might be too pessimist, but I don't believe you'll ever be able to create a test suite which would make you feel even a little safer. Manual testing is the way to go (I'm talking of end user experience here), but to get testers you need either to pay them, or to give them a product with a reasonable quality. >> PROPOSAL: MAILING LIST FOR CODE REVIEW > > I don't think this is the best approach though. There are many problems to overcome: > > * It throws away the streamlined workflow supported >by gitorious.org and its "merge request" functionality. I've been using gitorious for years now, but I still don't like it. The review process is not better than a ML (because there's no easy way to navigate from one diff to see the full code), and I would claim that it's even worse because of missing notifications. > * Who would volunteer to review the code? Currently >we have a surfeit of people working on the code of >the CSSU, not a surplus. Given they're doing it in their >spare time, drudgerous formal code review is not going >to be high on their list. People in maemo-developers. I'd be one, for sure. Besides, as I wrote before, there are several gurus there who have always been helpful and that happen to be the original writers of that software. > * In my professional experience, monolithic code reviews >are rubbish at detecting bugs. One certainly wouldn't've >caught #11813. Now I'm sure I'll sound arrogant, but I bet that I would have caught it. :-) And if by "monolithic code review" you mean reviewing a big chunk of code, then my objection is that such a patch would have been discarded in the first place. > Having said that, doing something informally should be fine. Gitorious offers "watch" and (IIRC) RSS functionality. If you, or anyone else, wanted to watch the commits and provide comments on maemo-developers, I think that'd be very useful. That would be a pain. It's true that it could help in spotting some bugs, but reviewing code "a posteriori" (after it has been merged into the master branch) it's demotivating for everyone. At least it won't help code quality: if I ask "please split this function into two", when the function is perfectly functional as it is, who would do that? And why would I bother doing that, given the the repository history has already recorded that? > I thought the wiki pages did. However, it's a wiki, feel free to iteratively improve it! I will :-) BTW, I don't mean to underestimate you, Mohammad or any other contributor -- I'm complaining about the development process. I have some experience with leading the development of a project, and I see how this CSSU could be very easily improved with very little effort. When we were developing for the N900 within Nokia, we had to make compromises, reduce the scope of some features and cancel others, just for the sake of delivering it in time and minimizing risks of missing deadlines. Now we have the unique opportunity of developing software with an infinite amount of time and a fair amount of good developers. We should aim at raising the quality of the original
Proposal: code review process for community SSU
(note: follow-up set to maemo-developers ML) Hi all! I think we all agree that we should try our best to deliver good software updates and avoid at all costs breaking any existing features. CURRENT SITUATION = Shortly after releasing the first community SSU, we already got a few bugs: https://bugs.maemo.org/buglist.cgi?query_format=advanced&product=Maemo%205%20Community%20SSU&classification=Extras Of these, https://bugs.maemo.org/show_bug.cgi?id=11813 was rather critical, as we can see from the amount of duplicate bugs it got. One one hand, it's excellent that the bug was fixed so promptly; but on the other hand, I think we should realize that the risk of completely breaking or ruining the user experience with a non well tested SSU update is real. I ran "git log -p" on the hildon-desktop repository (in the Community SSU project) and looked at the patches. It's scary. Commit 04725f6e6b261654d90fadeb2a2fc258a2ee3d28 consists of "26 files changed, 848 insertions(+), 17 deletions(-)" and commit 0fea52b0b7ce2c27054e08e3fa2160106c8eeea2, which is titled "modify changelog" is adding one new source file (?). No matter how good the developers are, I don't feel at all confident about having the development of core components happening in IRC, possibly with just 2 or 4 eyes reviewing the code. POSSIBLE SOLUTIONS, BRIEF = So, either we stop advertising the SSU repository, and on the contrary make it even harder to enable than extra-devel (because potentially it is *much more dangerous* than that!), or we think of some measures to minimize the risks of breakage. I would vote for the second: having more people using the work-in-progress community SSU is not only beneficial for testing, but for its development too, because more people get their hands itchy with the desire of improving it. :-) PROPOSAL: MAILING LIST FOR CODE REVIEW == Something like the LKML (Linux Kernel Mailing List): all patches are sent to the mailing-list before being merged into the master branch, and all subscribed people can comment, vote against the inclusion, or require some changes. We could introduce some rules about the number of people who need to approve a patch before it goes in, or assign components to maintainers, but I'd suggest to keep things simple and avoid creating processes until we really need to. We could use the already existing maemo-commits or maemo-developers mailing list. I would opt for the latter, because I don't expect a huge traffic of patches; besides, the maemo-developers list is read by a few of the Nokia employees who originally wrote that code, so this could be of a huge help. CONCLUSION == Please comment on the proposal. At the very least, we should immediately take the action of making the community SSU harder to enable and clearly state in the wiki pages that it's very high risk software. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Allowing rotation of closed-source apps
On 02/06/2011 02:53 PM, Thomas Perl wrote: Hi Alberto, 2011/2/6 Alberto Mardegan: What do you think about all this? I didn't check hildon-desktop and mb2 source code yet, so if you also happen to have some hints on the implementation, they are very welcome. :-) Sounds good. Hildon-Desktop already sets the auto-rotation flag on a window if Ctrl+Shift+R is pressed. There is a central place in H-D where these keyboard shortcuts are handled. Going from there, you can see how the setting of a flag is done (for the current window). It shouldn't be too hard to add support for doing this by window title or window class. Oh, I didn't know about that! Then some of the hard work is already done. Thanks for the tip! :-) Then what is left to do is to find a way to serialize the window description, store it somewhere and then read it back when a window is shown. About describing the windows, I had a quick look at libmatchbox2, and it looks like the MBWMClientWindow has a few interesting fields: - pid_t: we could look up the process name. - name: I suppose this is the window title - hildon_stacking_layer: I don't think that this is constant, but we might be able to use it somehow So, [/[/]] might be used as a key to match windows in the configuration file. (all this is supposing that the fields above work as I expect :-) ) I wonder what would happen if we would simply try to patch H-D to auto-rotate every window and then "blacklist" the closed-source apps that don't work? Mmm... Then we would mess up the existing open-source applications which have a fixed orientation, forcing their authors to add their applications to the blacklist. Hildon rotation window flags would lose their meaning, if your application is not blacklisted. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Allowing rotation of closed-source apps
Hi all! Since it looks like we are going to have a virtual keyboard which supports portrait mode [0], it would be nice if we were able to rotate closed-source applications too (such as the Conversations app). I think that this should be possible to achieve by modifying hildon-desktop so that it can override the window rotation flags of certain windows. To make this work, we would need to uniquely identify the windows created by clients (I'm not sure how, but I think it's possible), and then look up a few settings from GConf (or a GSettings file) which would override the rotation settings specified by the application. So, for instance, we could have settings like this for the Conversation application: HD/override/rtcom-messaging-ui/orientation = auto And for those windows which are unusable in portrait mode ( is some way to identify a window inside an application): HD/override/rtcom-messaging-ui//orientation = landscape Then we would either need a settings tool to configure this, or some keyboard shortcuts to be pressed when the selected window is in the foreground. What do you think about all this? I didn't check hildon-desktop and mb2 source code yet, so if you also happen to have some hints on the implementation, they are very welcome. :-) Ciao, Alberto [0]: http://talk.maemo.org/showthread.php?t=68924 -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QtQuick not present in PR1.3
On 11/12/2010 05:41 PM, Robin Burchell wrote: import QtQuick 1.0 I'm no QML expert, but where did you get the idea to do this? AFAIK it's currently 'import Qt 4.7' I got it from here: http://doc.qt.nokia.com/4.7/qml-tutorial1.html Only now I notice that the page title mentions "4.7.1". :-/ Anyway, thanks a lot guys! :-) Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QtQuick not present in PR1.3
Hi all,
did anyone try to run QtQuick applications in PR1.3?
I wrote sample.qml with these contents:
=
import QtQuick 1.0
Rectangle {
id: page
width: 500; height: 200
color: "lightgray"
Text {
id: helloText
text: "Hello world!"
y: 30
anchors.horizontalCenter: page.horizontalCenter
font.pointSize: 24; font.bold: true
}
}
=
But then when I try to run it:
=
Nokia-N900:~$ qmlviewer sample.qml
file:///home/user/sample.qml:1:1: module "QtQuick" is not installed
import QtQuick 1.0
^
=
Am I missing some packages? I think I've installed all Qt packages.
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
On 10/29/2010 12:14 PM, Eero Tamminen wrote: Hi, (I resurrected this old thread because there was on meego-dev mailing list a comment about possibility for RunFast float mode being enabled by default on MeeGo...) ext Alberto Mardegan wrote: Eero Tamminen wrote: Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Wed, 2010-03-10 at 12:57 +0100, ext Alberto Mardegan wrote: Not the libosso osso_fpu_set_mode() function? I can't find this in libosso.h. :-( It's defined in osso-fpu.h (since summer 2009): http://maemo.gitorious.org/fremantle-hildon-desktop/libosso/blobs/master/src/osso-fpu.h If somebody's using a lot of floats (RunFast mode affects only floats) and they're a bottleneck, it would be interesting to know how much this (setting the RunFast mode at program start) helps. The discussion continued in the same thread: http://lists.maemo.org/pipermail/maemo-developers/2010-March/025203.html and http://lists.maemo.org/pipermail/maemo-developers/2010-March/025218.html Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Horrible performance of GL rendering; why? (Qt, N900)
Hämäläinen Kimmo wrote: I'm experiencing a horrible performance of the QGraphics "accelerated" rendering when using the attached test program. [...] If you can see hildon-desktop taking more than 7% of CPU, try using a fullscreen window so it's not composited. (You may need to provide a Switcher and close button yourself...) I don't think it's the compositor's fault. I found this yesterday: http://bugreports.qt.nokia.com/browse/QTBUG-10420 It seems that Qt 4.6 is not using OpenGL ES operations for drawing textures, so this might be the reason. I'll try with 4.7 from extras devel, and let you know. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Horrible performance of GL rendering; why? (Qt, N900)
Hi!
I'm experiencing a horrible performance of the QGraphics
"accelerated" rendering when using the attached test program.
The program uses QGLWidget as a viewport when any command line parameter
is passed, and normal Qt rendering (software only?) otherwise.
When I run the application in my N900, it seems that the software
rendering is much smoother than the GL one.
Am I doing something wrong? I would expect much better performances,
with such a simple test application.
Any help is much appreciated (I'm trying to port Mappero to Qt :-) ).
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
/*
* Compile with:
g++ -DQT_SHARED -I/usr/include/QtMaemo5 -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include/QtOpenGL -g -O2 -o testgl -lQtMaemo5 -lQtOpenGL -lQtGui -lQtCore testgl.cpp
*/
#include
#include
#include
#include
#include
#include
class MyGraphicsScene: public QGraphicsScene
{
void timerEvent(QTimerEvent *event)
{
static qreal angle = 0;
foreach (QGraphicsItem *item, items()) {
item->setRotation(angle);
}
angle += 1;
}
};
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
MyGraphicsScene scene;
for (int i = 0; i < 3; i++)
for (int j = 0; j < 3; j++) {
QPixmap pixmap = QPixmap(256, 256);
pixmap.fill(QColor(i * 80, j * 80, 0));
QGraphicsItem *item = scene.addPixmap(pixmap);
item->setPos(i * 256, j * 256);
}
QGraphicsView view(&scene );
view.setAttribute(Qt::WA_Maemo5AutoOrientation, true);
view.setAttribute(Qt::WA_Maemo5NonComposited, true);
view.setRenderHints(QPainter::Antialiasing);
if (argc > 1)
view.setViewport(new QGLWidget);
view.show();
scene.startTimer(10);
return app.exec();
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: call_fi_call_type_cellular value in Qt?
Felipe Crochik wrote: Now the second part of the problem: what is the "catalog"? I am getting this string from the profile files at "/usr/share/osso-rtcom/" and the strings should be the "telepathy account names" (Cellular, Skype, Facebook, ... )... Some of them are the actual names (e.g. "Facebook") and some of them are entries to what I imagine is the "localized" version of the string (e.g. "call_fi_call_type_cellular"). All the translations catalogues are in /usr/share/locale/en_GB/LC_MESSAGES/ You can grep for the desired string in the directory, and see where it is defined. For call_fi_call_type_cellular, it's "rtcom-call-ui". Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: call_fi_call_type_cellular value in Qt?
On 08/04/2010 10:51 PM, Felipe Crochik wrote: What is the best way to get the localized version of, for example, “call_fi_call_type_cellular” in qt? gettext is a C function which comes with GNU libc, so it's available for Qt applications too. You'll need to use dgettext() and specify the catalog file where that string is located, too. Note the result is an UTF-8 string, so you'll have to pass it to QString::fromUtf8(). Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to add a telepathy account during package installation (and remove on package removal)?
Sudheer K wrote: However I am not sure how to add the line "SecondaryVCardFields=TEL" in the account details using mc-tool. I tried mc-tool update but it didn't work (mc-tool update: Not all parameters were recognized). This is not a connection manager parameter but it is required to set this value to support calls from addressbook. Any suggestions? I'm afraid you cannot set it with mc-tool. You could checkout the source code of mc-tool ( http://git.collabora.co.uk/?p=telepathy-mission-control.git;a=tree;f=util ) and build another utility that does set that too. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to add a telepathy account during package installation (and remove on package removal)?
Hi Sudheer, On 08/01/2010 08:07 PM, Sudheer K wrote: I need to add account details in /home/user/.rtcom-accounts/accounts.cfg for my custom connection manager automatically on package installation. Similar to ring account details, I want to avoid UI (like Haze plugin) because these values are pre-defined and user does not have to add/update anything. So my question is how can I add a new account section in accounts.cfg through code? I also should be able to remove it through code. You need to use the org.freedesktop.Telepathy.AccountManager interface to create a new account. The mc-tool command-line tool can also be used to create/edit/delete accounts from a script. It's in the libmissioncontrol-utils package, which is not installed by default. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mission Control: Any Dbus interface method to list all the available ChannelRequest objects?
On 07/28/2010 09:19 AM, Sudheer K wrote: Is there any way to list the object paths of all the channel requests in progress? With a dbus method call may be? IIRC, there isn't. Another related question. Is the specification for "com.nokia.Account.Interface.ChannelRequests" available anywhere or is it closed? It's open: http://git.collabora.co.uk/?p=telepathy-mission-control.git;a=blob;f=xml/Account_Interface_ChannelRequests.xml Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: MC-Client error "No Requests Interface", when Conn.I.Requests is implemented
Sudheer K wrote: Hi, I am working on a connection manager for N900 using Telepathy-Qt4 bindings. This is for tel protocol (based on telepathy-ring). The Connection manager is registered as service on session bus and the connection is available. When I try to initiate a new call (channel), I get the error "No Requests Interface" in the Dbus log. But my connection object did implement org.freedesktop.Telepathy.Connection.Interface.Requests interface. I verified this by running introspect command on Connection object and it includes requests interface. I have attached the dbus monitor log [1] and introspect output [2]. What am I doing wrong here? Do I need to implement any other interfaces for Maemo? Let me know if you need me to post the code. [1] - Dbus Monitor Log - http://pastebin.com/VTgKWqdP [2] - Introspect Command Ouput - http://pastebin.com/cKGzGgrw Implementing the interface is not enough; you also need to declare your interface in the org.freedesktop.Telepathy.Connection.Interfaces property: http://telepathy.freedesktop.org/spec/Connection.html#org.freedesktop.Telepathy.Connection.Interfaces Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
Kimmo Hämäläinen wrote: On Mon, 2010-06-14 at 08:18 +0200, ext Alberto Mardegan wrote: ... I'm not sure about virtual memory, but about CPU mappero will never use more than 30-35% -- it simply isn't allowed by the OS (startup times could be much faster if it were...). wooot? :) Who is using the rest 70% of the CPU then? Are you sure it's not just sleeping or waiting for GPU/network/IO? Because it's easy to make a two-line program that uses all your free CPU... I thought that c-groups didn't allow it? Well, I just checked with top and it seems I can never go beyond 40% when Mappero is starting up -- but that might be I/O indeed. Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
kate.alh...@nokia.com wrote: Situation is when lot of map tiles are loaded. "loaded" as in "downloaded"? About the number of tiles loaded into memory, mappero uses a tile cache, which is actually quite big (140 tiles, and tiles are textures sized 256x256 pixels) so it may consume quite a bit of memory. But in my case, according to "top" the RSS is about 21MB, which doesn't seem so scary. I dont't know what internaly happens. Some memory leak ? For application performance and cpu usage also time needed for tile pre-processing need to be counted. I doubt there are any substantial memory leaks, I've been using mappero for several hours without breaks, and didn't notice any worsening. Does it some scaling for tiles after loading them ? No, it does only if the tile of the needed size is missing. But that's something you can notice quite easily, because it's quite evident when the pixels are being doubled. Finally time used for scaling tiles is one key issues. Do we scale them or download every size. How much cpu power is used for scaling or do we leave it all for GPU ? Every size is downloaded. Scaling happens rarely, and it is done on the CPU; but after scaling the texture is stored into the GPU and reused, so the performance hit is minimal. For mappero case i don't know how much cpu is used for actual scaling and how much by exhausting virtual memory ? I'm not sure about virtual memory, but about CPU mappero will never use more than 30-35% -- it simply isn't allowed by the OS (startup times could be much faster if it were...). Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QT map widget
kate.alh...@nokia.com wrote: I don't know hat mappero (ex maemo mapper) does internaly but least, it can eat all cpu power when doing "processing maps" so that only way out is remove battery from device. I've been told that this happens when downloading large amounts of map tiles, so it has nothing to do with the map widget itself. That one is based on clutter, and seems to be quite efficient. (off topic: if you can find some way to reproduce it reliably, please file a bug -- although if you really need to take out the battery, that cannot be a bug in the application itself) Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: git over ssh access for garage projects - calling for brave testers
Alberto Mardegan wrote: Ferenc Szekely wrote: If you had a few minutes to spare please check it out and let me know your findings. We may have some bugs here and there, so let's find and fix them together. I get this: ma...@portatie:/tmp$ git clone ssh://drop.maemo.org/git/maemo-mapper Initialized empty Git repository in /tmp/maemo-mapper/.git/ fatal: ''/git/maemo-mapper'': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly Hi Ferenc, any news on this? I already had my SSH keys (and I can upload to extras, so I guess they are correct), but I still get the error above. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: git over ssh access for garage projects - calling for brave testers
Ferenc Szekely wrote: If you had a few minutes to spare please check it out and let me know your findings. We may have some bugs here and there, so let's find and fix them together. I get this: ma...@portatie:/tmp$ git clone ssh://drop.maemo.org/git/maemo-mapper Initialized empty Git repository in /tmp/maemo-mapper/.git/ fatal: ''/git/maemo-mapper'': unable to chdir or not a git archive fatal: The remote end hung up unexpectedly Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
Thomas Perl wrote: 2010/4/15 Aniello Del Sorbo : I am now using HeAboutDialog as well... only issue is that it doesn't properly render in portrait mode :) Patches are welcome :p No patches should be necessary since PR1.2: http://maemo.gitorious.org/hildon/gtk/blobs/master/gtk/gtkdialog.c#line680 Ciao, Alberto -- http://blog.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: oprofile on ARM
Felipe Contreras wrote: On Sun, Apr 11, 2010 at 10:46 AM, Alberto Mardegan wrote: == --- 336 4.2852 libpng12.so.0.37.0 png_do_expand_palette 336 100.000 libpng12.so.0.37.0 png_do_expand_palette [self] --- == It seems it cannot resolve the caller, why? Did you try to reinitialize OProfile? No, I didn't know that I had to do that. I got the instructions here: http://wiki.maemo.org/Documentation/devtools/maemo5/oprofile I just added some basic information for this here: http://elinux.org/OProfile Thanks! I'll try that, and if it works I'll add it to the wiki page in maemo.org :-) Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
"Size mismatch" on the extras-devel repository
It seems there is something wrong with the extras-devel repository (at least for the armel architecture): [sbox-FREMANTLE_ARMEL: ~/git/maemo-mapper/src] > apt-get install libclutter-1.0-0 Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: libclutter-1.0-dbg libclutter-1.0-dev The following packages will be upgraded: libclutter-1.0-0 libclutter-1.0-dbg libclutter-1.0-dev 3 upgraded, 0 newly installed, 0 to remove and 300 not upgraded. Need to get 413kB of archives. After unpacking 123kB disk space will be freed. Do you want to continue [Y/n]? WARNING: The following packages cannot be authenticated! libclutter-1.0-dbg libclutter-1.0-dev libclutter-1.0-0 Install these packages without verification [y/N]? y Get:1 http://repository.maemo.org fremantle/free libclutter-1.0-dbg 1.0.8-0maemo1 [57.8kB] Get:2 http://repository.maemo.org fremantle/free libclutter-1.0-dev 1.0.8-0maemo1 [105kB] Get:3 http://repository.maemo.org fremantle/free libclutter-1.0-0 1.0.8-0maemo1 [250kB] Fetched 450kB in 1s (301kB/s) Failed to fetch http://repository.maemo.org/extras-devel/pool/fremantle/free/c/clutter/libclutter-1.0-0_1.0.8-0maemo1_armel.deb Size mismatch E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
oprofile on ARM
Hi all, again I've tried to profile Mapper on the N900, with no results. First I tried gprof, but it gives me all 0.0 times (and a google search reveals that this is a common problem in maemo, even though I didn't find an explanation of it); then I tried oprofile, which gives me an output like this: == samples %image name symbol name 3007 38.3497 no-vmlinux /no-vmlinux 1083 13.8120 libclutter-eglx-1.0.so.0.8.0 /usr/lib/libclutter-eglx-1.0.so.0.8.0 424 5.4075 libc-2.5.so memcpy 336 4.2852 libpng12.so.0.37.0 png_do_expand_palette 317 4.0429 libz.so.1.2.3/usr/lib/libz.so.1.2.3 286 3.6475 libGLESv2.so /usr/lib/libGLESv2.so 219 2.7930 ld-2.5.sodo_lookup_x 120 1.5304 libglslcompiler.so /usr/lib/libglslcompiler.so 550.7014 libc-2.5.so _int_malloc 480.6122 libpthread-2.5.sopthread_mutex_lock 440.5612 libpixman-1.so.0.15.3fbCompositeSolidMask_nx8xneon 360.4591 libsrv_um.so /usr/lib/libsrv_um.so 350.4464 libc-2.5.so malloc 350.4464 libsqlite3.so.0.8.6 /usr/lib/libsqlite3.so.0.8.6 340.4336 libc-2.5.so memset 340.4336 libglib-2.0.so.0.2000.3 g_slice_alloc 320.4081 libglib-2.0.so.0.2000.3 g_hash_table_lookup [...] == (I got this output after moving the oprofile collected data into Scratchbox) But this doesn't help me, as Mapper's own functions appear on the bottom of the list and seem to take very little time. I tried to use the "-c" option of opreport to see the call graph, but it doesn't seem to be working properly, as for every function it gives this output: == --- 336 4.2852 libpng12.so.0.37.0 png_do_expand_palette 336 100.000 libpng12.so.0.37.0 png_do_expand_palette [self] --- == It seems it cannot resolve the caller, why? One more question: how can I see the total time taken by a function? I would expect to see the main() function of Mapper at the top of the list, as it's clearly the function that takes most time, but it doesn't even appear in the list at all. So I assume that these times are net (that is, the time spend in subroutines is excluded from the function times), which might be useful in some case, but it definitely prevents me from knowing what functions in Mapper need to be optimized... Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: R: Efficient storage and playback of speech
Hi, Floriano Scioscia wrote: I would suggest AAC: - it is free from license/patent encumberings - Maemo 5 (and also Diablo iirc) have built-in codecs using the DSP for better performance and less energy consumption - it is more efficient than MP3 thanks for your suggestion! It seems that the compression is really good. Any hints on how to play these files? libcanberra supports only WAV, AFAIK. :-( Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Application manager and language packages
Hi all, as soon as voice navigation will be ready in Mapper, I'll need to provide language packages for the speech files. Is it possible to have them grouped under Mapper in the application manager? I don't think there'll be that many of them -- but who knows! ;-) -- and since I hate when people are cluttering the Application Manager with tens of translation or data packages, I wouldn't like to do the same myself... Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Efficient storage and playback of speech
Hi all, I need to install on the device a few (I guess around 10-20) audio files with some seconds of speech each (it's for GPS navigation). What file format do you suggest to use, considering that one requirement is that the audio is played almost immediately (the lag should be under 1 second) when I request it to? The 22Khz 16bit WAV from the sound recorder sound good, but they are a bit "heavy", taking more than 100Kb for 3 seconds of speech. I'm a bit concerned because I'll eventually ship translations for these audio files in different languages, so they might end up taking quite some space. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [fremantle] HTML rendering inside applications
daniel wilms wrote: There is a qt application, which does that. Check out the code: http://qt.gitorious.org/qt-labs/graphics-dojo/trees/master/websnap Thanks! I already found other applications, and the code is almost the same. It's a bit surprising to see how easy it is done with Qt! :-) Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Disabling WM animations
Hi, is there some way to completely disable window animations? It's just for debugging, to make sure that they are the (indirect) cause of device freezes when using Mapper. Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[fremantle] HTML rendering inside applications
Hi, suppose that I have some HTML (in a file or in memory) and I want my application to display it as a static bitmap. How can this be done? Is there some browser API that I can call, and which would return me an image of the page. Ideally, the input data should be the HTML, a desired width (in pixels), a zoom level (or character size); the output would be a bitmap, either in memory or as a file path. Any suggestions? TIA, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Icons are just a few bytes, right ?
Attila Csipa wrote: Okay, big, but there are 3000+ user packages. But, how about we strip the... icons ? A quick and dirty grep -v gives a rough: [...] That would help, +1! One more observation -- even though I have no concrete proposals on how to solve this: usually even developers don't need but a very few packages from extras-devel, yet the whole list is downloaded. It would be nice to have a server-side logic, that generates the Packages file dynamically: the client gives a package name (and optionally a version), and the web engine generates the Packages file which enables downloading of this file, it's Depends:, Recommends:, Suggests:, and nothing else. I don't know much about APT, maybe something of this kind exists already? Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Siarhei Siamashka wrote: The output (application compiled with -O0): Using an optimized build (-O2 or -O3) may sometimes change the overall picture quite dramatically. It makes almost no sense benchmarking -O0 code, because in this case all the local variables are kept in memory and are read/written before/after each operation. It's substantially different from normal code. Right. Just to complete the picture, here's the same data with -O2: float (fast mode enabled): map_path_calculate_distances: 40 ms for 8250 points map_path_calculate_distances: 2 ms for 430 points double (fast mode enabled): map_path_calculate_distances: 93 ms for 8250 points map_path_calculate_distances: 4 ms for 430 points (I'm not posting the same data with fast mode disabled, as it cannot be worse than the -O0 case, which is anyway not too far from these values) The relative preformance seems to be about the same. But then of course, it might not be because of the FPU, but of the data transfers. Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900: Mapper, device deadlocks and clutter/GL errors
Eero Tamminen wrote: - Always: when I'm drawing on a texture (either loading a map tile, or using cairo on a texture) and a Hildon banner/notification appears (either from Mapper itself, or even an incoming chat notification), the texture is corrupted, and it will contain a small rectangle with pseudorandom pixels. And the graphics being drawn when the SGX HW reset happened can be corrupted (as the operation was interrupted and state before the reset isn't recoverable). This is a bit different: in these cases I rarely see any lines from SGX in the syslog. From there, everything appears fine, but the textures are corrupted. Note that on most(?) devices it doesn't seem to happen at all, at least with the pre-installed software. But e.g. the 3rd party Maep application seems to make triggering of this issue (at least on some devices) easier, especially as/when it's doing window updates even when it's not visible (which is a clear use-time and resource usage bug in Maep). In my case, I'm sure I've seen it when I was actively using the device. But now that I think of it, in all cases when I saw it I had a dialog on top of the clutter stage: the "download route" dialog, which also causes some network traffic to retrieve the route and then some CPU activity to parse it into a path and draw it on the stage, via the cairo functions. It is quite possible that drawing happened while the clutter stage was covered by a dialog. Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
N900: Mapper, device deadlocks and clutter/GL errors
Hi all, I've some issue with Maemo Mapper which I cannot solve by myself and are unfortunately quite severe: - Sometimes, a "HWRecoveryResetSGX: SGX Hardware Recovery triggered" line appears on the syslog. Most of the times, without any visible effects. - Rarely, the device freezes for several seconds. It seems to me that this is solved by pressing the power key and waiting a few seconds -- but it might be just a coincidence. - Always: when I'm drawing on a texture (either loading a map tile, or using cairo on a texture) and a Hildon banner/notification appears (either from Mapper itself, or even an incoming chat notification), the texture is corrupted, and it will contain a small rectangle with pseudorandom pixels. I'm using clutter 1.0, from extras-devel. When running the application in Scratchbox i486 with valgrind, it is damn slow but I don't see any errors reported while rendering the tiles. Can you help me to debug this? I suspect it is all due to some bugs in clutter (or maybe in the SGX driver), but I have no idea where to start from. TIA, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Alberto Mardegan wrote: Does one have any figure about how the performance of the FPU is, compared to integer operations? I added some profiling to the code, and I measured the time spent by a function which is operating on an array of points (whose coordinates are integers) and trasforming each of them into a geographic coordinates (latitude and longitude, floating point) and calculating the distance from the previous point. http://vcs.maemo.org/git?p=maemo-mapper;a=shortlog;h=refs/heads/gps_control map_path_calculate_distances() is in path.c, calculate_distance() is in utils.c, unit2latlon() is a pointer to unit2latlon_google() in tile_source.c The output (application compiled with -O0): double: map_path_calculate_distances: 110 ms for 8250 points map_path_calculate_distances: 5 ms for 430 points map_path_calculate_distances: 109 ms for 8250 points map_path_calculate_distances: 5 ms for 430 points float: map_path_calculate_distances: 60 ms for 8250 points map_path_calculate_distances: 3 ms for 430 points map_path_calculate_distances: 60 ms for 8250 points map_path_calculate_distances: 3 ms for 430 points float with fast FPU mode: map_path_calculate_distances: 50 ms for 8250 points map_path_calculate_distances: 2 ms for 430 points map_path_calculate_distances: 50 ms for 8250 points map_path_calculate_distances: 2 ms for 430 points So, it seems that there's a huge improvements when switching from doubles to floats; although I wonder if it's because of the FPU or just because the amount of data passed around is smaller. On the other hand, the improvements obtained by enabling the fast FPU mode is rather small -- but that might be due to the fact that the FPU operations are not a major player in this piece of code. One curious thing is that while making these changes, I forgot to change the math functions to there float version, so that instead of using: float x, y; x = sinf(y); I was using: float x, y; x = sin(y); The timings obtained this way are surprisingly (at least to me) bad: map_path_calculate_distances: 552 ms for 8250 points map_path_calculate_distances: 92 ms for 430 points map_path_calculate_distances: 552 ms for 8250 points map_path_calculate_distances: 91 ms for 430 points Much worse than the double version. The only reason I can think of, is the conversion from float to double and vice versa, but is it really that expensive? Anyway, I'll stick to using 32bit floats. :-) -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Eero Tamminen wrote: Is there any performance penalty if this switch is done often? Why you would switch it off? Operations on "fast floats" aren't IEEE compatible, but as far as I've understood, they should differ only for numbers that are very close to zero, close enough that repeating your algorithm few more times would produce divide by zero even with IEEE semantics (i.e. if "fast float" causes you issues, it's indicating that there's most likely some issue in your algorithm). Ok, I thought the precision loss would be more noticeable, but as we are talking about latitude and longitude (and anyway the GPS accuracy is not so great), I guess I don't have any need to turn it off. Anyway, I'm doing some benchmarks, I'll post the results soon. -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Eero Tamminen wrote: Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Wed, 2010-03-10 at 12:57 +0100, ext Alberto Mardegan wrote: Kimmo Hämäläinen wrote: You can also put the CPU to a "fast floats" mode, see hd_fpu_set_mode() in http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/main.c Not the libosso osso_fpu_set_mode() function? I can't find this in libosso.h. :-( I'll copy Kimmo's code. -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Performance of floating point instructions
Kimmo Hämäläinen wrote: You can also put the CPU to a "fast floats" mode, see hd_fpu_set_mode() in http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/blobs/master/src/main.c N900 has support for NEON instructions also. This sounds interesting! Is there any performance penalty if this switch is done often? Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Performance of floating point instructions
Hi all, in maemo-mapper I have a lot of code involved in doing transformations from latitude/longitude to Mercator coordinates (used in google maps, for example), calculation of distances, etc. I'm trying to use integer arithmetics as much as possible, but sometimes it's a bit impractical, and I wonder if it's really worth the trouble. Does one have any figure about how the performance of the FPU is, compared to integer operations? A practical question: should I use this way of computing the square root: http://en.wikipedia.org/wiki/Methods_of_computing_square_roots#Binary_numeral_system_.28base_2.29 (but operating on 32 or even 64 bits), or would I be better using sqrtf() or sqrt()? Does anyone know any tricks to optimize certain operations on arrays of data? Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras-testing improvements
Attila Csipa wrote: want better quality software, developers, testers, users, everybody. Let's make Extras-testing a place where we help applications get to Extras by improving them, not just kick them back to extras-devel, screaming. Thank you. I agree with Graham: I'd like the quarantine process to be only about critical problems, such as app not being optified, making the device unstable or not meeting some basic formal criteria (such as bugtracker link). I'm porting maemo-mapper to the N900; it is an application with a billion of features, and some of them are not working correctly, and the UI for certain operations is still unusable on the N900. Still, the application works fine and is perfectly usable for basic usage and it seems not to be harmful for the device. So, I wouldn't like it to be blocked from Extras just because some feature don't work (for instance, one commenter wrote on the testing page that he considers the absence of VirtualEarth maps to be a blocker, so he didn't vote for it, despite liking it). If applications are ugly or not completely working (but still not harmful), I'd like them to have a bad rating, of course, but still be available on Extras. Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Going crazy with HildonPickerButton with multiple selection
Alberto Garcia wrote: On Thu, Feb 18, 2010 at 10:33:46PM +0200, Alberto Mardegan wrote: HildonPickerButton with multiple selection seems to be perfect for my need, but unfortunately HildonPickerDialog doesn't allow closing the dialog if no item is selected (why???). I know it's controversial, but that was a design decision for Maemo 5. The solution is to have an option labelled "None". For an example, open the clock app, try adding a new alarm and see the "Repeat" button (which allows multiple selection). The first option is "Never" I see. I could actually implement it in the same way as the clock app is doing. BTW, I find the APIs for handling selections rather cumbersome, I have to write about 20 lines of code just to know the selection state of an item (if multiple selection is enabled). If I write a patch that adds gboolean hildon_touch_selector_is_selected(HildonTouchSelector *selector, gint column, gint index); void hildon_touch_selector_set_selected(HildonTouchSelector *selector, gint column, gint index, gboolean selected); would that have any chance of making its way in a future release? Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Going crazy with HildonPickerButton with multiple selection
Hi all,
I've been getting exasperated with HildonPickerButton: I have a
simple list of strings, and I want the user to select zero or more of them.
HildonPickerButton with multiple selection seems to be perfect for my
need, but unfortunately HildonPickerDialog doesn't allow closing the
dialog if no item is selected (why???).
The only workaround I could come up with, is connecting to the "changed"
signal of the HildonTouchSelector and in the handler run this code. I'm
pasting this here in case it turns out to be useful for someone else:
=
static void
hack_sel(GtkWidget *selector, gint column, gboolean *hacked)
{
GtkWidget *dialog;
guint id, ret;
if (*hacked) return;
/* HILDON HACK: HildonPickerDialog blocks the emission of the
* "response" signal if no item is selected. Since this blocking
* happens on a signal handler for the "response" signal itself,
* we disconnect it :-) */
dialog = gtk_widget_get_toplevel(selector);
id = g_signal_lookup("response", GTK_TYPE_DIALOG);
ret = g_signal_handlers_disconnect_matched(dialog,
G_SIGNAL_MATCH_ID | G_SIGNAL_MATCH_DATA, id, 0,
NULL, NULL, NULL);
if (ret != 1)
g_warning("%s: disconnected %u signals!", G_STRFUNC, ret);
*hacked = TRUE;
}
If someone has some better suggestion, you are most welcome to post it. :-)
Ciao,
Alberto
--
http://www.mardy.it <- geek in un lingua international!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: "Donate $x" button on Packages and/or Downloads
Andrew Flegg wrote: Do you know of any global-micropayment systems which have a simple API? I don't know about the API, but maybe one can have a look at Google Checkout. It also supports donations: https://checkout.google.com/support/bin/answer.py?hl=en&answer=105654 Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Till Harbaum / Lists wrote: > Hi, > > Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: >> This is my goal, but please move them in the 32GB storage. :-) > Oh, i see what you mean. Urgh ... that's a tricky one as moving > them for one app will break the other one. I don't think it's such a big problem: in the post-install script of the updated applications we can have a test that checks if the old tile directory exists (and is a regular dir, not a symlink) and if so copies all the tiles into the new location, and then removes the old dir and makes it a symbolic link to the new location. (the 32GB storage is FAT32 so it cannot have symlinks, but /home is ext3 so it should work) Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Hi Till, Till Harbaum / Lists wrote: > Am Mittwoch 30 Dezember 2009 schrieb Alberto Mardegan: >> Speaking of which, it would be nice if you instructed osmgpsmap to store >> the tiles under /home/user/MyDocs/.maps/ so that they could be shared >> with maemo-mapper (I probably need to modify it a bit so that the >> repository names are the same that osmgpsmap uses). > Uhm, maemo mapper has only recently been ported to maemo5. When > i came up with my naming scheme i was the only one storing map tiles > that way. Changing things now would mean that all of my apps have to > cleanup the old paths and convert the to the new scheme while at the > same time making sure that they don't affect maemo mapper etc etc ... I'm not proposing a different naming scheme: the one you osmgpsmap uses is fine, what I don't like is the base dir used by ecoach: IIRC, it's storing the tiles under /home/user and not on the 32GB flash (which is /home/user/MyDocs/). Then, the tiles need to be under a directory whose name starts with a dot, so that tracker won't index them. > And finally: Since when does maemo mapper store plain tiles at all?? Doesn't > it store everything in databases (even in varying sqlite or gnudb format)? I changed that: this way the code is much cleaner, it's at least as fast and we can share the tiles with other apps. > What about making maemo mapper deal with my repositories? I very likely > by now have the bigger installed user base and thus have to expect more > trouble during such a transition. This is my goal, but please move them in the 32GB storage. :-) Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New optification issues in extras-testing
Till Harbaum / Lists wrote: > i have just been instructed to reduce the size of osm2go _incl._ its > depending libraries to under 500k: Speaking of which, it would be nice if you instructed osmgpsmap to store the tiles under /home/user/MyDocs/.maps/ so that they could be shared with maemo-mapper (I probably need to modify it a bit so that the repository names are the same that osmgpsmap uses). Or please let me know if you have a better proposal. Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Attn map application developers: common cache for maps
Hi all, I'd like to propose a standard location to store cached map tiles (from openstreetmaps, google, or whichever), so to avoid re-downloading the same tiles when a user is using several applications which store their data in different directories. I'm working on maemo-mapper at the moment, and I know there are other applications (eCoach for instance) that are using map data. We could save user's bandwidth, time and flash space if we put the map tiles in the same place. I would suggest using ~/MyDocs/.maps/.png Where can be "google.com", "openstreetmap.org" or others, and is "street", "satellite", "hybrid", etc. Does anyone have a better proposal? Any map application developers here, interested in sharing maps with maemo-mapper? Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Profiling applications (oprofile, others?)
Andrea Borgia wrote: > Alberto Mardegan ha scritto: > >>since fremantle's maemo-mapper is so horribly slow, I went and tried to >> run >> oprofile. > > AFAIK, it was very slow even on Diablo: > https://bugs.maemo.org/show_bug.cgi?id=4452 Believe me, it's even slower :-) About the map cache, I don't see much point of having it in a DB at all, I would just use the filesystem. But I'll try to get all the developers of maps application to agree on a common place/format to store downloaded maps, in order to share it. Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Profiling applications (oprofile, others?)
Hi all, since fremantle's maemo-mapper is so horribly slow, I went and tried to run oprofile. Unfortunately it seems to me that static functions never appear in the final report. Is this how it is supposed to work? What other profiling tools can you recommend? TIA, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Double checking free/nonfree packages
Christopher Allan Webber wrote: > Mission control > --- > > Marked as nonfree on the graph, however irc conversation reveals: > > paroneayea: MC itself is LGPL [15:13] > paroneayea: Maemo uses osso-mission-control, which is upstream MC plus > some proprietary bits > > Any details on what these proprietary bits are, how they can be removed? * Special handling for emergency calls * Handling of connectivity (libconic) events * State management via MCE: MC tells MCE when we are in a call, and listens to MCE signals (offline mode requires some special handling) * Password storage is done with signon daemon. * Missed call notifications There is some more, but this are the most obvious things. The proprietary components are the /usr/bin/mission-control binary and the plugins in /usr/lib/mission-control/. Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Disable portrait support for dialog with Hildon
Cornelius Hald wrote: > How can I remove the flags from the dialog window? hildon_gtk_window_set_portrait_flags ( GTK_WINDOW (dialog), 0); Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder & /opt
Andrew Flegg wrote: > Alberto wrote: >> Graham Cobb wrote: >>> So, the consensus decision was that the solution would be that autobuilder >>> should automatically optify by default. >> Sounds wrong to me. > > Can you elaborate? I'd like to be convinced (as I was during the BOF) rather > than just whomever expresses the most feelings most often and loudest getting > their way. Sure :-) > Assuming: > * Developers want to upload the same source package > for Diablo, Fremantle and Mer; I have some doubts on this assumption. Fremantle is rather different then the previous version, so the source package will be most likely a separate one (especially for UI apps). At least this is going to be the case for maemo-mapper. > * /opt won't be necessary at some point in > the future, or on some devices such as those > running Mer; > * Nokia aren't going to implement a union FS or > just use the NAND for swap (and put the rootfs > on the eMMC) in the shortf (or even, probably, > medium-) term; > * Pretty much every package on Maemo should be using > /opt as much as possible; Ok, but then the maemo-optify will be doing different things in the various build environments. > ...it was concluded that: > > a) Modifying debian/rules is hacky and causes > forking between Diablo, Fremantle and Mer. Mmm... It might be hacky, true. But it does not cause any forking, if we provide it for Diablo and Mer too. > b) A control file field makes the most sense to > control the build process. Agreed. > c) That the absence of the control field would > Do The Right Thing ((c) Ruby, Perl, Groovy) > which, on Fremantle, is optification in most cases. Maybe. I don't have a strong opinion about that, but I wonder if the automatic optification might introduce some subtle bugs that the developer might have trouble to investigate, if he doesn't know that the build system did modify his package. Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder & /opt
Graham Cobb wrote: > So, the consensus decision was that the solution would be that autobuilder > should automatically optify by default. Sounds wrong to me. I agree with Ed, the default should be "manual": so, non optified packages would fail to build, but fixing that would be as easy as adding a "XS-Maemo-Optify: none". Ciao, Alberto -- http://www.mardy.it <-- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to find the author of a git commit?
Hi, I noticed just now that a few days ago someone committed some code into maemo-mapper, but I have no idea who did. I will ask in the project forum, but in case the author is not following it, is it possible to find out who the author was by looking at the git commit? It's this one: https://garage.maemo.org/plugins/ggit/browse.php/?p=maemo-mapper;a=commit;h=edd250bb545e15385375b131843d080ec81a8d1f Thanks in advance, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: git push problem at git.maemo.org
Ferenc Szekely wrote: > Apologies for the inconvenience if you and your project are affected. In the meantime are there any workarounds to this problem? Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: git push problem at git.maemo.org
Ferenc Szekely wrote: > Please let me know if you experienced problems (except speed) when > pushing code changes to git.maemo.org. Also please let me know if you > read or heard about workarounds in case git (or actually curl) returns > with "error code 18" [2] following push. I just encountered this error by pushing my changes to maemo-mapper: === $ git push gmo clutter:clutter error: Cannot access URL https://git.maemo.org/projects/maemo-mapper/, return code 18 error: failed to push some refs to 'https://git.maemo.org/projects/maemo-mapper' === Also, the web interface doesn't work: if from https://garage.maemo.org/scm/?group_id=29 I click on "Browse git repository" I get a page that tells me: === Error Could not open script https://git.maemo.org/?p=maemo-mapper." === I guess it's not related to that, but I'm sure it was working some time ago. Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
Graham Cobb wrote: > When porting my applications to Fremantle I have not had to add #ifdef's for > all my dialog boxes to cause them to have buttons on the right. Why is that? > > it is because I used a dialog box widget and the widget has been modified to > do that! Yes, good example! That's about the _only_ thing that you don't have to change! :-) What about hildon_button_set_theme_size(), that you must call for every button? Ciao, Alberto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [clutter] Clutter 1.0 in maemo fremantle
Update:
Alberto Mardegan wrote:
> JiangWei Zhou wrote:
>> you may remove the EGL_STENCIL_SIZE, 8 from the egl config list
>> and try again.
>> i just wonder it may cause this problem. but in our target, there is
>> no such problem.
I checked the source code of clutter-0.8 in maemo, and with that
attribute list it worked. Then I try to remove the differences one by
one, to reduce them to the minimum: strangely enough, the problem is in
specifying EGL_{RED,GREEN,BLUE}_SIZE. Removing them from the attributes
array make the whole things work.
I guess I won't submit a patch for it, as the change is maemo-specific:
I cannot see any reason why specifying those sizes would break the thing.
Anyway, I'm happy to announce that I got clutter 1.0 and clutter-gtk
0.10 to work fine in maemo fremantle. I'll create a project in
garage.maemo.org and upload the packages as soon as I've cleaned them up
a bit. :-)
Thanks for your support!
Alberto
--
http://www.mardy.it <- geek in un lingua international!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [clutter] Clutter 1.0 in maemo fremantle
JiangWei Zhou wrote: > you may remove the EGL_STENCIL_SIZE, 8 from the egl config list > and try again. > i just wonder it may cause this problem. but in our target, there is no > such problem. Mmmm... the more I play with egl the less I understand how it works. The call to eglChooseConfig() changes the configs variable, and puts in the first element of the array a configuration in which R, G, B, and A are all 8 bits (which presumably are not supported, because AFAIK on the N900 X starts on 16 bit mode). Anyway, commenting out the call to eglChooseConfig makes things go slightly better: eglCreateWindowSurface() succeeds. But then the context creation fails, with error EGL_BAD_CONFIG again. If I remove the attributes parameter and just pass NULL there, then it still fails but the error code is 0x3001, i.e. EGL_NOT_INITIALIZED. Any hints on what to try now? Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [clutter] Clutter 1.0 in maemo fremantle
Hi, JiangWei Zhou wrote: > when you run the test-actors test app, does it produce the same output? > it seems in clutter , it cannot create the egl window surface. > use |*eglGetError *|to check the error code ,which is not correct. > i think this may help you to find the cause. Yes, I get the same output from the test-actors test (the only difference is that test-actors exits shortly after the error occurs, while test-text loops forever). For both tests the error code is 0x3005, EGL_BAD_CONFIG. I'll try to investigate a bit more. Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Clutter 1.0 in maemo fremantle
(sorry for the crossposting, I couldn't decide which list was best) Hi all, I'd like to use clutter 1.0 (and clutter-gtk 0.10) in maemo fremantle, but so far I've had no luck. After applying the patches from bugs: http://bugzilla.openedhand.com/show_bug.cgi?id=1698 http://bugzilla.openedhand.com/show_bug.cgi?id=1795 the build succeeded, but at runtime nothing appears on screen, and from the attached logs it seems that there is something wrong with EGL. Can anyone help me in finding out what's wrong? I can create a project on garage.maemo.org and upload the packages and the git repository, in case someone wants to hack on it. Ciao, Alberto -- http://www.mardy.it <- geek in un lingua international! Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterX11 - [BACKEND] clutter-backend-x11.c:147: XOpenDisplay on ':0.0' Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterX11 - [BACKEND] clutter-backend-x11.c:174: Getting the X screen Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE Clutter - [BACKEND] ./clutter-backend.c:165: Units per em: 12,00 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterX11 - [BACKEND] clutter-backend-x11.c:226: X Display ':0.0'[0x1a3a8] opened (screen:0, root:68, dpi:96,00) Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-backend-egl.c:55: EGL Reports version 1.4 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE Clutter - [BACKEND] ./clutter-stage.c:1004: Creating stage from the default backend Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-backend-egl.c:245: Creating stage of type 'ClutterStageEGL' Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [MISC] clutter-backend-egl.c:260: EGLX stage created (display:0x1a3a8, screen:0, root:68) Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE Clutter - [ACTOR] ./clutter-actor.c:1183: Realizing actor 'ClutterStage' [0x28010] Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE Clutter - [ACTOR] ./clutter-actor.c:1183: Realizing actor 'ClutterStageEGL' [0x29018] Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:86: Realizing main stage Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:5 G:6 B:5 A:0 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:5 G:6 B:5 A:0 S:0 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:5 G:6 B:5 A:0 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:8 G:8 B:8 A:8 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:8 G:8 B:8 A:8 S:0 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:8 G:8 B:8 A:8 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:8 G:8 B:8 A:8 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:5 G:6 B:5 A:0 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:4 G:4 B:4 A:4 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:5 G:6 B:5 A:0 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:5 G:6 B:5 A:0 S:0 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:5 G:6 B:5 A:0 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:8 G:8 B:8 A:8 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:8 G:8 B:8 A:8 S:0 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE ClutterEGL - [BACKEND] clutter-stage-egl.c:147: EGLConfig == R:8 G:8 B:8 A:8 S:8 Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE Clutter - [LAYOUT] ./clutter-actor.c:4523: Width request for -1,00 px Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE Clutter - [LAYOUT] ./clutter-actor.c:4594: Width request for 640,00 px Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB CRITICAL ** ClutterEGL - Unable to create an EGL surface Sep 5 10:24:57 Nokia-N900-37-0 test-text[4858]: GLIB MESSAGE Clutter - [PAINT] ./clutter-stage.c:
Re: Need clutter-gtk
Kimmo Hämäläinen wrote: > On Wed, 2009-09-02 at 19:04 +0200, ext Alberto Mardegan wrote: >>I'm trying to use clutter-gtk 0.8.2 from extras-devel, but it >> segfaults as soon as I create an instance of the ClutterEmbed widget >> (clutter_x11_get_stage_visual returns NULL and then this pointer is >> accessed without checking). >>[...] > > I'm not aware of any version that has been tested with Maemo 5. However, > I can't imagine why upstream 0.8.X versions wouldn't work. I instantiated the ClutterEmbed right at the beginning of the main(), just after gtk_clutter_init(). I cannot see what I could be doing wrong there. Googling a bit, it seems that I'm not the only one having problems with clutter-gtk 0.8: http://lists.maemo.org/pipermail/maemo-developers/2009-July/020045.html Anyway, any plans to integrate clutter 1.0? Ciao, Alberto ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Need clutter-gtk
Hi, I'm trying to use clutter-gtk 0.8.2 from extras-devel, but it segfaults as soon as I create an instance of the ClutterEmbed widget (clutter_x11_get_stage_visual returns NULL and then this pointer is accessed without checking). In the SDK this package is missing. Is there a working version in some repository? If not, which version of clutter-gtk should I compile? TIA, Alberto -- http://www.mardy.it <- geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: desktop/home plugins 2nd round
ext Collin R. Mulliner wrote: > 2) Has anybody written a home plugin for Maemo 4.x and has published >the source? Yes, I wrote a stock-market plugin: https://garage.maemo.org/projects/stock-plugin/ You can browse the source here: https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/?root=stock-plugin Ciao, Alberto -- http://www.mardy.it <-- Geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mission control not implementing prefixes properly
ext Rainer Dorsch wrote: > Hello, > > I compiled mission-control outside my standard file system using > > ./configure --prefix=/opt/gtalk > make > make install > > The overall goal was to get empathy running outside the standard file system. > > Mission control apparently does not implement the prefix specified properly, > empathy segfaults because of that: MC is expecting to find the data file in the standard file system directories. However, you can override this by passing the --with-profiles-dir and --with-managers-dir options to the configure script, or override them at run-time, with the MC_PROFILE_DIR and MC_MANAGER_DIR environment variables. Ciao, Alberto -- http://www.mardy.it <-- Geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: latest rtcomm beta b0rked my "add account" button.
ext Jesse Guardiani wrote: > It's still broken. Is there anything I can do to find out why it's broken? There is a bug for it in the bugzilla: https://bugs.maemo.org/show_bug.cgi?id=1952 It would be great if you could SSH into the device and run maemo-summoner /usr/bin/controlpanel.launch and post here (or even better in the bugzilla) what happens. Ciao, Alberto -- http://www.mardy.it <-- Geek in un lingua international! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
