Re: [MeeGo-dev] N900 hardware adaptation team sync meeting Thursday 24 June 9.00 EEST (8.00 CEST, 6.00 UTC, wednesday 23.00 PDT).

[Carsten Munk]

2010/6/21 Carsten Munk :
> We'll be having another N900 hardware adaptation team sync meeting at
> Thursday 24 June 9.00 EEST (8.00 CEST, 6.00 UTC, wednesday 23.00 PDT)
> - everyone's welcome to join and contribute.
>
> Current state of agenda can be seen at http://wiki.meego.com/ARM/N900/Meetings
>

Meeting minutes can be found at
http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-06-24-06.01.html

Next meeting date TBA.

Best regards,
Carsten Munk
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] Booting Moorestown image

[Veerabhadra Sheelavant]

 Hi,

I have downloaded the
meego-preview-shcdk-core-20100330-001.tar.bz2
image
for Intel atom based handset(Moorestown).
I could not find the instructions create image and boot the Moorestown
device.

Please can anybody let me know the instructions to boot from the above tar
file.

thanks,
kumar
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] MeeGo build and development setenvironment setup for ARM

[Zheng Zhang]

Hi everyone,

I want to do the MeeGo build and development environment setup work for the
ARM platform.And I have several plans, such as:
1.Use the MeeGo SDK following the
http://wiki.meego.com/Getting_started_with_the_MeeGo_SDK_for_Linux, and
install some cross-compile toolchain in it for the arm development.

2.Use the mic-image-creator and mic-chroot to make a MeeGo chroot
environment, and install some cross-compile toolchain from
http://repo.meego.com/MeeGo/releases/1.0/core/repos/ia32/packages/i586/ in
it for the arm development.

3.Use the MADDE

4.Waiting for the MeeGo SDK for ARM(N900 device)

So what is your recommendation?Thank you for your advice!

Br
Zheng
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[王国宁]

Dear Arjan, Auke
thanks for your answer.

在 2010年6月24日 上午1:32，Arjan van de Ven 写道：

> On 6/23/2010 10:31 AM, Auke Kok wrote:
> > On 06/23/2010 02:47 AM, 王国宁 wrote:
> >
> >> Another question hasn't be answered: X, QT is must, right?
> >> If I want to develop a application for MeeGo,  am I use the QT to
> develop the UI?
> >>
> >
> > no, if you really wish to use an alternative widget set, that is
> > allowed. However, there are certain downsides to doing that (larger
> > overhead for your application, more package requirements, more
> > development time etc).
> >
>
> to correct this, it may be allowed, but your application will not be
> MeeGo compliant and there's no guarantee it
> works in newer versions or in versions done by other people or other
> devices.
> so it's not allowed in that sense.
>
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[Thiago Macieira]

Em Quarta-feira 23. Junho 2010, às 20.02.29, Patrick Ohly escreveu:
> > One thing I've wanted to do but never had the time was to have an
> > "overlay" system for the XML files, which would append extra
> > information, like the C++ type that matches the complex signature.
> 
> That sounds like an improvement over copying the file, in particular
> when different apps prefer to have different mappings to local types,
> but still doesn't address the "out-of-the-box" aspect.

There's nothing I can do about that. The tool needs to know what C++ type to 
match. A type of (ii) can mean both a point (like QPoint) or a line (QLine) or 
something else.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Trusted computing and TrustZone Adaptation

[Shaz]

>
> btw who is "ours"; you're using a gmail address so it's not clear who
> you're working for/on behalf of
>
>
I am one of the representative of the intelligentsia known as the community.
Anyways, we are a group of researchers and prototype implementation group
where we design and implement state of the art in security ranging from
domain specific languages and transformations to low level system security.
Mobile platforms is one of our concerns.

http://serg.imsciences.edu.pk funded by ICT R&D and linked to trusted
computing efforts with researchers from the industry like Samsung
information System America for instance. I am afraid we are not updating our
website much but if any more specific details are required than what are
given in this thread than you can email your questions.

I personally handle the design and supervise implementation of system
security and our work is now mature enough to align it with community
efforts. From two years we are working on building skills and now we are
ready to contribute. We were more active in pure research till some time ago
and now we are going more implementation specific.

We have server side expertize which are also maturing up but that is not
relevant to these lists.

thanks.

-- 
Shaz
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[Patrick Ohly]

On Wed, 2010-06-23 at 18:25 +0100, Thiago Macieira wrote:
> On Wednesday 23 June 2010 13:39:22 Patrick Ohly wrote:
> > But I'm far from being an expert on this. I don't know whether all
> > projects with D-Bus interfaces already have the necessary QDBus
> > annotations.
> 
> They probably don't. But it's a matter of whether you need them or not. Like 
> Rusty said, you can just comment them out.

But that implies that every user of the .xml files has to maintain a
local copy, possibly repeating the same work that someone else has
already done. IMHO this is okay as a short-term solution, but in order
to have it work out-of-the-box, the upstream .xml files need to be
patched.

> One thing I've wanted to do but never had the time was to have an "overlay" 
> system for the XML files, which would append extra information, like the C++ 
> type that matches the complex signature.

That sounds like an improvement over copying the file, in particular
when different apps prefer to have different mappings to local types,
but still doesn't address the "out-of-the-box" aspect.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Trusted computing and TrustZone Adaptation

[Arjan van de Ven]

On 6/23/2010 10:56 AM, Shaz wrote:

Dear lists,

We are designing some work based on our existing implementation of 
secure computing on mobile devices but I wanted to get an idea what 
has been planned by the base system designers regarding trustzone 
security feature available to modern ARM architectures. Apart from 
trustzone trusted computing features can still exist so not sure what 
is the progress on your end.


I have added some preliminary ideas on Linaro/Ubuntu lauchpad for 
trusted computing as well but before actually taking it serious for 
full design based on existing research and respectively possible 
implementation steps we would like to confirm with you regarding any 
plans that I might not contradict or possibly add synergy to them.


MeeGo security framework is a bit different than ours with respect to 
MAC as we use SELinux and possibly Tomoyo as they can take care of 
complex and simple scenarios respectively.



btw who is "ours"; you're using a gmail address so it's not clear who 
you're working for/on behalf of


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] Trusted computing and TrustZone Adaptation

[Shaz]

Dear lists,

We are designing some work based on our existing implementation of secure
computing on mobile devices but I wanted to get an idea what has been
planned by the base system designers regarding trustzone security feature
available to modern ARM architectures. Apart from trustzone trusted
computing features can still exist so not sure what is the progress on your
end.

I have added some preliminary ideas on Linaro/Ubuntu lauchpad for trusted
computing as well but before actually taking it serious for full design
based on existing research and respectively possible implementation steps we
would like to confirm with you regarding any plans that I might not
contradict or possibly add synergy to them.

MeeGo security framework is a bit different than ours with respect to MAC as
we use SELinux and possibly Tomoyo as they can take care of complex and
simple scenarios respectively.

Thanks.

-- 
Shaz
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[Arjan van de Ven]

On 6/23/2010 10:31 AM, Auke Kok wrote:
> On 06/23/2010 02:47 AM, 王国宁 wrote:
>   
>> Another question hasn't be answered: X, QT is must, right?
>> If I want to develop a application for MeeGo,  am I use the QT to develop 
>> the UI?
>> 
>
> no, if you really wish to use an alternative widget set, that is
> allowed. However, there are certain downsides to doing that (larger
> overhead for your application, more package requirements, more
> development time etc).
>   

to correct this, it may be allowed, but your application will not be
MeeGo compliant and there's no guarantee it
works in newer versions or in versions done by other people or other
devices.
so it's not allowed in that sense.

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[Auke Kok]

On 06/23/2010 02:47 AM, 王国宁 wrote:
> Another question hasn't be answered: X, QT is must, right?
> If I want to develop a application for MeeGo,  am I use the QT to develop the 
> UI?


no, if you really wish to use an alternative widget set, that is
allowed. However, there are certain downsides to doing that (larger
overhead for your application, more package requirements, more
development time etc).

Auke
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 10:24 AM, Dave Neary wrote:

but your phone and tablet almost always are only used on battery. So

basically you now have degraded behavior
all the time the user is using the device. sounds like a really bad plan
to me.
 

There's the bandwidth issue, which is separate - and there are codecs
that can adaptively change their bandwidth usage. But yeah, I think that
there are apps where it's appropriate to have a lesser user experience
for someone who's not on A/C.
   


bandwidth is 100% orthogonal. Scaling behavior with available bandwidth 
(or cost of bandwidth) is perfectly legit

and based on something real.

   

the difference between 5 minutes and 30 minutes is not power visible to
be honest; this would be a "how am I connected" tradeoff not a power one.
And .. half an hour on all phones all the time? you're kidding ;)
 

Without getting into the details... the principle stands. And again, I
see the bandwidth issue as only one parameter. The key is "do less".

Just out of interest, do you see half an hour as too far apart, or too
close together? I'm having trouble figuring out.
   


waay too far apart. Users will not accept that if their phone is 30 
minutes behind on email and twitter and .. and ..


   

i can go on and on, but... with devices being almost always on battery,
and your examples very visibly and annoyingly degrading the experience...
(and often NOT being about AC/Battery but about where the device is
at that point in time)
 

Meh. I guess we have different ideas about what "degrading" means. I
think the user experience you expect does change if you're on the move.
Of course, if you're thinking about a laptop, you might consider some of
the ideas here annoying. But I definitely think that the use-case when
you have a phone in your pocket or on a charger is different than a
netbook. Perhaps you're falling into "All the world's a netbook"
thinking a little?
   


absolutely not. In fact I think you are ;-)
netbooks are at least sometimes used on power.
mobile phones and tablets are otoh almost only really used on battery.
people tend to charge it at night when they're not using it.
people tend to disconnect that annoying wire/take it out of the cradle 
when starting to use it
and when the phone is actually charging, it matters again (due to the 
thermal constraints)


phone-in-pocket is an interesting case for sure, but that's an idle 
case, and there is no tradeoff there to be made

realistically.

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Auke Kok]

On 06/23/2010 08:15 AM, Dave Neary wrote:

Hi,

Rob Staudinger wrote:

On Wed, 2010-06-23 at 14:06 +0100, Dave Neary wrote:

Good point - it would be great to know when you're on battery, and do
even less.


What would be even more helpful than going back and forth
   "apps should know about battery" ..
   "no they should not" ..
   "but they need to" ..
would be if people who have concerns about their apps would bring actual
use-cases forward.


I agree :) Didn't realise I was going to be starting a ruckus.

I agree with Arjen that if your app is going to be in a context where
power is important, then you should just make power usage a top priority
regardless of "on A/C" or "not on A/C". But with netbooks and mobile
phones, we'll clearly be in a situation where some portion of the usage
time will be on A/C and in those situations, saving battery is not an
issue (general "being a good citizen" still is, of course).


Once the tradeoff between user experience and power consumption is clear
for a certain case it will be much easier to decide whether AC/battery
status information is needed.


Here's a few examples that come to mind:

* Video player - wants to give best experience possible when on A/C, so
goes with HD, high frame rate - but when on battery, reduces video
quality&  frame rate to use less energy
* Email application that checks for&  downloads email every minute/5
minutes when you're hooked to A/C, but only every half an hour when on
the move
* Wifi detection that updates very regularly when on A/C, but only
occasionally (or after manual request) when on battery
* Screensaver that goes from "nice attractive eye candy" when on A/C to
"blank screen" (or suspend) when on the move
* Window manager automatically turning off knobs&  whistles&  3d effects
when on battery

etc. etc.

There are lots of situations where when you're on A/C you expect instant
updates, and when you're on the move they're just not that important.
And those are opportunities to adapt your user experience to be less
featureful, and thus less power-hungry.




most of this list is not even applicable to handsets, and really, only 
applicable to geekstations (let's just use that term for workstations 
which never make it into C2 or deeper, and run some form of cows or seti).


Yeah, this post is a bit sarcastic, sorry about that :)

I can probably pick each item in this list apart easily. Wifi usually 
updates ten times per second if not more, even with power management 
features enabled. I don't think more updates per second will help anyone.


Even on my home geekstation with a 30 inch LCD screen, I want the damn 
screen to go off so it doesn't suck 100W when I take a quick break :) 
(Mind you, my wife has one too so it shows in the electricity bill if 
the screensaver on one of them is not functional and lights up my living 
room at night).


Window manager knobs and whistles would consume cpu power when doing 
normal work, therefore degrading the performance of the system while on 
A/C power, thus lowering the overall response and hindering other 
applications - so window manager bells and whistles need to be fast and 
power efficient (3d hardware accelerated, short, responsive ones offer 
great return on that. blatant throwing cpu power at this is just going 
to get in your way, and makes people use twm).


e-mail, now there is a valid point. The big problem is here that unix 
mail technologies aren't very good at PUSH mail. Only IMAP supports it 
and most clients ignore that. This is an issue with the underlying 
system. But, then again, keeping a TCP connection open and once-a-minute 
writing 30 characters to that is really not that power costly, is it?


almost always, in the long run, coding power-efficient algorithms as the 
default and only solution, will work the best for everyone.


I have yet to see an algorithm where "if (on_ac_power) {" does something 
anyone in my household excluding my 2 cats would really appreciate :)


BTW, the favorite spot in the house for one of my cats is on top of the 
cabinet that holds our set-top-box for cable TV even when it's off, 
it still produces a ton of heat.


I think the main problem with everyone coding for mobile is that they 
see a "pot of gold" at the end of the rainbow when "coding for power 
use" comes up, as if you can do amazing new things with a system when 
you plug in (or unplug) the power cord. This of course is completely false.


Auke
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[Thiago Macieira]

On Wednesday 23 June 2010 13:39:22 Patrick Ohly wrote:
> But I'm far from being an expert on this. I don't know whether all
> projects with D-Bus interfaces already have the necessary QDBus
> annotations.

They probably don't. But it's a matter of whether you need them or not. Like 
Rusty said, you can just comment them out.

One thing I've wanted to do but never had the time was to have an "overlay" 
system for the XML files, which would append extra information, like the C++ 
type that matches the complex signature.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Dave Neary]

Hi,

Arjan van de Ven wrote:
> On 6/23/2010 8:15 AM, Dave Neary wrote:
>> Here's a few examples that come to mind:
>>
>> * Video player - wants to give best experience possible when on A/C, so
>> goes with HD, high frame rate - but when on battery, reduces video
>> quality&  frame rate to use less energy
> 
> but your phone and tablet almost always are only used on battery. So
> basically you now have degraded behavior
> all the time the user is using the device. sounds like a really bad plan
> to me.

There's the bandwidth issue, which is separate - and there are codecs
that can adaptively change their bandwidth usage. But yeah, I think that
there are apps where it's appropriate to have a lesser user experience
for someone who's not on A/C.

> the difference between 5 minutes and 30 minutes is not power visible to
> be honest; this would be a "how am I connected" tradeoff not a power one.
> And .. half an hour on all phones all the time? you're kidding ;)

Without getting into the details... the principle stands. And again, I
see the bandwidth issue as only one parameter. The key is "do less".

Just out of interest, do you see half an hour as too far apart, or too
close together? I'm having trouble figuring out.

> i can go on and on, but... with devices being almost always on battery,
> and your examples very visibly and annoyingly degrading the experience...
> (and often NOT being about AC/Battery but about where the device is
> at that point in time)

Meh. I guess we have different ideas about what "degrading" means. I
think the user experience you expect does change if you're on the move.
Of course, if you're thinking about a laptop, you might consider some of
the ideas here annoying. But I definitely think that the use-case when
you have a phone in your pocket or on a charger is different than a
netbook. Perhaps you're falling into "All the world's a netbook"
thinking a little?

Cheers,
Dave.

-- 
maemo.org docsmaster
Email: dne...@maemo.org
Jabber: bo...@jabber.org

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Thiago Macieira]

On Wednesday 23 June 2010 14:31:12 Arjan van de Ven wrote:
> On 6/23/2010 4:26 AM, Narendranath Ghosh wrote:
> > Hi,
> > 
> > three things coming to my mind.
> > 
> > 1. we cant guarantee that third party application development will be
> > well behaved.
> 
> well we'll find these, and point them out to the user
> so that the user will just not buy such bad apps from the app store !
> 
> Authors of apps have an economic incentive to get their app right
> (this is true on say Android today as well)

One of the first apps I downloaded from the N900 Extras-Devel repository ended 
up eating all RAM on my device. I woke up one morning and it was unusable.

Solution: removed it, for good.

Such apps in the store would get quickly negative rating. And as a matter of 
commercial sense, those apps should be screened out too.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Auke Kok]

On 06/23/2010 04:33 AM, Gary Birkett wrote:

On Tue, Jun 22, 2010 at 6:08 PM, Arjan van de Ven  wrote:

correct. there are, by design, no special APIs in MeeGo for applications to
be power friendly.
It must be sufficient for an application to be well behaving [*] for it to
be power friendly in MeeGo.



would it be wise to document all the best practices in one place though?


as I referred to before, check lesswatts.org

Auke
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 10:00 AM, Graham Cobb wrote:

It should be up to the app developer.  If they have a neat idea for how to
adjust behaviour dependent on whatever they feel are the appropriate
parameters (power, temperature, connectivity, time since last update, what I
had for breakfast...) then they should be able to do it. The system should
provide the information the app developer needs to implement their ideas and
the users will judge them.
   


the information if you're on battery/etc is obviously available; there 
are very legitimate uses for that
(just to mention the most obvious one: the icon that shows how much 
battery you have left).


Just it's not what we want to recommend to app writers to use in power 
scenarios.


I *could* see a point of a am_I_power_sensitive() function somewhere
(which takes more into account than just ac/battery)

however I can also write it with 95% accuracy as

int am_I_power_sensisitive(void)
{
return 1;
}

that's correct for servers and phones that are discharging or charging, 
and many other scenarios ;-)



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Graham Cobb]

On Wednesday 23 June 2010 16:24:39 Arjan van de Ven wrote:
> i can go on and on, but... with devices being almost always on battery,
> and your examples very visibly and annoyingly degrading the experience...
> (and often NOT being about AC/Battery but about where the device is
> at that point in time)

You may be right.  

But, on the other hand, you may not be.  I want the system to enable great and 
innovative ideas for apps.  Unfortunately, that also means it enables crappy 
and useless ideas.  So be it.

Let the users decide which app behaviours they prefer: the apps the users 
prefer will win.  

It should be up to the app developer.  If they have a neat idea for how to 
adjust behaviour dependent on whatever they feel are the appropriate 
parameters (power, temperature, connectivity, time since last update, what I 
had for breakfast...) then they should be able to do it. The system should 
provide the information the app developer needs to implement their ideas and 
the users will judge them.

They may even be developing an app which is completely different to the way 
anyone on this list expected the device to be used.  Great!

Graham

P.S. Personally I think that after the hype about the iPad has died down, 
tablets will go back to being kitchen devices -- normally sitting in a 
charging rack, picked up for a few minutes to walk around the kitchen 
measuring out ingredients, etc.  So, they will spend most of their time 
connected to power, although not necessarily to a high speed network.

I might be wrong -- I have been before :-)
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 8:15 AM, Dave Neary wrote:

I agree with Arjen that if your app is going to be in a context where
power is important, then you should just make power usage a top priority
regardless of "on A/C" or "not on A/C". But with netbooks and mobile
phones, we'll clearly be in a situation where some portion of the usage
time will be on A/C and in those situations, saving battery is not an
issue (general "being a good citizen" still is, of course).
   


other than while charging being in a thermal sensisitve environment you 
mean ;)
   

Once the tradeoff between user experience and power consumption is clear
for a certain case it will be much easier to decide whether AC/battery
status information is needed.
 

Here's a few examples that come to mind:

* Video player - wants to give best experience possible when on A/C, so
goes with HD, high frame rate - but when on battery, reduces video
quality&  frame rate to use less energy
   


but your phone and tablet almost always are only used on battery. So 
basically you now have degraded behavior
all the time the user is using the device. sounds like a really bad plan 
to me.

* Email application that checks for&  downloads email every minute/5
minutes when you're hooked to A/C, but only every half an hour when on
the move
   
the difference between 5 minutes and 30 minutes is not power visible to 
be honest; this would be a "how am I connected" tradeoff not a power one.

And .. half an hour on all phones all the time? you're kidding ;)


i can go on and on, but... with devices being almost always on battery, 
and your examples very visibly and annoyingly degrading the experience...
(and often NOT being about AC/Battery but about where the device is 
at that point in time)


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[Rusty Lynch]

On 06/23/2010 04:39 AM, Patrick Ohly wrote:

On Wed, 2010-06-23 at 11:35 +0100, ronan.maclave...@nokia.com wrote:
   

Do the DBus bindings for Qt (QDbus) work on MeeGo?  It has some nice
features like an interface compiler (qdbusxml2cpp).
 

That depends on the content of the XML interface definition and how it
is installed.

How we do it in SyncEvolution is:
   * .xml files go into /usr/share/dbus-1/interfaces/ as part of the
 development package.
   * These files need
 elements for the more complex types.
   * dbus-binding-tool for glib-dbus does not like annotations in
   specifications, so we filter out the annotations when
 building the GTK sync-ui.

But I'm far from being an expert on this. I don't know whether all
projects with D-Bus interfaces already have the necessary QDBus
annotations.

   
This only happens when the signature is more complex then what 
qdbusxml2cpp understands.  I've created a bunch of proxies for such 
things as udisks and libsocialweb, and I have found a few of signatures 
that confused the tool, but so for nothing that i needed (i.e. i just 
comment out the method/signal in the xml and re-run the tool.)


So far I've hit:
* a(ssxa{ss})
* a{ss}
* a(td)
* a(ssbbbu)

...but i haven't filed a Qt bug yet.

--rusty

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Dave Neary]

Hi,

Rob Staudinger wrote:
> On Wed, 2010-06-23 at 14:06 +0100, Dave Neary wrote:
>> Good point - it would be great to know when you're on battery, and do
>> even less.
> 
> What would be even more helpful than going back and forth
>   "apps should know about battery" .. 
>   "no they should not" .. 
>   "but they need to" ..
> would be if people who have concerns about their apps would bring actual
> use-cases forward.

I agree :) Didn't realise I was going to be starting a ruckus.

I agree with Arjen that if your app is going to be in a context where
power is important, then you should just make power usage a top priority
regardless of "on A/C" or "not on A/C". But with netbooks and mobile
phones, we'll clearly be in a situation where some portion of the usage
time will be on A/C and in those situations, saving battery is not an
issue (general "being a good citizen" still is, of course).

> Once the tradeoff between user experience and power consumption is clear
> for a certain case it will be much easier to decide whether AC/battery
> status information is needed.

Here's a few examples that come to mind:

* Video player - wants to give best experience possible when on A/C, so
goes with HD, high frame rate - but when on battery, reduces video
quality & frame rate to use less energy
* Email application that checks for & downloads email every minute/5
minutes when you're hooked to A/C, but only every half an hour when on
the move
* Wifi detection that updates very regularly when on A/C, but only
occasionally (or after manual request) when on battery
* Screensaver that goes from "nice attractive eye candy" when on A/C to
"blank screen" (or suspend) when on the move
* Window manager automatically turning off knobs & whistles & 3d effects
when on battery

etc. etc.

There are lots of situations where when you're on A/C you expect instant
updates, and when you're on the move they're just not that important.
And those are opportunities to adapt your user experience to be less
featureful, and thus less power-hungry.

Cheers,
Dave.

-- 
maemo.org docsmaster
Email: dne...@maemo.org
Jabber: bo...@jabber.org

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] Technical Steering Group Meeting Rescheduled for June 30

[Foster, Dawn M]

The Technical Steering Group (TSG) meeting originally scheduled for today (June 
23rd) at 19:00 UTC has been rescheduled for next week. The next TSG meeting 
will be on June 30 at 19:00 UTC. Logistics for the TSG meetings along with the 
agenda can be found on the wiki page: 
http://wiki.meego.com/Technical_Steering_Group_meetings

Regards,
Dawn
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 6:32 AM, Arjan van de Ven wrote:

On 6/23/2010 6:27 AM, Rob Staudinger wrote:

On Wed, 2010-06-23 at 14:06 +0100, Dave Neary wrote:

[...]


Good point - it would be great to know when you're on battery, and do
even less.

What would be even more helpful than going back and forth
   "apps should know about battery" ..
   "no they should not" ..
   "but they need to" ..
would be if people who have concerns about their apps would bring actual
use-cases forward.

Once the tradeoff between user experience and power consumption is clear


there are generally tradeoffs, sure.
but battery tends to be not the right input to that.

ask any datacenter operator.

but even on phones most often performance is temperature limited, 
as is battery charging.
if you suddenly make the phone hot due to heavy cpu work, your battery 
will charge slower.
And/or you may have less capacity to raise the cpu speed due to the 
system being warmer already.


_



btw one thing to add; if you degrade the user experience (that's what 
"tradeoff" implies) on batter, you need
to also come to grips with the mobile usage model; it's not unthinkable 
that a large portion of mobile device users
(be it phone or tablet) is using his device only ever on battery (and 
charges his/her device when he's not using it).
That'd basically mean that you provide a 100% degraded experience to a 
sizeable portion of your userbase.



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 6:27 AM, Rob Staudinger wrote:

On Wed, 2010-06-23 at 14:06 +0100, Dave Neary wrote:

[...]

   

Good point - it would be great to know when you're on battery, and do
even less.
 

What would be even more helpful than going back and forth
   "apps should know about battery" ..
   "no they should not" ..
   "but they need to" ..
would be if people who have concerns about their apps would bring actual
use-cases forward.

Once the tradeoff between user experience and power consumption is clear
   


there are generally tradeoffs, sure.
but battery tends to be not the right input to that.

ask any datacenter operator.

but even on phones most often performance is temperature limited, as 
is battery charging.
if you suddenly make the phone hot due to heavy cpu work, your battery 
will charge slower.
And/or you may have less capacity to raise the cpu speed due to the 
system being warmer already.


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 6:06 AM, Dave Neary wrote:


Good point - it would be great to know when you're on battery, and do
even less.
   


absolutely not!

this is the wrong tradeoff.
really.

if you can do less legitimately... always do less.
not just when on battery

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Rob Staudinger]

On Wed, 2010-06-23 at 14:06 +0100, Dave Neary wrote:

[...]

> Good point - it would be great to know when you're on battery, and do
> even less.

What would be even more helpful than going back and forth
  "apps should know about battery" .. 
  "no they should not" .. 
  "but they need to" ..
would be if people who have concerns about their apps would bring actual
use-cases forward.

Once the tradeoff between user experience and power consumption is clear
for a certain case it will be much easier to decide whether AC/battery
status information is needed.

Best,
Rob

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[mahendra panpalia]

FO

On Wed, Jun 23, 2010 at 2:06 PM, Dave Neary  wrote:

> Hi,
>
> Gary Birkett wrote:
> > would it be wise to document all the best practices in one place though?
>
> Best practices, and tools you can use to identify, characterise and fix
> power issues.
>
> This has at least 3 different facades:
>
> * Do less stuff
>  - Use the right algorithms
>  - Don't do things you don't have to
>  - Don't poll needlessly
> * Work smarter
>  - Handle events asynchronously
>  - Be aware of trade-off between pre-calculating and working on-demand
> * Have a tuned system
>  - All the stuff powertop can find - allow devices & system components
> to switch off/suspend when not in use, increase buffering & writeback
> time, etc, etc
>
> The third one is the black magic stuff that I don't understand (and the
> only one addressed by lesswatts.org apparently). I do know that there's
> not much that an application developer can do at that level to ensure
> their app behaves well, but we can certainly ensure that apps are doing
> less and behaving correctly as good citizens when handling user
> interaction, wake-ups, signals, handling I/O, etc.
>
> I'd appreciate someone putting a guide together for those types of
> issues personally.
>
> > also for applications to be well behaved, they should know something
> > about their environment
> > to that end should know where to look for the charging status for
> instance
> > if the devices have a power profile available, the api to access this
> > should be documented and clearly stated
> > I believe that sort of information is what Narendranath Ghosh was
> requesting.
>
> Good point - it would be great to know when you're on battery, and do
> even less.
>
> Cheers,
> Dave.
>
> --
> maemo.org docsmaster
> Email: dne...@maemo.org
> Jabber: bo...@jabber.org
>
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>



-- 
Thanks and Kind Regards,
Mahendra Panpalia
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Dave Neary]

Hi,

Gary Birkett wrote:
> would it be wise to document all the best practices in one place though?

Best practices, and tools you can use to identify, characterise and fix
power issues.

This has at least 3 different facades:

* Do less stuff
 - Use the right algorithms
 - Don't do things you don't have to
 - Don't poll needlessly
* Work smarter
 - Handle events asynchronously
 - Be aware of trade-off between pre-calculating and working on-demand
* Have a tuned system
 - All the stuff powertop can find - allow devices & system components
to switch off/suspend when not in use, increase buffering & writeback
time, etc, etc

The third one is the black magic stuff that I don't understand (and the
only one addressed by lesswatts.org apparently). I do know that there's
not much that an application developer can do at that level to ensure
their app behaves well, but we can certainly ensure that apps are doing
less and behaving correctly as good citizens when handling user
interaction, wake-ups, signals, handling I/O, etc.

I'd appreciate someone putting a guide together for those types of
issues personally.

> also for applications to be well behaved, they should know something
> about their environment
> to that end should know where to look for the charging status for instance
> if the devices have a power profile available, the api to access this
> should be documented and clearly stated
> I believe that sort of information is what Narendranath Ghosh was requesting.

Good point - it would be great to know when you're on battery, and do
even less.

Cheers,
Dave.

-- 
maemo.org docsmaster
Email: dne...@maemo.org
Jabber: bo...@jabber.org

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Qt Mobility says "Hello MeeGo World!"

[Renato Araujo]

Hi Guys,

Congratulations for all this work on QtMobility, this is a great API
and this will make the developer work more easy :D.

I would like to use this opportunity to announce  the fists steps to
QtMobility Python binds have already started and the PySide[1] team
are working hard to have the complete QtMobility bindings in the next
weeks, and we will expect to keep the bindings updated with the new
changes and sync with the meego project.

You can follow the progress in the gitorious project[2].

[1] PySide home: http://www.pyside.org/
[1] QtMobility bindings: http://qt.gitorious.org/pyside/pyside-mobility

BR
Renato Araujo Oliveira Filho

On Wed, Jun 23, 2010 at 7:47 AM,   wrote:
> Hi Guys,
> Firstly thank you all for such a warm welcome.
> A couple of people have asked that I draft a blog here on meego.com and im 
> happy to facilitate.
> So I hope that we can set that up in the next few days.
> In the interim, I believe Min has answered most questions and for others that 
> may be remaining, I hope that we can address those in the blog post here on 
> Meego.com
>
> Kind regards,
> Gerard.
>
>
>
>
>>-Original Message-
>>From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com]
>>On Behalf Of Shin Minjung (Nokia-D-Qt/Brisbane)
>>Sent: Wednesday, June 23, 2010 11:09 AM
>>To: meego-dev@meego.com
>>Subject: Re: [MeeGo-dev] Qt Mobility says "Hello MeeGo World!"
>>
>>Hi Dave,
>>
>>I can access it now. Thanks you.
>>
>>Regards,
>>Min
>>
>>-Original Message-
>>From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com]
>>On Behalf Of ext Dave Neary
>>Sent: Tuesday, 22 June 2010 9:25 PM
>>To: Development for the MeeGo Project
>>Subject: Re: [MeeGo-dev] Qt Mobility says "Hello MeeGo World!"
>>
>>Hi Min,
>>
>>minjung.s...@nokia.com wrote:
>>> It seems http://bug.meego.com is down at the moment...
>>
>>Did you try http://bugs.meego.com?
>>
>>Google finds this page with "MeeGo bug tracker":
>>http://meego.com/community/bug-tracking
>>
>>There is a bug about Google indexing of bugs.meego.com open, which will
>>perhaps make Bugzilla easier to find when it's fixed:
>>http://bugs.meego.com/show_bug.cgi?id=1967
>>
>>Cheers,
>>Dave.
>>
>>--
>>maemo.org docsmaster
>>Email: dne...@maemo.org
>>Jabber: bo...@jabber.org
>>
>>___
>>MeeGo-dev mailing list
>>MeeGo-dev@meego.com
>>http://lists.meego.com/listinfo/meego-dev
>>___
>>MeeGo-dev mailing list
>>MeeGo-dev@meego.com
>>http://lists.meego.com/listinfo/meego-dev
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Fwd: [MeegoMessenger-Developer-Forum] build requirements libupnp & libpinentry

[Bernd Stramm]

On Wed, 23 Jun 2010 06:19:21 +0200
Randolph Dohm  wrote:

> Hi
> there is already a Forum question to the MeeGoDevels,
> how MeeGo wants to add upnp and pinentry.
> We build rpms for that, maybe you want include it by default.
> Thanks
> 

I filed a bug for the pinentry issue. Until that is resolved, we have a
temporary solution providing an unofficial rpm for our purposes. If
there should be a collision with an official rpm, I would advise people
to use the offical version. At present they can't do that, since there
isn't any.

-- 
Bernd Stramm


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 4:26 AM, Narendranath Ghosh wrote:

Hi,

three things coming to my mind.

1. we cant guarantee that third party application development will be
well behaved.

   


well we'll find these, and point them out to the user
so that the user will just not buy such bad apps from the app store !

Authors of apps have an economic incentive to get their app right
(this is true on say Android today as well)

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Arjan van de Ven]

On 6/23/2010 4:33 AM, Gary Birkett wrote:

On T


correct. there are, by design, no special APIs in MeeGo for applications to
be power friendly.
It must be sufficient for an application to be well behaving [*] for it to
be power friendly in MeeGo.
 


would it be wise to document all the best practices in one place though?
   


sure makes sense

also for applications to be well behaved, they should know something
about their environment
to that end should know where to look for the charging status for instance
   


applications should ABSOLUTELY NOT care about charging status. That 
thinking is the first fundamental

mistake many people make :-)

1. Apps should in general not care about AC/DC. Really. Many people 
think "only on battery do I need to be power efficient".

That's just not true for many reasons (ask any datacenter operator)

2. Apps should not do "if the battery is less than 20% I should be power 
efficient" kind of thing. The last 20% of battery is not where it matters
to save power... it's the first 80%! Lets say that if you did nothing, 
you would have an hour left at 20%, and if you did the special thing, 
you'd have two hours left.

You'd say, great, I gave the user an extra hour.
But... if you had done the right thing from the start, for the first 
80%, you'd have given the user 5 hours of extra battery!
Or in other words... the amount of savings in the last 20% is not going 
to be very much, because there's just not much left you're going to 
do a %age improvement over an already small number



___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[Patrick Ohly]

On Wed, 2010-06-23 at 11:35 +0100, ronan.maclave...@nokia.com wrote:
> Do the DBus bindings for Qt (QDbus) work on MeeGo?  It has some nice
> features like an interface compiler (qdbusxml2cpp).

That depends on the content of the XML interface definition and how it
is installed. 

How we do it in SyncEvolution is:
  * .xml files go into /usr/share/dbus-1/interfaces/ as part of the
development package.
  * These files need 
elements for the more complex types.
  * dbus-binding-tool for glib-dbus does not like annotations in
 specifications, so we filter out the annotations when
building the GTK sync-ui.

But I'm far from being an expert on this. I don't know whether all
projects with D-Bus interfaces already have the necessary QDBus
annotations.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Gary Birkett]

On Tue, Jun 22, 2010 at 6:08 PM, Arjan van de Ven  wrote:
> On 6/22/2010 4:15 AM, Dave Neary wrote:
>>
>> Hi,
>>
>> Arjan van de Ven wrote:
>>
>>>
>>> On 6/21/2010 1:27 PM, Narendranath Ghosh wrote:
>>>

 Is there any power management architecture doc available for user
 domain?

>>>
>>> Applications need to be well behaved. not wake up the cpu unneeded,
>>> not keeping resources busy etc etc
>>> (see various presentations that I and others did in the past on this
>>> topic)
>>>
>>
>> So, in summary, no?
>>
>
>
> correct. there are, by design, no special APIs in MeeGo for applications to
> be power friendly.
> It must be sufficient for an application to be well behaving [*] for it to
> be power friendly in MeeGo.


would it be wise to document all the best practices in one place though?
also for applications to be well behaved, they should know something
about their environment
to that end should know where to look for the charging status for instance
if the devices have a power profile available, the api to access this
should be documented and clearly stated
I believe that sort of information is what Narendranath Ghosh was requesting.

correct me if I am wrong.

BR

Gary

>
>
>
> [*] so no frequent polling, closing devices it's not using etc; the stuff
> that we've been educating everyone
> on for the last few years, and that most open source software took to heart.
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Power Managemengards

[Narendranath Ghosh]

Hi,

three things coming to my mind.

1. we cant guarantee that third party application development will be
well behaved.

2. two things, in power saving, saving power when no use (no eating)

3. saving power by consuming less ( less eating)

Does meego have some kind of similar architecture?

Regards,
-Naren

On Tue, Jun 22, 2010 at 9:08 PM, Arjan van de Ven  wrote:
> On 6/22/2010 4:15 AM, Dave Neary wrote:
>>
>> Hi,
>>
>> Arjan van de Ven wrote:
>>
>>>
>>> On 6/21/2010 1:27 PM, Narendranath Ghosh wrote:
>>>

 Is there any power management architecture doc available for user
 domain?

>>>
>>> Applications need to be well behaved. not wake up the cpu unneeded,
>>> not keeping resources busy etc etc
>>> (see various presentations that I and others did in the past on this
>>> topic)
>>>
>>
>> So, in summary, no?
>>
>
>
> correct. there are, by design, no special APIs in MeeGo for applications to
> be power friendly.
> It must be sufficient for an application to be well behaving [*] for it to
> be power friendly in MeeGo.
>
>
>
> [*] so no frequent polling, closing devices it's not using etc; the stuff
> that we've been educating everyone
> on for the last few years, and that most open source software took to heart.
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] multimedia architecture

[Narendranath Ghosh]

Thomas I agree with you.

Still few Qs.

1. Is there any architectural diagram of Meego multimedia framework
(which includes HW and SW)

2. I dont know about QT multimedia APIs, is it sufficient? I mean
doest it includes all the APIs to support ALL the HW and SW
functinality of multimedia?

3. I feel its NOT, then is there any APIs or framework meego exposes
to user? (advance or simple)

4. Different HW has different multimedia architecture, some HW may
support lots of codec in HW accelator or some HW has less.
Some codes can be in HW and some in SW, so meego has any demand or
requirement for multimedia or codecs?

5. Any codes can be added later, right?

6. Any power management guideline for Multimedia Framework or any
links between power policy with multimedia framwork?

7. Any component for audio routing? At least it needed in Phone HW.

8. When I am porting ("adding support") QT to some HW platform, is
there any issues to consider or its totally independent of HW platform

9. what about USB camera or any extranl video source. Support for this
is available in meego?

Thanks
-Naren

On Wed, Jun 23, 2010 at 11:09 AM, David Greaves  wrote:
> On 22/06/10 16:32, Tomas Frydrych wrote:
>>
>> This is entirely irrelevant; MeeGo *is* Linux, and we are not discussing
>> Qt architecture here, but MeeGo architecture. Ultimately the MeeGo
>> architecture must make engineering sense in itself, and should not be
>> restricted by the limitations that Qt is imposing on itself in its
>> strive to be a cross-platform toolkit. Qt should be a means to an end on
>> MeeGo, not the end itself.
>
> "Invert" that thinking.
>
> Using cross-platform Qt eases non-linux developers into developing for
> MeeGo.
>
> David
>
> --
> "Don't worry, you'll be fine; I saw it work in a cartoon once..."
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Qt Mobility says "Hello MeeGo World!"

[gerard.loughran]

Hi Guys,
Firstly thank you all for such a warm welcome.
A couple of people have asked that I draft a blog here on meego.com and im 
happy to facilitate.
So I hope that we can set that up in the next few days.
In the interim, I believe Min has answered most questions and for others that 
may be remaining, I hope that we can address those in the blog post here on 
Meego.com

Kind regards,
Gerard.




>-Original Message-
>From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com]
>On Behalf Of Shin Minjung (Nokia-D-Qt/Brisbane)
>Sent: Wednesday, June 23, 2010 11:09 AM
>To: meego-dev@meego.com
>Subject: Re: [MeeGo-dev] Qt Mobility says "Hello MeeGo World!"
>
>Hi Dave,
>
>I can access it now. Thanks you.
>
>Regards,
>Min
>
>-Original Message-
>From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com]
>On Behalf Of ext Dave Neary
>Sent: Tuesday, 22 June 2010 9:25 PM
>To: Development for the MeeGo Project
>Subject: Re: [MeeGo-dev] Qt Mobility says "Hello MeeGo World!"
>
>Hi Min,
>
>minjung.s...@nokia.com wrote:
>> It seems http://bug.meego.com is down at the moment...
>
>Did you try http://bugs.meego.com?
>
>Google finds this page with "MeeGo bug tracker":
>http://meego.com/community/bug-tracking
>
>There is a bug about Google indexing of bugs.meego.com open, which will
>perhaps make Bugzilla easier to find when it's fixed:
>http://bugs.meego.com/show_bug.cgi?id=1967
>
>Cheers,
>Dave.
>
>--
>maemo.org docsmaster
>Email: dne...@maemo.org
>Jabber: bo...@jabber.org
>
>___
>MeeGo-dev mailing list
>MeeGo-dev@meego.com
>http://lists.meego.com/listinfo/meego-dev
>___
>MeeGo-dev mailing list
>MeeGo-dev@meego.com
>http://lists.meego.com/listinfo/meego-dev
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[ronan.maclaverty]

Do the DBus bindings for Qt (QDbus) work on MeeGo?  It has some nice features 
like an interface compiler (qdbusxml2cpp). 

>-Original Message-
>From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com]
>On Behalf Of ext Narendranath Ghosh
>Sent: 23 June, 2010 13:32
>To: Development for the MeeGo Project
>Subject: Re: [MeeGo-dev] DBus tutorials
>
>Hi Elliot,
>
>Nice tuto.
>
>Which component in the user side handles USB Hardware (attach & detach
>notification) using D-BUS?
>
>Regards,
>-Naren
>
>On Wed, Jun 23, 2010 at 1:25 PM, Elliot Smith 
>wrote:
>> I've migrated a couple of tutorials from the old Moblin site to the
>> MeeGo wiki. These give a brief introduction to D-Bus and some
>> information about the ConnMan D-Bus API, and may be of use to MeeGo
>> platform developers. Of course, if anyone wants to add details about
>> Qt's D-Bus support (or appropriate links), that would be good too.
>>
>> http://wiki.meego.com/D-Bus/
>>
>> Elliot
>> --
>> Elliot Smith
>> Intel Open Source Technology Centre
>>
>> -
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>> ___
>> MeeGo-dev mailing list
>> MeeGo-dev@meego.com
>> http://lists.meego.com/listinfo/meego-dev
>>
>___
>MeeGo-dev mailing list
>MeeGo-dev@meego.com
>http://lists.meego.com/listinfo/meego-dev
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[Narendranath Ghosh]

Hi Elliot,

Nice tuto.

Which component in the user side handles USB Hardware (attach & detach
notification) using D-BUS?

Regards,
-Naren

On Wed, Jun 23, 2010 at 1:25 PM, Elliot Smith  wrote:
> I've migrated a couple of tutorials from the old Moblin site to the
> MeeGo wiki. These give a brief introduction to D-Bus and some
> information about the ConnMan D-Bus API, and may be of use to MeeGo
> platform developers. Of course, if anyone wants to add details about
> Qt's D-Bus support (or appropriate links), that would be good too.
>
> http://wiki.meego.com/D-Bus/
>
> Elliot
> --
> Elliot Smith
> Intel Open Source Technology Centre
>
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] DBus tutorials

[Elliot Smith]

On Wed, 2010-06-23 at 11:25 +0100, Elliot Smith wrote:
> I've migrated a couple of tutorials from the old Moblin site to the
> MeeGo wiki. These give a brief introduction to D-Bus and some
> information about the ConnMan D-Bus API, and may be of use to MeeGo
> platform developers. Of course, if anyone wants to add details about
> Qt's D-Bus support (or appropriate links), that would be good too.
> 
> http://wiki.meego.com/D-Bus/

Of course, that link should be minus the trailing slash:

http://wiki.meego.com/D-Bus

Elliot
-- 
Elliot Smith
Intel Open Source Technology Centre

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[王国宁]

:)
what are you doing?

2010/6/23 Jeffrey Cheung 

> Poor Eric Wang,
>
> Be a QT developer now ?
>
> regards,
>
> Jeffrey
>
> >>> 王国宁 6/23/2010 5:47 PM >>>
> Another question hasn't be answered: * X, QT is must, right? *
> If I want to develop a application for MeeGo,  am I use the QT to develop
> the UI?
>
> Thanks.
>
> BR
>
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

[MeeGo-dev] DBus tutorials

[Elliot Smith]

I've migrated a couple of tutorials from the old Moblin site to the
MeeGo wiki. These give a brief introduction to D-Bus and some
information about the ConnMan D-Bus API, and may be of use to MeeGo
platform developers. Of course, if anyone wants to add details about
Qt's D-Bus support (or appropriate links), that would be good too.

http://wiki.meego.com/D-Bus/

Elliot
-- 
Elliot Smith
Intel Open Source Technology Centre

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[Jeffrey Cheung]

Poor Eric Wang,

Be a QT developer now ?

regards,

Jeffrey
 
>>> 王国宁 6/23/2010 5:47 PM >>> 
Another question hasn't be answered: * X, QT is must, right? *
If I want to develop a application for MeeGo,  am I use the QT to develop
the UI?

Thanks.

BR

___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[ronan.maclaverty]

Hi,
That is the recommended approach.

The MeeGo Qt SDK is due to come out soon, in the meantime you can use the Nokia 
Qt SDK available from 
http://www.forum.nokia.com/info/sw.nokia.com/id/e920da1a-5b18-42df-82c3-907413e525fb/Nokia_Qt_SDK.html
  to get started.  It is planned so that a lot of the cool features in the 
Nokia Qt SDK will make their way to the MeeGo Qt SDK (on device debugging etc.).

Ronan.

From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On 
Behalf Of ext ???
Sent: 23 June, 2010 12:48
To: Development for the MeeGo Project
Subject: Re: [MeeGo-dev] ARM + Meego?

Another question hasn't be answered: X, QT is must, right?
If I want to develop a application for MeeGo,  am I use the QT to develop the 
UI?

Thanks.

BR
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[王国宁]

Another question hasn't be answered: * X, QT is must, right? *
If I want to develop a application for MeeGo,  am I use the QT to develop
the UI?

Thanks.

BR
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] error in image creation

[Praveen Swaroop]

Hi:

I used the below mentioned .ks files but still images are not created
This is what I get :-


r...@infba01964:/home/user/image-creator# sudo mic-image-creator --config=NEW\ 
KS/n900.ks --format=raw --cache=mycache --arch=armv7
[main]
use_comps=1
no_proxy=localhost,127.0.0.0/8,172.0.0.0/8,10.0.0.0/8,192.0.0.0/8
default_ks=default.ks
cachedir=/var/tmp/cache
distro_name=MeeGo
image_format=raw
tmpdir=/var/tmp
outdir=.



Geting repomd.xml from repo MeeGo-1.0-Core-official...
Getting primary.sqlite from repo MeeGo-1.0-Core-official...
Getting patterns 
repodata/fe5060bbedc0f46ee5ae483ac56d932a8b2d4c80b363c20f220d32789d39f4be-patterns.xml.gz
 from repo MeeGo-1.0-Core-official...
Getting comps 
repodata/8307949a000b361c877273cbb4037c304094f902b9435927f9fafbeaff8fb422-comps.xml.gz
 from repo MeeGo-1.0-Core-official...
[u'armv7l']
MeeGo release 1.0
Target arch: armv7l
Loading dm_snapshot...
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
106848 inodes, 427246 blocks
4272 blocks (1.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=440401920
14 block groups
32768 blocks per group, 32768 fragments per group
7632 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 21 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
tune2fs 1.41.9 (22-Aug-2009)
Setting maximal mount count to -1
Setting interval between checks to 0 seconds
Traceback (most recent call last):
  File "/usr/local/bin/mic-image-creator", line 582, in 
ret = main()
  File "/usr/local/bin/mic-image-creator", line 549, in main
creator.install()
  File "/usr/lib/python2.6/dist-packages/mic/imgcreate/creator.py", line 745, 
in install
ayum = LiveCDYum(self._recording_pkgs, target_arch = self.target_arch)
  File "/usr/lib/python2.6/dist-packages/mic/imgcreate/yuminst.py", line 50, in 
__init__
self.arch.setup_arch(target_arch)
AttributeError: 'LiveCDYum' object has no attribute 'arch'





Thanks.
Regards,
Praveen Swaroop Dash
Mob : 9916490742
Email : praveen.swar...@lntinfotech.com

From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of 
Carsten Munk [cars...@maemo.org]
Sent: Tuesday, June 22, 2010 5:52 PM
To: Development for the MeeGo Project
Subject: Re: [MeeGo-dev] error in image creation

2010/6/22 Puneet Jain :
> Hi all,
> I am getting errors during image creation.Can anyone share .ks file for 
> armv7l architecture.
>
> Thanks & Regards,
> Puneet Jain

http://repo.meego.com/MeeGo/releases/1.0/core/images/meego-n900-open-armv7l/meego-n900-open-armv7l-1.0.0.20100525.1.ks
for 1.0

http://repo.meego.com/MeeGo/builds/trunk/1.0.80.7.20100618.1/core/images/meego-core-armv7l-n900/meego-core-armv7l-n900-1.0.80.7.20100618.1.ks
for latest weekly image
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

__

This Email may contain confidential or privileged information for the intended 
recipient (s) If you are not the intended recipient, please do not use or 
disseminate the information, notify the sender and delete it from your system.

__
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] Media Framework

[rglujing]

>On 6/22/2010 8:50 PM, rglujing wrote: >> Hi, all >> I want to know whether the 
>camera based on V4l2 or libCI in future? I  >> know moblin used libci. >> Now 
>i want to develop gstreamer plugin like v4l2src for demo usage, Is  >> that 
>necessary? > > >moblin never used libci; some private branches of it may have 
>come with  >libci. > > >In MeeGo we strongly recommend using gstreamer for the 
>camera; for many  >cases this will be plugged to v4l2, >but there are cases 
>where v4l2 is a bit limiting in terms of API... and  >hardware vendors may 
>plug directly into gstreamer. > >

Thank you for your reply. 
In fact I want to know the video interface support by kernel. Can you give me 
some advice?
And no matter v4l2 or libci, they can be wrapped to a gstreamer plugin (v4l2 or 
mrstcamsrc).
Thanks
Omego
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] multimedia architecture

[David Greaves]

On 22/06/10 16:32, Tomas Frydrych wrote:

This is entirely irrelevant; MeeGo *is* Linux, and we are not discussing
Qt architecture here, but MeeGo architecture. Ultimately the MeeGo
architecture must make engineering sense in itself, and should not be
restricted by the limitations that Qt is imposing on itself in its
strive to be a cross-platform toolkit. Qt should be a means to an end on
MeeGo, not the end itself.


"Invert" that thinking.

Using cross-platform Qt eases non-linux developers into developing for MeeGo.

David

--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[si jiangping]

thanks for Carston's reply, it is very details to me. thanks again. --tom

On Wed, Jun 23, 2010 at 3:11 PM, Carsten Munk  wrote:

> 2010/6/23 si jiangping :
> > thanks for your feedback.
> > but not all of ARM5/7 CPU could run QT, right?  so how to name them with
> > Meego?
> >
>
> A Nokia N8x0 (OMAP2420, ARMv6+VFP) runs Qt and Qt is built for ARMv5..
> Even an ARMv4t Freerunner ran Qt (but won't run MeeGo)
>
> Also, keep close notice to the 'v' part. ARM5/7 means something different.
>
> http://en.wikipedia.org/wiki/ARM_architecture , check out
> 'architecture version'. You'll want either ARMv5TEJ, ARMv5TE with MMU,
> ARMv6*, or ARMv7*
>
> Best regards,
> Carsten Munk
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] please give the sollution

[jamilireddy obulareddy]

Hi Carsten Munk,

Which component is used for development of alarm application in Meego.

Thanks & Regards,
Jamili Reddy.

On Wed, Jun 23, 2010 at 12:26 PM, Carsten Munk  wrote:

> 2010/6/23 Sanjay Gupta :
> > Hi Carsten Munk,
> > I am also facing similar problem.
> > is there any plan going forward to open up the source code for this
> libtime
> > library which is currently available as binary provided by Nokia?
> > Please let me know if you have any information on it?
>
> Again, quite off topic for here. But
> https://bugs.maemo.org/show_bug.cgi?id=4560 states this is a WONTFIX.
>
> If you don't mind, can I ask why you're bothering to adapt Fremantle
> (43% open packages)?
>
> It would be a better use of your time to port MeeGo (100% open source,
> minus the artwork which is serving the compliance program) and it's
> UX(es) and more future proof.
>
> Best regards,
> Carsten Munk
> maemo.org distmastr
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>



-- 
ఓ.జమిలిరెడ్డి
సాఫ్ట్వేర్ఇంజనీర్
మోటోరోల ఇంక్
హైదరాబాద్
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[Thiago Macieira]

Em Quarta-feira 23. Junho 2010, às 09.03.51, si jiangping escreveu:
> thanks for your feedback.
> but not all of ARM5/7 CPU could run QT, right?  so how to name them with
> Meego?

Like Carsten said, you meant ARMv5 and ARMv7. Be careful, because ARM11 is an 
ARMv6.

Anyway, the instruction set is not the issue here. Qt can be compiled for many 
architectures, including ARMv5 and v6 (v7 uses the v6 atomics, but we're going 
to add a new set of atomics).

What you need to look into is the ability of the rest of the system to run the 
applications you have. A full Linux system, running a full glibc (not uclibc 
or newlib) and a full Qt will have stricter requirements than other systems.

And also note that MeeGo will require OpenGL ES 2 in the handset UX, so you 
should get an ARM system that has a good video device and driver.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] please give the sollution

[Sanjay Gupta]

Hi Carsten,
Thanks for the suggestion. I was interested to understand the source code of
component used for managing the alarms in the MeeGo, but did not find any
component for it in MeeGo repository.
That's why I was looking into alarmd code in Fremantle but got stuck at this
libtime closed source code.

Do you have any idea if there is any component already available for this
purpose in MeeGo which is completely open source? Please suggest.

Thanks & Regards,
Sanjay

On Wed, Jun 23, 2010 at 12:26 PM, Carsten Munk  wrote:

> 2010/6/23 Sanjay Gupta :
> > Hi Carsten Munk,
> > I am also facing similar problem.
> > is there any plan going forward to open up the source code for this
> libtime
> > library which is currently available as binary provided by Nokia?
> > Please let me know if you have any information on it?
>
> Again, quite off topic for here. But
> https://bugs.maemo.org/show_bug.cgi?id=4560 states this is a WONTFIX.
>
> If you don't mind, can I ask why you're bothering to adapt Fremantle
> (43% open packages)?
>
> It would be a better use of your time to port MeeGo (100% open source,
> minus the artwork which is serving the compliance program) and it's
> UX(es) and more future proof.
>
> Best regards,
> Carsten Munk
> maemo.org distmastr
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[Carsten Munk]

2010/6/23 si jiangping :
> thanks for your feedback.
> but not all of ARM5/7 CPU could run QT, right?  so how to name them with
> Meego?
>

A Nokia N8x0 (OMAP2420, ARMv6+VFP) runs Qt and Qt is built for ARMv5..
Even an ARMv4t Freerunner ran Qt (but won't run MeeGo)

Also, keep close notice to the 'v' part. ARM5/7 means something different.

http://en.wikipedia.org/wiki/ARM_architecture , check out
'architecture version'. You'll want either ARMv5TEJ, ARMv5TE with MMU,
ARMv6*, or ARMv7*

Best regards,
Carsten Munk
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev

Re: [MeeGo-dev] ARM + Meego?

[si jiangping]

thanks for your feedback.
but not all of ARM5/7 CPU could run QT, right?  so how to name them with
Meego?

thanks again.
Tom

On Wed, Jun 23, 2010 at 1:46 PM, Carsten Munk  wrote:

> 2010/6/23 si jiangping :
> > hi Meegos,
> > could you give me any information about which ARM chips support or will
> > support Meego？
> >
> > As I know, Nokia's N9 is A8 chip, how about others?
> >
> > BTW, one more question is: which kind of ARM CPU could support Meego? X,
> QT
> > is must, right?
>
> MeeGo currently builds towards ARMv5 and ARMv7. This means ARMv6 can
> use ARMv5 and ARMv7 can use ARMv5 and ARMv7.
>
> A N900 is ARMv7, for reference.
>
> Best regards,
> Carsten Mun
> ___
> MeeGo-dev mailing list
> MeeGo-dev@meego.com
> http://lists.meego.com/listinfo/meego-dev
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev