5. Re: Say Goodbye to GTK, Will Meego open to what extent? More
than Android or Less than? (Auke Kok)
Actually Android is not just Java Machine,
Android applications have own life cycle, android java machine(Dalvik)
has own api.
And if Meego says that it will support android application it should
be mean that you need only to repackage an application without any
modifications in source files.
How can answer? Will Meego support Android App?
2010/3/31, [email protected] <[email protected]>:
> Send MeeGo-dev mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.meego.com/listinfo/meego-dev
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MeeGo-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Bootchart2 / bootchart duplication ... (Auke Kok)
> 2. Re: Bootchart2 / bootchart duplication ... (Auke Kok)
> 3. Re: How to get screen active application in Meego
> (Robison, Clayne B)
> 4. Re: Bootchart2 / bootchart duplication ... (Greg KH)
> 5. Re: Say Goodbye to GTK, Will Meego open to what extent? More
> than Android or Less than? (Auke Kok)
> 6. Re: Bootchart2 / bootchart duplication ... (Auke Kok)
> 7. Re: USBFS Bug (Linux Kernel >=2.6.32.9 <=2.6.33) (Greg KH)
> 8. Re: Bootchart2 / bootchart duplication ... (Greg KH)
> 9. Re: 3G support (Marcel Holtmann)
> 10. Re: Bootchart2 / bootchart duplication ... (David Greaves)
> 11. Re: Bootchart2 / bootchart duplication ... (Auke Kok)
> 12. GConf API Usage issue (Zhang, Qiang Z)
> 13. Re: GConf API Usage issue (Roger WANG)
> 14. Re: On device help framework ([email protected])
> 15. Re: GConf API Usage issue (Damien Lespiau)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 30 Mar 2010 10:29:27 -0700
> From: Auke Kok <[email protected]>
> To: "[email protected]" <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] Bootchart2 / bootchart duplication ...
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/30/10 04:10, Michael Meeks wrote:
>>
>> On Tue, 2010-03-30 at 11:52 +0100, Jamie Bennett wrote:
>>> It would be interesting to hear Auke Kok's reasoning behind choosing
>>> to re-implement rather than take an already existing solution.
>>
>> FWIW - my personal take is that Auke is sufficiently sharp, that it is
>> actually rather easier and quicker for him to re-write than work with an
>> existing code-base.
>>
>> It is almost always more work to re-use than re-implement, in this case
>> I had to learn some python to get the best bootchart pieces pulled
>> together :-) that took me a little time. Intel's bootchart is very
>> small, pure C, has no dependencies etc. There are plenty of
>> semi-technical arguments you can make in it's favour.
>
> That sums it up a bit.
>
> There were several issues, and most were rather trivial for me to solve
> by going to a single C-based implementation:
>
> - we can graph SVG data without any libraries (Python, Java etc), which
> makes this usable in any deployment
> - everything can read SVG (browsers)
> - we can frob <!-- comments --> in SVG putting more numerical
> information if we want (flexibility).
>
> As for the logger rewrite: it didn't make much sense to me to write out
> several megabytes to a slow SSD, then re-read it all again to graph. The
> obvious conclusion was to log in memory, and graph from there. This
> solves several issues (no need to use tmpfs, buffered files etc).
>
> So, altogether this was worth it for us to do.
>
> What I did before I wrote this version:
>
> 1) hack pybootchartgui to include all sorts of display options I was missing
> 2) rewrite the logger in C
> 3) re-use the ubuntu logger written in C
>
> Then I got stuck on the "glue logger and grapher into one program
> without java/python" idea, which seemed ideal for embedded/small
> platforms, and ultimately started from scratch.
>
> Auke
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 30 Mar 2010 11:01:18 -0700
> From: Auke Kok <[email protected]>
> To: David Greaves <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] Bootchart2 / bootchart duplication ...
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/30/10 03:43, David Greaves wrote:
>> Michael Meeks wrote:
>>> My views on this sort of Intel internal re-writing are well known.
>>> There is a good way to do this: work with the existing guys on the
>>> various bootchart projects out there, and try to draw them together.
>>> That is the approach I took with bootchart2. It is also far, far less
>>> wasteful of the scarce resources that we (collectively) have today to
>>> work on tooling.
>> +1
>>
>>> There is a good way to do software development in community; and IMNSHO
>>> it doesn't look like this. We don't need yet-another bootchart
>>> project[2] there are currently a handful (now +1).
>> +1
>>
>>
>> Auke - I would suggest that you lead by example and make a conscious
>> effort to
>> say "NIH is not acceptable. We now know of external tools that are
>> functionally
>> equivalent to internal tools. We will drop the internal tool and work with
>> the
>> wider community."
>
> Nonsense :)
>
> Innovation comes from looking at an old good idea, and making a newer
> and shinier implementation of it - not from shooting down good ideas
> just because someone has already invented it...
>
> Auke
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 30 Mar 2010 11:23:06 -0700
> From: "Robison, Clayne B" <[email protected]>
> To: "Zhang, Xing Z" <[email protected]>, Chris Pearson
> <[email protected]>, "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] How to get screen active application in Meego
> Message-ID:
>
> <b27ebc40d200ed48a3f4cc2ebeabae0b254f063...@orsmsx501.amr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Agreed. (Although one could argue that in a matchbox-style window manager,
> an app doesn't really need to rotate (i.e. receive accelerometer events)
> until it comes into the foreground.)
>
> Clayne
> -----Original Message-----
> From: Zhang, Xing Z
> Sent: Monday, March 29, 2010 6:42 PM
> To: Robison, Clayne B; Chris Pearson; [email protected]
> Subject: RE: [MeeGo-dev] How to get screen active application in Meego
>
> This rule could not apply to all applications. For example, an application
> may
> run in background to detect window rotation event, it requires data in its
> life-cycle.
> For this kind application, there should be an interface to get over power
> policy.
>
>
>> -----Original Message-----
>> From: Robison, Clayne B
>> Sent: Tuesday, March 30, 2010 2:35 AM
>> To: Zhang, Xing Z; Chris Pearson; [email protected]
>> Subject: RE: [MeeGo-dev] How to get screen active application in Meego
>>
>> I think the default should be "stop retrieving data when the app is in the
>> background". An app should have to take the extra step if it is going to
>> drain
>> the battery.
>>
>> Clayne
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Zhang, Xing Z
>> Sent: Sunday, March 28, 2010 6:29 PM
>> To: Chris Pearson; [email protected]
>> Subject: Re: [MeeGo-dev] How to get screen active application in Meego
>>
>> Yes. Your concern is right.
>> Actually here would be API to application sets "don't apply power
>> management
>> policy
>> to me".
>> For these who don't set such flag, daemon will stop polling data for them.
>> There already API for application stop polling when it wants. But I don't
>> expect
>> application will be designed to power awareness, for example, stop
>> requiring
>> data when switched to background. So I have to do as much as I can in my
>> daemon
>> and library.
>> However, one thing will be guarantee, that daemon will not decide
>> application's
>> behavior
>> or force application do something.
>>
>> > -----Original Message-----
>> > From: Chris Pearson [mailto:[email protected]]
>> > Sent: Monday, March 29, 2010 3:14 AM
>> > To: Zhang, Xing Z; Jussi Kukkonen; [email protected]
>> > Subject: Re: [MeeGo-dev] How to get screen active application in Meego
>> >
>> > Hi Xing,
>> >
>> > Are you sure that all applications for your daemon would want polling to
>> > stop when they are in the background? Can we not imagine an application
>> > that runs in background (e.g., as an icon) and displays a pop-up message
>> > when some sensor event is detected? If so, instead of the daemon
>> > deciding
>> > how all application(s) must behave, why not allow each application to
>> > tell
>> > the daemon when to stop polling (or what polling rate is required)?
>> > This
>> > seems possible since there is already a connection between the
>> > application
>> > and the daemon.
>> >
>> > -- Chris
>> >
>> > ----- Original Message -----
>> > From: "Zhang, Xing Z" <[email protected]>
>> > To: "Jussi Kukkonen" <[email protected]>; <[email protected]>
>> > Sent: Saturday, March 27, 2010 3:40 AM
>> > Subject: Re: [MeeGo-dev] How to get screen active application in Meego
>> >
>> >
>> > > My application is a sensor daemon supplying data to application, e.g.
>> > > accelerometer data.
>> > > If an application connects to my daemon, the daemon will poll driver
>> > > in a
>> > > high sample rate which obviously kills power.
>> > > so if I could know which application is viewable to user, I could stop
>> > > polling since sensor awareness application is running at background
>> > > My thought is to write a context provider of window manager to provide
>> > > such feature.
>> > >
>> > > Thank you your suggestion. I will take a look of Libwnck first.
>> > >
>> > >> -----Original Message-----
>> > >> From: [email protected]
>> > >> [mailto:[email protected]] On Behalf Of Jussi Kukkonen
>> > >> Sent: Friday, March 26, 2010 5:00 PM
>> > >> To: [email protected]
>> > >> Subject: Re: [MeeGo-dev] How to get screen active application in
>> > >> Meego
>> > >>
>> > >> Zhang, Xing Z wrote:
>> > >> > Hi all: Do we have method to get known which application is active
>> > >> > on
>> > >> > screen now? I filter properties of contextkit, Session.State makes
>> > >> > sense to me. Is there a more detailed info tells me which
>> > >> > application
>> > >> > is in fullscreen mode (by pid or others)?
>> > >>
>> > >> Libwnck may be worth a look, but I don't know if it's available in
>> > >> all
>> > >> versions... If you explain what you want to achieve (and in what
>> > >> context), you might get better suggestions.
>> > >>
>> > >>
>> > >> HTH,
>> > >> Jussi
>> > >> _______________________________________________
>> > >> MeeGo-dev mailing list
>> > >> [email protected]
>> > >> http://lists.meego.com/listinfo/meego-dev
>> > > _______________________________________________
>> > > MeeGo-dev mailing list
>> > > [email protected]
>> > > http://lists.meego.com/listinfo/meego-dev
>>
>> _______________________________________________
>> MeeGo-dev mailing list
>> [email protected]
>> http://lists.meego.com/listinfo/meego-dev
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 30 Mar 2010 11:32:39 -0700
> From: Greg KH <[email protected]>
> To: "Maloney, Gerard" <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] Bootchart2 / bootchart duplication ...
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Mar 30, 2010 at 11:51:26AM +0100, Maloney, Gerard wrote:
>> As for enabling CONFIG_TASKSTATS=y people can rebuild there kernel as
>> needed,
>> for the analysis phase and use the default kernel when deployed.
>
> That usually doesn't work so well when we are wanting to see user charts
> on their own hardware to determine where the boot problems are. You
> can't ask a user to rebuild their kernel very easily :)
>
> Are there known issues that CONFIG_TASKSTATS has that keeps it from
> being enabled in the main meego kernel?
>
> thanks,
>
> greg k-h
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 30 Mar 2010 11:33:39 -0700
> From: Auke Kok <[email protected]>
> To: frederico schardong <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] Say Goodbye to GTK, Will Meego open to what
> extent? More than Android or Less than?
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 03/30/10 05:06, frederico schardong wrote:
>>> Frankly speaking, Maemo&Moblin let me down. I love X window system, but
>>> GTK
>>> is ugly, it is an anti--human toolkit?difficult to maintain, hard to
>>> understand.
>>
>> Ugly? hard to understand? Are you a developer? Anti--human toolkit?
>> GTK+ is very simple and complete, and everything is completely
>> documented, without forgetting that GTK+ is lighter than Qt...
>
> Not to mention that MeeGo will fully support Gtk+ going forward, and
> most likely come with several, if not many, Gtk+-based applications for
> e.g. netbooks etc.
>
> Auke
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 30 Mar 2010 11:39:20 -0700
> From: Auke Kok <[email protected]>
> To: Greg KH <[email protected]>
> Cc: "[email protected]" <[email protected]>, "Van De Ven, Arjan"
> <[email protected]>
> Subject: Re: [MeeGo-dev] Bootchart2 / bootchart duplication ...
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/30/10 11:32, Greg KH wrote:
>> On Tue, Mar 30, 2010 at 11:51:26AM +0100, Maloney, Gerard wrote:
>>> As for enabling CONFIG_TASKSTATS=y people can rebuild there kernel as
>>> needed,
>>> for the analysis phase and use the default kernel when deployed.
>>
>> That usually doesn't work so well when we are wanting to see user charts
>> on their own hardware to determine where the boot problems are. You
>> can't ask a user to rebuild their kernel very easily :)
>
> and it's what we want: users making their own bootcharts if needed, with
> little knowledge of the system...
>
>> Are there known issues that CONFIG_TASKSTATS has that keeps it from
>> being enabled in the main meego kernel?
>
> I actually don't know, but other than the small overhead, I can't think
> if a reason why this would negatively impact anything.
>
> Auke
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 30 Mar 2010 12:25:29 -0700
> From: Greg KH <[email protected]>
> To: Markus Rechberger <[email protected]>
> Cc: [email protected]
> Subject: Re: [MeeGo-dev] USBFS Bug (Linux Kernel >=2.6.32.9 <=2.6.33)
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Mar 30, 2010 at 11:02:14AM +0200, Markus Rechberger wrote:
>> Hi,
>>
>> one of our customers is trying to use an isochronous device with
>> USBFS, he told us that he's using 2.6.33
>> Unfortunately a bug slipped in into the USBFS implementation between
>> >=2.6.32.9 and <=2.6.33.1 which breaks isochronous USB.
>>
>> Can someone backport/apply the proposed patch:
>> http://lkml.org/lkml/2010/2/26/490 (Report)
>> http://lkml.org/lkml/2010/2/27/226 (Bugfix)
>
> Apply it to what? There is no public meego kernel yet :(
>
> The patch will be in the next .33-y kernel release, in a few days.
>
> thanks,
>
> greg k-h
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 30 Mar 2010 12:26:25 -0700
> From: Greg KH <[email protected]>
> To: Auke Kok <[email protected]>
> Cc: "[email protected]" <[email protected]>, "Van De Ven, Arjan"
> <[email protected]>
> Subject: Re: [MeeGo-dev] Bootchart2 / bootchart duplication ...
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Mar 30, 2010 at 11:39:20AM -0700, Auke Kok wrote:
>> On 03/30/10 11:32, Greg KH wrote:
>>> On Tue, Mar 30, 2010 at 11:51:26AM +0100, Maloney, Gerard wrote:
>>>> As for enabling CONFIG_TASKSTATS=y people can rebuild there kernel as
>>>> needed,
>>>> for the analysis phase and use the default kernel when deployed.
>>>
>>> That usually doesn't work so well when we are wanting to see user charts
>>> on their own hardware to determine where the boot problems are. You
>>> can't ask a user to rebuild their kernel very easily :)
>>
>> and it's what we want: users making their own bootcharts if needed, with
>> little knowledge of the system...
>>
>>> Are there known issues that CONFIG_TASKSTATS has that keeps it from
>>> being enabled in the main meego kernel?
>>
>> I actually don't know, but other than the small overhead, I can't think if
>>
>> a reason why this would negatively impact anything.
>
> Great, can you please enable it in your kernel package then?
>
> thanks,
>
> greg k-h
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 30 Mar 2010 12:48:30 -0700
> From: Marcel Holtmann <[email protected]>
> To: Leonardo Luiz Padovani da Mata <[email protected]>
> Cc: [email protected]
> Subject: Re: [MeeGo-dev] 3G support
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Leonardo,
>
>> > within MeeGo we are using oFono as telephony stack. Besides 3G based
>> > Internet connections this also has support for voice calls (if the
>> > hardware supports its), SMS, USSD etc. Depending on the hardware this
>> > might be already fully integrated with ConnMan and the user interface.
>> >
>> > Work for the PPP based 3G dongles and devices is work in progress and we
>> > merged initial support for it. For further details use the mailing list
>> > of the oFono project or join #ofono IRC channel. Any help is more than
>> > welcome.
>> >
>>
>> Do you have any idea about the integration with Conman Network manager?
>
> for ConnMan we have a generic oFono plugin that is already integrated
> and ready to work. We have tested it with Ericsson MBM and Option HSO
> hardware so far.
>
> As I said, PPP support in the making, but that is purely inside oFono
> and ConnMan will not see the difference. The generic oFono plugin will
> take care of it. Check the doc/dataconnectionmanager-api.txt inside the
> oFono source code.
>
> Regards
>
> Marcel
>
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 30 Mar 2010 20:56:41 +0100
> From: David Greaves <[email protected]>
> To: Auke Kok <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] Bootchart2 / bootchart duplication ...
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Auke Kok wrote:
>> On 03/30/10 03:43, David Greaves wrote:
>>> Michael Meeks wrote:
>>>> My views on this sort of Intel internal re-writing are well known.
>>>> There is a good way to do this: work with the existing guys on the
>>>> various bootchart projects out there, and try to draw them together.
>>>> That is the approach I took with bootchart2. It is also far, far less
>>>> wasteful of the scarce resources that we (collectively) have today to
>>>> work on tooling.
>>> +1
>>>
>>>> There is a good way to do software development in community; and
>>>> IMNSHO
>>>> it doesn't look like this. We don't need yet-another bootchart
>>>> project[2] there are currently a handful (now +1).
>>> +1
>>>
>>>
>>> Auke - I would suggest that you lead by example and make a conscious
>>> effort to
>>> say "NIH is not acceptable. We now know of external tools that are
>>> functionally
>>> equivalent to internal tools. We will drop the internal tool and work
>>> with the
>>> wider community."
>>
>> Nonsense :)
>
> heh :)
>
> Could you clarify which bit is nonsense? Are you saying that NIH is
> acceptable?
> Or is re-implementing internally a good idea when you know of external
> equivalents?
>
>> Innovation comes from looking at an old good idea, and making a newer
>> and shinier implementation of it - not from shooting down good ideas
>> just because someone has already invented it...
> True.
> Those innovators get the best out of the community.
>
>
> However I suggest that the very *best* innovators don't just take the ideas
> of
> others and reimplement in the easiest way possible to their own advantage
> leaving those upon who's shoulders they climbed in the dust. They go the
> extra
> mile and reimplement in a way that reaches back down to enable the whole
> community to benefit.
>
> Those innovators give the most back to the community.
>
>
>
> Which is (/me just checks the copyright on bootchart.c... Intel
> Corporation...)
> Intel?
>
> Maybe in this case a small, efficient, in-memory data collection engine that
> could supplement the tools built around the other bootchart utilities.
>
> Sure bootchart is only a few lines of code - but I hope I'm arguing
> constructively to ensure bootchart isn't the thin end of the wedge.
>
> David
> --
> "Don't worry, you'll be fine; I saw it work in a cartoon once..."
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 30 Mar 2010 13:45:58 -0700
> From: Auke Kok <[email protected]>
> To: David Greaves <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] Bootchart2 / bootchart duplication ...
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/30/10 12:56, David Greaves wrote:
>> Auke Kok wrote:
>>> On 03/30/10 03:43, David Greaves wrote:
>>>> Michael Meeks wrote:
>>>>> My views on this sort of Intel internal re-writing are well known.
>>>>> There is a good way to do this: work with the existing guys on the
>>>>> various bootchart projects out there, and try to draw them together.
>>>>> That is the approach I took with bootchart2. It is also far, far less
>>>>> wasteful of the scarce resources that we (collectively) have today to
>>>>> work on tooling.
>>>> +1
>>>>
>>>>> There is a good way to do software development in community; and
>>>>> IMNSHO
>>>>> it doesn't look like this. We don't need yet-another bootchart
>>>>> project[2] there are currently a handful (now +1).
>>>> +1
>>>>
>>>>
>>>> Auke - I would suggest that you lead by example and make a conscious
>>>> effort to
>>>> say "NIH is not acceptable. We now know of external tools that are
>>>> functionally
>>>> equivalent to internal tools. We will drop the internal tool and work
>>>> with the
>>>> wider community."
>>>
>>> Nonsense :)
>>
>> heh :)
>>
>> Could you clarify which bit is nonsense? Are you saying that NIH is
>> acceptable?
>> Or is re-implementing internally a good idea when you know of external
>> equivalents?
>>
>>> Innovation comes from looking at an old good idea, and making a newer
>>> and shinier implementation of it - not from shooting down good ideas
>>> just because someone has already invented it...
>> True.
>> Those innovators get the best out of the community.
>>
>>
>> However I suggest that the very *best* innovators don't just take the
>> ideas of
>> others and reimplement in the easiest way possible to their own advantage
>> leaving those upon who's shoulders they climbed in the dust. They go the
>> extra
>> mile and reimplement in a way that reaches back down to enable the whole
>> community to benefit.
>>
>> Those innovators give the most back to the community.
>
> You're making much more out of this than is even worth it.
>
> If you want to discuss bootchart on a technical level, I'm fine with that.
>
> If you want to argue policy, please start a new thread or propose a
> steering group meeting topic.
>
> Auke
>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 31 Mar 2010 14:51:38 +0800
> From: "Zhang, Qiang Z" <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: [MeeGo-dev] GConf API Usage issue
> Message-ID:
> <cf2f38d4ae21bb4cb845318e4c5ecb671d5fd...@shsmsx501.ccr.corp.intel.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello all,
>
> I am using GConf API (gconf_client_get, etc.) to read system configures
> info, but I encounter the follow issue:
>> Wrote a small code to read system configure, it's OK on netbook
>> locally, but fails when execute from remote using ssh.
> Sample code as follows:
> #include <stdio.h>
> #include <stdlib.h>
> #include <gconf/gconf-value.h>
> #include <gconf/gconf-client.h>
> int main()
> { GError *error = NULL;
> GConfClient *client = (g_type_init(), gconf_client_get_default());
> const char *host;
> if (client != NULL){
> GConfValue *v = gconf_client_get(client, "/system/http_proxy/host",
> &error);
> if (v != NULL)
> host = gconf_value_get_string(v);
> printf("Host:%s\n",host);
> g_object_unref(client);
> }
> }
>
> Execute locally:
> [xiaoqi...@zq-desktop cmake]# ./a.out
> Host: proxy01.pd.intel.com #[Correct proxy info]
> Execute remotely
> [xiaoqi...@zq-desktop cmake]# ./a.out
> Host: #[No proxy info here]
> --------------
> We can see no host proxy info from remote.
> The same issue also occurs at library using GConf API (gconf_client_get),
> and if I write a library using GConf API, then the API cant works well.
>
> Any comment? How to write a library using GConf, or any options? GConf API
> seems using dbus to get info, how to control it?
> Thanks in advance.
>
> -Thanks
> -Qiang
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.meego.com/pipermail/meego-dev/attachments/20100331/def7f4a8/attachment-0001.html>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 31 Mar 2010 15:02:42 +0800
> From: Roger WANG <[email protected]>
> To: "Zhang\, Qiang Z" <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] GConf API Usage issue
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
> Zhang, Qiang Z <[email protected]> writes:
>
>> Hello all, I am using GConf API (gconf_client_get, etc.) to read
>> system configures info, but I encounter the follow issue:
>
>> * Wrote a small code to read system configure, it?s OK on netbook
>> locally, but fails when execute from remote using ssh.
>
> The thing missing when you're using remote login is a proper set
> DBUS_SESSION_BUS_ADDRESS environment variable. gconf-dbus need that to
> find the session bus, as other dbus client does.
>
> --
> Roger WANG
>
>
> ------------------------------
>
> Message: 14
> Date: Wed, 31 Mar 2010 10:07:58 +0200
> From: <[email protected]>
> To: <[email protected]>, <[email protected]>
> Cc: [email protected], [email protected], [email protected]
> Subject: Re: [MeeGo-dev] On device help framework
> Message-ID:
>
> <6f45dee63c5bb542b6a7b0c4e41467d0152f173...@nok-eumsg-03.mgdnok.nokia.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi all,
> For the developer documentation there is a start of the developer
> guide on the wiki (http://wiki.meego.com/Developer_Guide) it is rather blank
> being more of a proposal that a finished product, ideal for community
> participation.
>
>>
>>Foster, Margie wrote:
>>> I think there are at least two types of documentation being discussed
>>here: that which a developer wants and that for an end user (the
>>consumer). The tech writer here at Intel is writing the end user help,
>>and that's something we can figure out how to open source after the
>>first release. However, developer documentation is wide open, AFAIK. I
>>think there is an SDK working group, and that might be the place to
>>bring up this collaborative effort.
>>
> I agree, the developer documentation is part of the developer offering of
> Meego. Having good tools and good documentation is essential to the success
> of Meego as a platform.
>
>>1. API documentation - should be in the source code (Doxygen, or QDoc,
>>or gtk-doc, or JavaDoc, or whatever) - any developer should be able to
>>patch this. 90% of this type of documentation will be upstream, and is
>>not specific to MeeGo
>
> The Meego source code can be used to generate the API documentation. There
> needs to be guidelines on how to document the code in order to make it
> consistent (a set of recommended doxygen tags for example). For APIs
> outside the scope of Meego, for example OpenGL, we should just link to their
> documentation and create a use case/user story around howto use OpenGL
> inside Meego.
>
>>
>>2. Code samples and "toolbox" type documentation, describing how to
>>string together different APIs to accomplish something consequential -
>>some of these will be documented in the source code, and some of these
>>will be in the form of code samples and tutorials, some will be in the
>>wiki. We should try, as we started to do in Maemo with the use-case
>>template: http://wiki.maemo.org/Documentation/Use_case_template to
>>standardise these & centralise them into a kind of searchable knowledge
>>base. Much of this will not be applicable only to MeeGo, so we should
>>try and make sure that we're submitting docs like these upstream where
>>possible
>
> The use case template in wiki.meego.com is copied from the one at Maemo. I
> cannot say how we should submit documents to upstream components as they
> will have their own policies and ways of documenting, but we can plan to
> have these sections to be easy to edit and more open to the
> community/developers.
>
>>
>>3. Developer guides - platform overview, development environment set-up,
>>how to deploy an application, UI guidelines - longer documents aimed at
>>application developers, reference documents. Mostly MeeGo specific. This
>>is where I see a great need for read-write documentation
>>
>
> Agreed.
>
>>4. User documentation - how to use the basic desktop, core applications
>>included with MeeGo, and also user documentation for user-developped
>>applications (oft neglected!) - we should ensure that everyone can
>>contribute here, where possible
>>
>>If you're only talking about the fourth type, then there probably isn't
>>a major issue. The developer guides and tutorials & code samples are
>>where it will be trickier to have something that works well.
>>
>
> The localization of the developer guides and use cases will be rather
> tricky. The API reference documentation will be particularly tricky since
> it is embedded in the source code. For the other read-write documentation,
> it might be possible to have community participation.
>
> The user documentation is different story. Companies making products based
> on Meego will have to create user documentation describing the applications,
> desktop functions that are available, so reusing their output would make
> sense if it is available.
>
>>Since initial versions of MeeGo will primarily be aimed at developers,
>>as I understand it, the middle tier of documentation is the most
>>important to the success of the platform (in terms of rapid adoption of
>>MeeGo as a developer platform). It's also the area where openness is
>>most important.
>>
>>Cheers,
>>Dave.
>>
>>
>>--
>>maemo.org docsmaster
>>Email: [email protected]
>>Jabber: [email protected]
>>
>>_______________________________________________
>>MeeGo-dev mailing list
>>[email protected]
>>http://lists.meego.com/listinfo/meego-dev
>
>
> ------------------------------
>
> Message: 15
> Date: Wed, 31 Mar 2010 11:34:15 +0100
> From: Damien Lespiau <[email protected]>
> To: "Zhang, Qiang Z" <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [MeeGo-dev] GConf API Usage issue
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 2010-03-31 at 07:51 +0100, Zhang, Qiang Z wrote:
>> Hello all,
>
> Hi,
>
>> GConfValue *v = gconf_client_get(client,
>> "/system/http_proxy/host", &error);
>
> Note that poking GConf for proxy configuration is *not* how one should
> query the proxy information.
>
> The way to do it is to go through libproxy[1], which happens to mimic
> the way firefox has done it in the first place (GConf keys, GNOME plugin
> in libproxy). For instance, using libproxy will allow you to support
> proxy auto configuration out the box, something that needs a javascript
> engine, nothing less... http://en.wikipedia.org/wiki/Proxy_auto-config
>
> HTH,
>
> --
> Damien
>
> [1] http://code.google.com/p/libproxy/
>
>
>
> ------------------------------
>
> _______________________________________________
> MeeGo-dev mailing list
> [email protected]
> http://lists.meego.com/listinfo/meego-dev
>
>
> End of MeeGo-dev Digest, Vol 2, Issue 31
> ****************************************
>
--
//with Best Regards
--Denis Bolshakov
e-mail: [email protected]
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
