RE: Any early QtWRT adopters flying with us?

[Devesh.Kothari]

I can try and help you out.

Devesh


From: maemo-developers-boun...@maemo.org 
[mailto:maemo-developers-boun...@maemo.org] On Behalf Of ext Dawid Lorenz
Sent: 12 August, 2010 16:57
To: Maemo Developers
Subject: Any early QtWRT adopters flying with us?

I was wondering whether any early adopters of recently released Qt Web Runtime 
are here on this list? I've been trying to develop a little application of my 
own, yet lack of proper documentation (which is apparently in works) and rather 
quiet QtWRT forum [1] doesn't help. Anyone trying QtWRT out recently, please 
stand up. :) Thanks!
[1] http://developer.qt.nokia.com/forums/viewforum/20/

--
Dawid 'evad' Lorenz * http://dawid.lorenz.co

null:// I haven't lost my mind - it's backed up on disk somewhere
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

FW: [Telepathy] Announce: mission-control 4.17

[Devesh.Kothari]

FYI, just in hope that this announcement does not go unnoticed :)


Cheers
Devesh
 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of 
>ext Naba Kumar
>Sent: 09 March, 2007 19:08
>To: telepathy@lists.freedesktop.org
>Cc: gnome-announce-list@gnome.org
>Subject: [Telepathy] Announce: mission-control 4.17
>
>Hi all,
>
>Let me take the pleasure to announce our first public release of
>(telepathy) mission-control. The release is sufficiently 
>stable and implements most of the features that were planned. 
>We hope you will enjoy using it in your telepathy based 
>communication softwares for more powerful integration. It uses 
>glib and gconf hence is mostly suitable for GTK/GNOME based 
>applications.
>
>What is Mission Control?
>
>
>Mission Control, or MC, is a Telepathy component providing a 
>way for "end-user" applications to abstract some of the 
>details of connection managers, to provide a simple way to 
>manipulate a bunch of connection managers at once, to remove 
>the need to have in each program the account definitions and 
>credentials, to manage channel handling/request and to manage 
>presence statues. See the diagram at homepage.
>
>http://mission-control.sourceforge.net
>
>What is new?
>
>
>This is the first release of mission-control that implements 
>most features as explained in the above URL.
>
>Where to get it?
>
>http://sourceforge.net/project/showfiles.php?group_id=190214
>
>What are the dependencies?
>==
>glib, gconf
>
>Happy coding.
>
>Regards,
>-Naba
>___
>Telepathy mailing list
>Telepathy@lists.freedesktop.org
>http://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] How to change font

[Devesh.Kothari]

In Maemo 3.0

http://maemo.org/platform/docs/howtos/howto_him_bora.html

It was made possible for 3rd party to extend the Hildon input methods

Devesh
 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of ext 
>Sun Richard
>Sent: 09 February, 2007 11:47
>To: ext wolfg
>Cc: maemo-developers@maemo.org
>Subject: Re: [maemo-developers] How to change font
>
>On Fri, 2007-02-09 at 17:31 +0800, ext wolfg wrote:
>> 2007/2/8, Sun Richard <[EMAIL PROTECTED]>:
>> > Not for N770. And I don't know when it will be available 
>in public. 
>> > :/
>> >
>> > //X2
>> >
>> 
>> means no way to input Chinese characters on N770?
>> 
>It means you can not input Chinese with hildon Input method. :)
>
>Cheers
>X2
>___
>maemo-developers mailing list
>maemo-developers@maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Dream Scenario (Re: Maemo roadmap, SDK improvements...)

[Devesh.Kothari]

One way to start would be 

- look at the developer rootfs (it includes the package db). I think
this info is also available from package list, which enable you to
create your own packages (sometimes also refered to as black list ;)
- cross check with the ones available in maemo repo

You will get the number of binary only packages. This gives a start
point. 
Would be interesting to know the number so we can quantify what % of the
total is closed binary only. On top of my head that number would be less
than 5%. How about Maemo team ??? Any takers :)

 
Devesh


>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of ext 
>Hanno Zulla
>Sent: 07 February, 2007 12:53
>To: maemo-developers@maemo.org
>Subject: Re: [maemo-developers] Dream Scenario (Re: Maemo 
>roadmap,SDK improvements...)
>
>Jorge Salamero Sanz schrieb:
>> so why nokia is claiming they have an oss product if they are not 
>> making any effort to open it ?
>
>Allow me to rephrase this a bit less harsh. Nokia, so far, is 
>doing a really good job and just because the flamewar is the 
>de-facto mode of discussion between most FOSS developers, I'm 
>not trying to flame Nokia into submission to my wishes...
>
>So far, Nokia has tried to attract application developers. 
>That's the layer above the platform.
>
>I would like to tinker with the platform, though.
>
>Making this possible will require an added layer of 
>development material for non-Nokia folks.
>
>It would be nice if Nokia could make this possible and I am 
>naive enough to believe that this is doable /and/ in the best 
>interest for both parties.
>
>(Nokia developers, if there is a way where we can - politely - 
>ask for this from your keepers / project managers, let me know.)
>
>Regards,
>
>Hanno
>
>
>___
>maemo-developers mailing list
>maemo-developers@maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Xvideo support for Nokia 770?

[Devesh.Kothari]

 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of ext 
>Siarhei Siamashka
>Sent: 08 February, 2007 09:16
>To: maemo-developers@maemo.org
>Subject: Re: [maemo-developers] Xvideo support for Nokia 770?
>
>Hello, 
>
>It would be probably a good idea to discuss different 
>possibilities for improving multimedia support on 770/N800.
>
>Now we have a fast JIT scaler that runs on ARM core, it solves 
>all the video resolution related performance problems. I'm 
>going to work on improving quality, performance and its 
>inclusion into upstream ffmpeg library, this task is in my 
>nearest plans:
>http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-January/0
>51209.html
>
>As for the ways of improving multimedia support on Nokia 770, 
>it may be done in the following ways (in no particular order):
>1. Continue ffmpeg optimizations (motion compensation 
>functions, finetune idct, have a look at the possibilities to 
>optimize codecs other than mpeg4 and its variants) 2. 
>Implement Xvideo extension support for Nokia 770 (using 
>scaling done on ARM core) 3. Implement XvMC in some way (using 
>C55x DSP for it as it is supposedly good for IDCT and motion 
>compensation stuff) 4. Improve GStreamer plugins (replacements 
>for dspfbsink and dspmpeg4sink running on ARM core, it could 
>probably improve mpeg4 playback performance a lot and allow 
>using higher video bitrates and resolutions that are currently 
>available in MPlayer) 5. Try to relay color format conversion 
>and scaling to DSP. If it works as expected, video scaling can 
>be done with almost zero overhead for ARM core. Theoretically 
>the same trick could probably also work for GStreamer if video 
>output sink can provide its own buffer (::buffer_alloc). The 
>first step would be to try just doing nonscaled color format 
>conversion. If it is successful, some more advanced stuff can 
>be tried such as JIT dynamic code generation on C55x.
>6. Try porting vorbis decoder (tremor) to DSP 7. Try porting 
>libmpeg2 to DSP. With audio decoding and scaling done on ARM 
>core, it might improve overall mpeg2 playback performance, I 
>wonder if nonconverted DVD video playback is even 
>theoretically possible on Nokia 770.
>
>That's quite a big list and it contains some things that might 
>be generally nice to have, but have relatively low practical 
>value and are actually not worth efforts implementing :)
>
>There are two issues that need to be solved for this all to 
>become reality:
>1. We need some way of applying community developed upgrades 
>for core system components such as xserver and xlib (if we go 
>after Xvideo support on Nokia 770). They must be easy to 
>install by end users, otherwise this all development does not 
>make much sense. It would be also nice to integrate these 
>improvements into official firmware later, but I wonder if 
>Nokia has spare resources for doing this integration and its 
>quality assurance.

>2. Reliable information that is detailed enough for performing 
>graphics and audio output from DSP, see 
>http://maemo.org/pipermail/maemo-developers/2007-February/007949.html

Again throwing some options in the air
1. Dump DSP. If I remember the driver for the audio chip is in the omap
tree. So (probably never tried) is to remove all dsp related components
from the image, and then have everything purely on ARM [maybe worth a
shot]
2. use ALSA DSP


Devesh

>___
>maemo-developers mailing list
>maemo-developers@maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Dream Scenario (Re: Maemo roadmap, SDK improvements...)

[Devesh.Kothari]

 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of ext Dave Neuer
>Sent: 07 February, 2007 15:25
>To: Stone Daniel (Nokia-M/Helsinki)
>Cc: maemo-developers@maemo.org
>Subject: Re: [maemo-developers] Dream Scenario (Re: Maemo 
>roadmap,SDK improvements...)
>
>On 2/7/07, Daniel Stone <[EMAIL PROTECTED]> wrote:
>>
>> Also, the FIASCO generator would presumably have to be 
>opened for this 
>> to happen.
>
>Carl said this too, and I'm unclear as to the dependency of an 
>all-open-source FIASCO image on opening the flasher tool; it 
>seems like I can already package up a new image using the 
>closed-source flasher, no?

Its been a while, don't know if that has changed
FIASCO is more of a container, flasher is able to seperately flash
kernel, jffs2 rootfs etc. I think if I remember correctly you could even
extract different parts in a FIASCO image using the flasher.

E.g if you want to just recompile the kernel, you can flash that
seperately
Devesh

>
>Dave
>___
>maemo-developers mailing list
>maemo-developers@maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Too busy to accept help? I'm not complaining

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of ext Dave Neuer
> Sent: 12 May, 2006 00:02
> To: Kothari Devesh (Nokia-M/Tampere)
> Cc: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] Too busy to accept help? I'm not
> complaining
> 
> 
> On 5/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > can you be more specific ???
> > >
> > > I can remove all software for which I cannot access and 
> re-publish the
> > > source code and all of the hardware capabilities (power 
> management,
> > > DSP and whatever other little doodads Nokia packed in 
> there) are still
> > > accessible; I can compile a kernel and a corresponding 
> initfs and root
> > > fs from source. Etc.
> >
> > Those are the goals but i have to admit we have not yet 
> reached there. We are
> > working on most parts e.g you can compile your own kernel, 
> create your custom rootfs,
> > remove stuff etc with package management. There are still 
> certain piecies which are
> > either not in our direct control (e.g TI/DSP related 
> stuff), and some which we
> > just cant give out (e.g battery related software).
> 
> As far as the DSP stuff goes, if a developer has linux-dsp-tools,
> what's the issue? The actual code which implements the DSP tasks
> should be distributable under just about any license, no?

developers are free to use the linux-dsp-tool and write dsp tasks
(there have been some previous discussion on the mailing list about 
that)if they want to (and distribute it in a license terms they like), 
for us mostly the licensed codecs run as dsp tasks which
we cannot give out. sorry

> 
> > For us it is important to strive a balance at product 
> creation and at the same
> > time persue the openness goal
> 
> I certainly understand that being a software developer by profession
> myself. However, to some extent, the two goals are either at odds, or
> the second one is actually more important, to whit:

In my opinion, they are more complementary goals, like our desire towards
openess results in us thinking more about customizable, extendible and generally
better architecture which has clear points for openness and 
product differentiation. It also makes us think about enabling MOST developer
use cases to enable cooperation and working with communities as well
as engaging commercial ISV developers

> 
> If Nokia has a product which is viable in the marketplace as it
> currently stands, it actually doesn't need the community and can do
> only what it has to do legally to comply with the licenses of the Free
> Software it ships. In which case pursuing openess is just a
> distraction and internal development effort focussed on that goal is
> probably wasted. This of course puts the community in a position where

Maemo and Nokia 770 is based on large majority or open software and 
has benifit from the open source, and that brings into us a sense to 
work together with the community as a constructive partner. To us open 
source and openness strategy is a long term investment and not a one time
opportunistic goal.
 
> it has little option but to reverse-engineer the parts that Nokia
> won't release and pursue whatever course makes the community's
> software usable and effective, even if it means forking.

As with all open source projects and initiatives these are individual
choices :) The better option is to identify areas which are close, and then
come up with extendible architecture, so the nokia solution can coexist with 
a reference implementation (so its more worth while to work on stable interfaces
and reasonable standardization). This provides 2 advantages, first better 
architecture and second, points of differentiation for vendors 
(i.e there could be optimized battery and power management features, or better
DSP optimized multimedia)

> 
> On the other hand, if Nokia is hoping that it can leverage the
> comminity to *create* the software that makes the device a compelling
> product for consumers, then it's in a bind; it must please the
> developer community *first,* so that we'll be motivated to do the
> lifting required to get the product to that point; speaking
> personally, my own enthusiasm for the device is directly tied to its
> openess, and my interest in contributing is entirely linked to this

As i mentioned earlier, every individual needs to make or find his/her
happiness and hence reason for contributions. I am sorry to hear
you werent, but that only helps us to keep improving :)
 
> (hence my not developing software for the various Windows-based
> tablets and handhelds or purchasing said devices).
> 
> To put this in a slightly different perspective, compare it to the
> situation in desktop and server operating systems: it is widely
> accepted that it's the open source development process itself which
> makes Linux a stable server platform, so it's strongly in the
> self-interest of vendors shipping said hardware to support *the
> community* well. On the othe

RE: [maemo-developers] GMP - available on 770?

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: 10 May, 2006 09:52
> To: maemo-developers@maemo.org
> Subject: [maemo-developers] GMP - available on 770?
> 
> 
> Dear all,
> 
> I found something very puzzling.  Is the GMP available on 770?
> 
> In the scratchbox SDK environment:
> 
> dpkg -l|grep gmp
> 
> libgmp3
> libgmp3-dev
> 
> It shows that it is available in SDK environment.
> 
> But on Nokia 770 itself:
> /usr/lib/libgmp.so.3.3.3
> Or
> /usr/lib/libgmp*
> 
> Simply does not exist.
Always please refer to 

http://repository.maemo.org/stable/1.1/package_reference.html

which points out, what is available on device compared to maemo releases
cheers
Devesh

> 
> Is it planned to include libgmp somehow in future?
> And if I wanted to use this library, which I can use in SDK, 
> should I manually install it from a debian arm package?
> 
> Alvis Koon
> Software Engineer
>  
> TietoEnator
> Telecom and Media
> Direct +86 010 84221188 ext 189
> Mobile +86 13911789924
> Fax +86 010 84221189
> E-mail [EMAIL PROTECTED]
>  
> Unit 301, House 2, No.11 HePingLi DongJie,
> DongCheng District
> Beijing, 100013 PRC
>  
> www.tietoenator.com
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Too busy to accept help? I'm not complaining

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of ext Dave Neuer
> Sent: 04 May, 2006 23:39
> To: Kothari Devesh (Nokia-M/Tampere)
> Cc: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] Too busy to accept help? I'm not
> complaining
> 
> 
> On 5/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > Well, since you brought up "truely open product" and "expectation
> > > management," what are Nokia's expectations about when the 
> 770 will be
> > > a truely open product (i.e., I can run all free software 
> on the device
> > >
> > Maemo 2.0 would take it closer, with real package 
> management. It is even today
> > an open product, you can get root and install whatever you 
> want today :) but
> > remember the hardware limitations of the device itself :)
> >
> > > without losing any functionality)?
> > can you be more specific ???
> 
> I can remove all software for which I cannot access and re-publish the
> source code and all of the hardware capabilities (power management,
> DSP and whatever other little doodads Nokia packed in there) are still
> accessible; I can compile a kernel and a corresponding initfs and root
> fs from source. Etc.

Those are the goals but i have to admit we have not yet reached there. We are
working on most parts e.g you can compile your own kernel, create your custom 
rootfs,
remove stuff etc with package management. There are still certain piecies which 
are
either not in our direct control (e.g TI/DSP related stuff), and some which we
just cant give out (e.g battery related software).

The important thing i believe is still to work with (work around;) limitations, 
and strive towards abstraction and generic architecture which would enable to 
make maemo more extensible, adaptable and customizable for different hardware 
configuration (though for the moment we pretty much product driven and that 
takes the priority, BUT i firmly believe that community with its experience can 
really help on this front), remember Nokia 770 is NOT
a kind of reference platform :) for us

For us it is important to strive a balance at product creation and at the same
time persue the openness goal

Rome was not built in a day :)
cheers
Devesh

> 
> Dave
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Too busy to accept help? I'm not complaining

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext Dave Neuer
> Sent: 02 May, 2006 21:07
> To: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] Too busy to accept help? I'm not
> complaining
> 
> 
> On 4/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > no offense, it always look simpler from the other side. 
> Developing and
> > bringing a product to market (in all my experience) is no 
> simple task
> > combine that with new challenges working with open source, 
> and OS communities,
> > new processes and at the same time building a truely open product.
> > I am not saying we havnt and we will not make mistakes 
> (maybe we will),
> > but we are ready to listen and willing to learn.
> >
> > And as i see right now, I am ready to take small baby steps 
> and disappoint few
> > than going grand. There is a natural order of things, and 
> lot what you suggested
> > would/may happen but lets take patience as a virtue.
> >
> >
> > As your rightly said, its about expectation management :)
> > cheers
> > Devesh
> 
> Well, since you brought up "truely open product" and "expectation
> management," what are Nokia's expectations about when the 770 will be
> a truely open product (i.e., I can run all free software on the device
Maemo 2.0 would take it closer, with real package management. It is even today
an open product, you can get root and install whatever you want today :) but
remember the hardware limitations of the device itself :)

> without losing any functionality)?
can you be more specific ???

Devesh

> 
> This has been the #1 reason why the device has mostly sat unused in my
> house rather than constantly traveling with me and sucking up a lot of
> my time. I honestly expected based on Nokia's (admittedly limited)
> advanced advertising of the product that that would be the case
> immediately, rather than at some unspecified point in the future.
> 
> Dave
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Too busy to accept help?]

[Devesh.Kothari]

> 
> 
>  Original Message 
> Subject: [maemo-developers] Too busy to accept help?
> Date: Wed, 19 Apr 2006 13:14:13 +0200
> From: ext Murray Cumming <[EMAIL PROTECTED]>
> To: maemo-developers@maemo.org
> 
> The Maemo community is alive, but not thriving as much as it 
> could. This
> is because the Nokia developers are so busy and are often unable to
> respond to the simplest of requests for changes or information, and
> often unable to even acknowledge that contributions have been 
> accepted.

I agree. but sometimes, I believe also community cannot be pushed 
too hard either, things just take time (simple example is if
something itches, you step in to solve :)

> It's OK to be busy, so this isn't a personal attack on those 
> developers.
> It's a suggestion for how to take the weight off them.
> 
> I think Nokia needs to assign a dedicated community liaison, full time
> or part time, while still demanding that all developers are involved
> with the community as much as possible. This person would maintain the
> web site, and help the community to maintain it by extracting
> information from Nokia. This person would also do simple patch and bug
> triage and apply obvious changes without bothering the developers with
> trivial stuff.

I rather turn this other way to identify clear problems today and expectations
e.g (here is my list), feel free to add

1. Responsive discussion on mailing list (this should decrease, as Maemo 
matures,
  and more things get documented) - so patience advised
   [Thing community can do for us] : Create a Wiki page with concrete How-To's 
needed. Remember so 
   many things are discussed on mailing dev list, which are asked again and 
again. Also it is easier
   to update things at one place, when things change
2. clear forums for feature/enhancements discussion
3. more transparency from Nokia about Maemo roadmap (with ability for community 
to be involved)
4. responsive bugzilla [this should now start to work :)
5. ability for community to be involved with bleeding edge Maemo, to contribue 
and experiment
   baby step 
[http://maemo.org/pipermail/maemo-developers/2006-April/003550.html]
6. ability for community to contribute and share Maemo applications
7. Clear process from each project (in Murrays case HAF) 
   - how they accept contributions (e.g access rights, patches, feature 
enhancements)


I still see a lot of value in Murrays proposal, and as Carlos pointed out :) 
there are hiring announcements :).

Devesh

> 
> It must be politically acceptable for this person to be under less
> pressure than a regular developer. If the community liaison 
> ever has no
> problems to solve then that's good.
> 
> If you need a more traditional job title, you could squeeze these
> responsibilities into "Documentation" or "Q & A".
> 
> Nokia will get a lot of the advantages of open source if they don't do
> this, and the community will survive if they don't do this, 
> but I think
> the extra salary would be a good investment to get even more valuable
> advantages.
> 
> 
> -- 
> Murray Cumming
> [EMAIL PROTECTED]
> www.murrayc.com
> www.openismus.com
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Too busy to accept help? I'm not complaining

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext 
> Shawn Gordon
> Sent: 19 April, 2006 23:06
> To: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] Too busy to accept help? I'm not
> complaining
> 
> 
> At 12:23 PM 4/19/2006, Philippe De Swert wrote:
> >Hello Shawn,
> >
> >On Wed, 2006-04-19 at 11:59 -0700, Shawn Gordon wrote:
> > > I've already got Nils slamming me privately because I dared to
> > > mention Qtopia, but let me provide some perspective as a 
> company who
> > > was very successful with Qtopia and the Sharp Zaurus and 
> what Sharp
> > > and Trolltech did both right and wrong that Nokia could 
> learn from (I
> > > don't care if they use Qtopia at this stage, I just 
> honestly think it
> > > would have been faster and cheaper than going the route 
> they did, but
> > > I am not privy to the information that went in to making 
> that decision).
> >
> >Why would Qtopia be faster and cheaper?
> 
> faster because it is done, has been used, refined, debugged and 
> developed for for years, so other than device drivers in the kernel 
> it wouldn't have taken hardly any time at all to get it up 
> and running.

no offense, it always look simpler from the other side. Developing and
bringing a product to market (in all my experience) is no simple task
combine that with new challenges working with open source, and OS communities,
new processes and at the same time building a truely open product. 
I am not saying we havnt and we will not make mistakes (maybe we will), 
but we are ready to listen and willing to learn.

And as i see right now, I am ready to take small baby steps and disappoint few
than going grand. There is a natural order of things, and lot what you suggested
would/may happen but lets take patience as a virtue. 


As your rightly said, its about expectation management :)
cheers
Devesh
> 
> cheaper - I'm assuming cheaper based on what I know of the licensing 
> costs and the costs to hire a bunch of developers for years to 
> develop and support the software.  Nokia is not going to just rely on 
> the open source community for something that they depend on, they 
> will certainly have their own developers and these are going to be 
> far more expensive than simply paying a small per unit license cost 
> (I'm talking ones of dollars per unit).
> 
> >I am not trying to troll here
> >but both have wide support in the Free Software community. 
> (However in
> >the embedded space GTK might have an edge. GPE is atm better 
> supported
> >and has more active developers than Opie for example. And I am not
> >stating that because I happen to be involved with GPE, but 
> because both
> >Opie and GPe are involved with familiar we know about each other
> >projects and we even co-operate on certain parts.)
> 
> Keep in mind that Opie is simply a fork of the GPL version of Qtopia, 
> so they get the advantage of all the things I spelled out above.
> 
> 
> > > Now by the time the Zaurus was commercially available, my company
> > > already had a dozen products running on it, maybe more, 
> and there was
> > > a big and healthy open source movement that was also producing
> > > software, I don't remember how many apps, but it was a good amount
> > > and grew very rapidly.
> >
> >Well Nokia might not have had applictions readily available 
> before the
> >product was released. But I do remember porting an app in 
> the maemo SDK
> >before the device was actually available
> >
> > > What was done right:
> > >
> > > 1.Sharp actually located about 50 companies and 
> individual developers
> > > 2.They worked with Handango to create a web site where 
> commercial and
> > > 3.Trolltech hired a liaison to work directly with the embedded
> > > community and keep the line of communication open.
> >
> >Ok. That indeed are valid points that could contribute to 
> success with
> >an "open" project. However *again* I see no reason why 
> Qtopia would have
> >been an advantage. In it's own right I believe the technical 
> choice GTK
> >vs QT(opia) has nothing to do with the success of these 
> projects. As you
> >point out political choices are much more important. Nokia 
> has supported
> >Gnome and has hired professional companies to support them as can be
> >seen in Ari Jaaksi's presentation from Boston see (slide 7):
> >http://www.kotiposti.net/jaaksi/ME9_LinuxWorld_2006_AriJaaksi_.pdf .
> >So the one thing they really need to do is having somebody 
> that can put
> >time in co-ordinating the community and pass on all interesting
> >developments to the people in Nokia who take the decisions. This last
> >part has not yet been done. And if they manage to pick up the good
> >things from the community it will become a killer product. So they
> >definitely need to work on point 3. Apart from that the used toolkit
> >point is completely moot. The 770 would probabely be as 
> good/bad as it
> >is now regardless of GTK or QT.
> 
> I'm not espousing the benef

RE: [maemo-developers] Maemo 2.0 API changes, signals and properties

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext 
> Shawn Gordon
> Sent: 19 April, 2006 20:10
> To: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] Maemo 2.0 API changes, signals and
> properties
> 
> 
> At 10:03 AM 4/19/2006, Marius Vollmer wrote:
> >"ext Shawn Gordon" <[EMAIL PROTECTED]> writes:
> >
> > > What's happening at Nokia to help with this and remove the
> > > perception that the device is a beta unit?
> >
> >We are hanging around on mailing lists and browse blogs, waiting for
> >someone to tell us what to do. ;-)
> 
> I'm engaged in private conversations with 2 people at Nokia involved 
> with the 770 about our issues and they agree with everything, but 
> we're still waiting for something to happen.  My concern is that 
> these conversations have been going for 5 months now with no visible 
> progress.  There could be progress behind the scenes, but I'm not 
> privvy to it, so I'm expressing my frustration here.  The other 
> frustration is that we have a number of applications on other devices 
> that we'd port to the 770 except that Nokia has given the impression 
> that these are coming any time now, so we haven't done it, but the 
> apps haven't shown up either.
> 
> I think the device is really nice, but maemo itself just seems far 
> from complete and it gives the whole experience a beta feel.  Not to 

It will really help me if you please send a list, where you think we 
need to improve (please dont say we need to move to QT :)
e.g API (functionality) missing in Maemo which is there in Qtopia

Devesh

> dredge up the whole decision of what to use on the device again, but 
> Qtopia would have been a lot less of a hassle.

> 
> 
> >___
> >maemo-developers mailing list
> >maemo-developers@maemo.org
> >https://maemo.org/mailman/listinfo/maemo-developers
> 
> 
> Regards,
> 
> Shawn Gordon
> President
> theKompany.com
> www.thekompany.com
> www.mindawn.com
> 949-713-3276
> 
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Maemo 2.0 API changes, signals andproperties (was: ANN: Eagle)

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext 
> Shawn Gordon
> Sent: 19 April, 2006 19:15
> To: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] Maemo 2.0 API changes, signals
> andproperties (was: ANN: Eagle)
> 
> 
> I gotta say as a third party developer that the state of Maemo is 
> rather frustrating, it seems like a far from done piece of work and a 
> moving target.  I've seen a lot of complaints on industry reviews of 

- First it is expected to be a moving target :) [improved features, bug fixes, 
runtime performance improvements etc ..]
- Its strange to say "Maemo ... far from done piece of work". What are your 
expectations???

IMHO Maemo 1.1 provides a solid start point. Its gives you capability to write, 
test, cross compile in a easy to use environment. Most of the developers have 
really appreciated the kind of plumbing less (if a word like that exist:) 
development environment. There are short commings, but I dont think developers 
with C/glib/gtk/sdl have any major issues. Community has been great at pro 
actively providing great support to who asked for it on developer mailing 
lists, and have produced so much sample code (sdl games, hildon apps, plugins 
etc), to make up for lot of still missing documentation. 

As for other things source code to almost everything is available 
(http://maemo.org/lxr/), browse it and you would know in most cases, what is 
going wrong. Most places, examples could be found together with source e.g 
http://maemo.org/lxr/source/maemo-examples/

I agree it all can be better organized (and we working on it), as for API 
breaks, Maemo almost all is built on top of open source projects (hildon/hildon 
desktop/haf included), so we just need to be able to deal with it (API changes, 
reasonable effort is made not too), important thing is we are able to 
communicate them early on (again a work item)


> the device as well to the stability and selection of software 
> included on the device.  What's happening at Nokia to help with this 
> and remove the perception that the device is a beta unit?

As with all devices, you get some good reviews, some ok, and some bad.
What is important is we are commited to delivering good quality products 
for our focused target segment.

Devesh

> 
> thanks,
> shawn
> 
> At 08:52 AM 4/19/2006, you wrote:
> >On Tue, 2006-04-18 at 08:51 -0300, ext Gustavo Sverzut 
> Barbieri wrote:
> > > Hello,
> > >
> > > Eagle (http://www.gustavobarbieri.com.br/eagle/) was ported to
> > > Maemo/Hildon 
> > (http://blog.gustavobarbieri.com.br/2006/04/eagle-in-maemo.html).
> >
> >In your blog you had mentioned this:
> >
> > > However I opted to not port every component, like 
> HildonColorButton
> > > or HildonNote because I think they're not well designed, 
> they don't
> > > even provide signal "changed", used by Eagle's DataWidget 
> to persist
> > > data automatically. As API will change in Maemo 2.0, I 
> won't bother
> > > with this until then.
> >
> >HildonColorButton and HildonNote APIs are not changing in 
> any signifcant
> >way, so don't let that stop you from including more widgets in the
> >supported list.
> >
> >Hildon-related API changes are more or less limited to HildonApp and
> >AppView and gtk_infoprint (and widgets no one was supposed 
> to be using
> >anyway)  See http://maemo.org/maemowiki/HildonWidgets for a bit more
> >details.
> >
> >
> >HildonColorButton doesn't need a specific "changed" signal, it is
> >already provided, though it's called "notify::color" and the callback
> >signature is slightly strange
> >(http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-B
ase-Object-Type.html#GObject-notify)
>(The older version of generated API documentation misses some crucial
>bits like signals and properties, the new API has slightly better
>generated documentation in
>https://stage.maemo.org/svn/maemo/projects/haf/doc/api/hildon-libs/HildonColorButton.html)
>
>It's a less known feature in GObjects that all properties have implicit
>"changed" signals associated with them. It has the benefit that you
>don't need multiple "foo-changed", "bar-changed", ... signals for
>complex objects.
>
>So the lack of "extra" signal is intentional and we plan to use the same
>design in new widgets as well, see HildonProgram for example.
>
>
>--
>Tommi Komulainen<[EMAIL PROTECTED]>
>
>___
>maemo-developers mailing list
>maemo-developers@maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers


Regards,

Shawn Gordon
President
theKompany.com
www.thekompany.com
www.mindawn.com
949-713-3276


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Maemp 1.2 SDK ?

[Devesh.Kothari]

Thats 
a mistake. 1.2 was indeed at 1 point in time planned to go out, but it didnt :) 
. It was meant as an incremental update to 1.1 with improvements in 
documentation and some new bug fixes etc. Documentation was pushed 
out. Then we decided to focus on 2.0 , as lots of major changes are coming 
through
 
Devesh
 

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]On Behalf Of ext Ade 
  BamigboyeSent: 18 April, 2006 16:26To: 
  maemo-developers@maemo.orgSubject: [maemo-developers] Maemp 1.2 SDK 
  ?
  Hi we can see the documentaion "Getting started 
  with multimedia in the Maemo 1.2 SDK".
   
  Can anyone tell us where to download the SDk 
  from.
   
  Thanks
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Building maemo from cvs

[Devesh.Kothari]

Murray

> -Original Message-
> From: ext Murray Cumming [mailto:[EMAIL PROTECTED]
> Sent: 31 March, 2006 15:21
> To: Kothari Devesh (Nokia-M/Tampere)
> Cc: maemo-developers@maemo.org
> Subject: RE: [maemo-developers] Building maemo from cvs
> 
> 
> On Fri, 2006-03-31 at 13:51 +0300, [EMAIL PROTECTED] wrote:
> > jhbuild is another beast, i have to learn something about :)
> > Devesh
> 
> I think you'll like it. It makes life simple. I should have some
> instructions up on the wiki soon.
> 
> I notice that some of the modules in svn (shared-mime-info, 
> dbus) don't
> have autogen.sh files, probably because they were added from tarballs.
> But jhbuild needs these files. May I add them, please?

work with Luc on that
Devesh

> 
> -- 
> Murray Cumming
> [EMAIL PROTECTED]
> www.murrayc.com
> www.openismus.com
> 
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Building maemo from cvs

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext Murray
> Cumming
> Sent: 31 March, 2006 12:45
> To: Kothari Devesh (Nokia-M/Tampere)
> Cc: maemo-developers@maemo.org
> Subject: RE: [maemo-developers] Building maemo from cvs
> 
> 
> On Fri, 2006-03-31 at 10:55 +0300, [EMAIL PROTECTED] wrote:
> > Murray,
> > Such a page would be welcomed.
> > 
> > Few things to consider
> > 1. Maemo 1.1 public release usually lag behind internal 
> product development
> > 2. what you see in SVN are realtime in sync (mostly) with 
> product development
> > 3. some of the time, these SVN projects like HAF (hildon 
> application framework) move on to new components versions or 
> new dependencies (due to new feature additions) which are not 
> in Maemo X.X public releases
> > 
> > So to build from scratch (i am throwing things from my head now :)
> > 1. get a empty scratchbox
> > 2. get a basic developer rootstrap from public maemo release
> > 3. set up the apt/sources.list to target the Maemo x.x repository
> 
> Ah, so is more than one set of packages in that repository? How can I
> discover which are available. I currently have this in my 
> sources.list:
> 
> deb http://repository.maemo.org/ maemo1.1rc5 free non-free
> deb-src http://repository.maemo.org/ maemo1.1rc5 free

deb http://repository.maemo.org/ maemo1.1 free non-free
deb-src http://repository.maemo.org/ maemo1.1 free

> 
> If we can get recent builds of the code currently being 
> worked on, then
> that helps a lot, but we will still need to build from cvs 
> too (usually
> to a separate prefix). For instance, many of the GNOME Developer use
> Ubuntu's unstable release (with the latest GNOME as released in
> tarballs) but also use jhbuild to develop the software that 
> can go into
> the tarballs.

Mostly what i am talking is a bootstrap process to bleed edge unstable
development.

once you have that (which makes you reach a point where all basic development
dependencies are satisfied), and keeps a clean development environment and 
process, 
then you can start pulling from SVN's and CVS's of the components you want to 
hack

So what I am outline is more of your unstable Maemo because Maemo yet dont have 
it :)
that is like ubuntu's unstable.
> 
> > 4. set up a local repository on host system(i prefer using 
> a localhost webserver), something like maemo unstable [this 
> is where all the new and updated components used by e.g HAF would go]
> 
> So you are talking here about a .deb/apt package repository 
> here rather
> than a svn repository?

Yes I meant apt/deb repository

> 
> > 5. Look into e.g HAF SVN and find (thats the hard part), 
> all the new dependencies introduced and updated components. 
> If the project itself dont provide them , then grab them from 
> mainstream and put them in local repo.

It would really help is projects like HAF would have some kind
of release process, which also outlines the build process together
with the dependencies and their versions.

> 
> Yes, this is something that the jhbuild modulesets should 
> show. I'd also
> like to see a page like this, with the module list for a 
> certain release
> phase, with branch names:
> http://live.gnome.org/TwoPointFifteen/Platform
> 
> > 6. Give your local repo preference over the Maemo repo. 
> [you can use tools like apt-ftparchive stuff to create you a 
> Packages.gz/Sources.gz etc]
> > 7. apt-get update, install etc
> > 8. get the latest SVN source, and then I think you have 
> possibility of some success :)
> > 9. once you create and compiled you packages from SVN 
> sources, upload them to you local repository.
> 
> This local apt repository only seems necessary in order to load the
> updated software onto the device. For working in scratchbox 
> and xephyr,
> it does not seem necessary.

Well it also keeps your development environment sane, and easy to 
reproduce e.g you move to another SB configuration etc.

> 
> > 9. To test : Grab developer rootfs from Maemo , and flash to device
> > 10. setup USB networking and modify the apt/sources.list to 
> also point to your local repo, and then the magic apt 
> dist-upgrade (who knows, it might work, at least the theory 
> sound reasonable, isnt it ?) 
> > 
> > Now here I am assuming when you say Maemo from scratch, you 
> mean Hildon Application Framework, which is in my terminology 
> just HAF, which sits on top of "Maemo Core" [which is all 
> base system, X, gdk, gtk, gconf etc etc]
> 
> Well, when we build the hildon-* libs, we also need to build Maemo's
> custom GTK+ version, for instance, so I think it makes sense 
> to call it
> Maemo.
> 
> I'm having some success with building HAF via jhbuild at the moment. 

jhbuild is another beast, i have to learn something about :)
Devesh

> 
> -- 
> Murray Cumming
> [EMAIL PROTECTED]
> www.murrayc.com
> www.openismus.com
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https

RE: [maemo-developers] Building maemo from cvs

[Devesh.Kothari]

Murray,
Such a page would be welcomed.

Few things to consider
1. Maemo 1.1 public release usually lag behind internal product development
2. what you see in SVN are realtime in sync (mostly) with product development
3. some of the time, these SVN projects like HAF (hildon application framework) 
move on to new components versions or new dependencies (due to new feature 
additions) which are not in Maemo X.X public releases

So to build from scratch (i am throwing things from my head now :)
1. get a empty scratchbox
2. get a basic developer rootstrap from public maemo release
3. set up the apt/sources.list to target the Maemo x.x repository
4. set up a local repository on host system(i prefer using a localhost 
webserver), something like maemo unstable [this is where all the new and 
updated components used by e.g HAF would go]
5. Look into e.g HAF SVN and find (thats the hard part), all the new 
dependencies introduced and updated components. If the project itself dont 
provide them , then grab them from mainstream and put them in local repo.
6. Give your local repo preference over the Maemo repo. [you can use tools like 
apt-ftparchive stuff to create you a Packages.gz/Sources.gz etc]
7. apt-get update, install etc
8. get the latest SVN source, and then I think you have possibility of some 
success :)
9. once you create and compiled you packages from SVN sources, upload them to 
you local repository.
9. To test : Grab developer rootfs from Maemo , and flash to device
10. setup USB networking and modify the apt/sources.list to also point to your 
local repo, and then the magic apt dist-upgrade (who knows, it might work, at 
least the theory sound reasonable, isnt it ?) 

Now here I am assuming when you say Maemo from scratch, you mean Hildon 
Application Framework, which is in my terminology just HAF, which sits on top 
of "Maemo Core" [which is all base system, X, gdk, gtk, gconf etc etc]

Hope that helps
Cheers

Devesh


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext Murray
> Cumming
> Sent: 29 March, 2006 20:42
> To: maemo-developers@maemo.org
> Subject: [maemo-developers] Building maemo from cvs
> 
> 
> Is there any documentation anywhere about building (and using) maemo
> from svn, installed in a separate prefix, or should I start a new page
> on the maemo wiki?
> 
> -- 
> Murray Cumming
> [EMAIL PROTECTED]
> www.murrayc.com
> www.openismus.com
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] SDK upgrade failed

[Devesh.Kothari]

True,
Sorry for confusion :)true, I had even older SB ;) 0.9.8.4 and then i upgraded 
to 0.9.8.5
and my troubles were with dist upgrade, not getting to start the env 

My mistake !
Devesh


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext Ferenc
> Szekely
> Sent: 29 March, 2006 09:36
> Cc: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] SDK upgrade failed
> 
> 
> Hello,
> 
> You have/had some different problems. Maemo 1.1 works with
> scratchbox 0.9.8.5 and the newer version was never required.
> 
> Nils:
> which version did you have before you did the upgrade? 1.0 or 1.1 RC5?
> 
> Cheers,
> ferenc
> 
> ext [EMAIL PROTECTED] wrote:
> > I had similar problem but then i noticed that I am supposed 
> to be using 0.9.8.6 and that solved it.
> > 
> > Devesh
> > 
> > 
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> [mailto:[EMAIL PROTECTED] Behalf Of ext 
> >> Nils Faerber
> >> Sent: 28 March, 2006 18:02
> >> To: maemo-developers@maemo.org
> >> Subject: [maemo-developers] SDK upgrade failed
> >>
> >>
> >> Hi!
> >> I just upgraded my SDK setup to scratchbox 0.9.8.5 and SDK 
> >> rootstrap to 1.1.
> >> After that I cannot start the GUI environment anymore:
> >>
> >> [sbox-i386: ~/bin] > af-sb-init.sh start
> >> Note: For remote X connections DISPLAY should contain hostname!
> >> Sample files present.
> >> Starting Maemo Launcher: maemo-launcher.
> >> Starting DBUS system bus
> >> Starting D-BUS session bus daemon
> >> Error loading /usr/bin/dbus-daemon-1
> >> Error loading /usr/bin/dbus-daemon-1
> >> Starting Sapwood image server
> >> Error loading /usr/lib/sapwood/sapwood-server
> >> Starting Matchbox window manager
> >> Error loading /usr/bin/matchbox-window-manager
> >> Starting Keyboard
> >> Error loading /usr/bin/hildon-input-method
> >> Starting MAEMO AF Desktop
> >> [sbox-i386: ~/bin] > Error loading /usr/bin/maemo_af_desktop
> >>
> >>
> >> Any idea what is wrong now?
> >>
> >> Cheers
> >>   nils faerber
> >>
> >> -- 
> >> kernel concepts  Tel: +49-271-771091-12
> >> Dreisbachstr. 24 Fax: +49-271-771091-19
> >> D-57250 Netphen  Mob: +49-176-21024535
> >> --
> >> ___
> >> maemo-developers mailing list
> >> maemo-developers@maemo.org
> >> https://maemo.org/mailman/listinfo/maemo-developers
> >>
> >>
> >> 
> --
> --
> >>
> >> ___
> >> maemo-developers mailing list
> >> maemo-developers@maemo.org
> >> https://maemo.org/mailman/listinfo/maemo-developers
> 
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Alarm/wake-up?

[Devesh.Kothari]

Sorry for not being able to update on this. Alarm/Notifier interface is now 
part of the roadmap. Exact delivery implementation schedule is difficult to 
say, but my guess would be around August/3Q time frame (maybe early access 
releases too :)


Alarm sub system basic features

1.API for developer to use Alarm/Notifier Interface
   - Schedule/Cancel Alarm (multiple and multiday alarms)
   - Ability to register callback handler
2 Ability to deliver Alarm
3 Ability for device wakeup on Alarm expiry

I thank everyone who participated on that discussion thread.
Devesh




> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext Damien
> Challet
> Sent: 28 March, 2006 17:20
> To: maemo-developers@maemo.org
> Subject: [maemo-developers] Alarm/wake-up?
> 
> 
> Dear All,
> 
> Since the January discussion about how to implement an alarm, 
> what is the 
> present situation regarding this matter? I am thinking of 
> buying a 770 to 
> replace my Palm, but not before it is able to wake up 
> spontaneously and beep 
> loudly.
> 
> Damien
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] SDK upgrade failed

[Devesh.Kothari]

I had similar problem but then i noticed that I am supposed to be using 0.9.8.6 
and that solved it.

Devesh


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext 
> Nils Faerber
> Sent: 28 March, 2006 18:02
> To: maemo-developers@maemo.org
> Subject: [maemo-developers] SDK upgrade failed
> 
> 
> Hi!
> I just upgraded my SDK setup to scratchbox 0.9.8.5 and SDK 
> rootstrap to 1.1.
> After that I cannot start the GUI environment anymore:
> 
> [sbox-i386: ~/bin] > af-sb-init.sh start
> Note: For remote X connections DISPLAY should contain hostname!
> Sample files present.
> Starting Maemo Launcher: maemo-launcher.
> Starting DBUS system bus
> Starting D-BUS session bus daemon
> Error loading /usr/bin/dbus-daemon-1
> Error loading /usr/bin/dbus-daemon-1
> Starting Sapwood image server
> Error loading /usr/lib/sapwood/sapwood-server
> Starting Matchbox window manager
> Error loading /usr/bin/matchbox-window-manager
> Starting Keyboard
> Error loading /usr/bin/hildon-input-method
> Starting MAEMO AF Desktop
> [sbox-i386: ~/bin] > Error loading /usr/bin/maemo_af_desktop
> 
> 
> Any idea what is wrong now?
> 
> Cheers
>   nils faerber
> 
> -- 
> kernel concepts  Tel: +49-271-771091-12
> Dreisbachstr. 24 Fax: +49-271-771091-19
> D-57250 Netphen  Mob: +49-176-21024535
> --
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] gtk+ builtin stock icons removed

[Devesh.Kothari]

Is it possible to have these extra icons and stuff application installable 
package ???

Br,
Devesh


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext 
> Florian Boor
> Sent: 26 October, 2005 20:32
> To: Komulainen Tommi (Nokia-M/Helsinki)
> Cc: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] gtk+ builtin stock icons removed
> 
> 
> Hello,
> 
> Tommi Komulainen wrote:
> > This message was brought to you by the performance police. 
> The builtin
> > stock icons compiled in the gtk+ library are causing extra 
> >30k dynamic
> > memory consumption regardless of whether they're ever used. 
> In 770 all
> > icons are coming from the icon theme anyway, so this is a cheap and
> > simple optimization to do. And everyone loves to have better
> > performance, right? :)
> 
> i don't think 30k is worth making it a major pain maintaining 
> applications which
> support both plain GTK and Hildon UI. But that's my personal opinion.
> In addition to this you loose a pile of convenient functions 
> to deal with the
> stock icons. UI guidelines (e.g. the Gnome HIG) suggest to 
> use a set of well
> known symbols for common operations which is a really good 
> idea if you want
> users to feel familiar with their applications - another 
> important feature you
> will loose with this.
> 
> My suggestion: Forget about this as long as you don't offer a 
> similar feature to
> replace the builtin stock icons. It might be a good idea to 
> modify GTK in a way
> that only the the stock icons used by an application are kept 
> in memory instead
> of compiling them into the library.
> Additionally it might be a good idea to replace the builtin 
> icons with maemo
> style icons... currently some of them look pretty good (like 
> the arrows, useful
> to replace the broken GtkArrows in the default theme), but 
> some look very different.
> 
> Greetings
> 
> Florian
> 
> -- 
> The dream of yesterday  Florian Boor
> is the hope of todayTel: 0271-771091-14
> and the reality of tomorrow.Fax: 0271-771091-19
> [Robert Hutchings Goddard, 1904][EMAIL PROTECTED]
> 
> 6C 44 30 4C 43 20 6B 61  16 07 0F AA E6 97 70 A8
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] So you need more documentation?

[Devesh.Kothari]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext Karoliina
> Salminen
> Sent: 18 July, 2005 00:36
> To: kimmo.virtanen
> Cc: maemo-developers@maemo.org
> Subject: Re: [maemo-developers] So you need more documentation?
> 
> 
> kimmo.virtanen wrote:
> 
> >
> >
> > Hi,
> >
> > I was able to test real N770 at debconf (thanks Kate and 
> Katariina :) ).
> 
> It was a pleasure to show the device :). Besides of that my name is 
> Karoliina by the way :).
> 
> > Anyway there isn't in net really any information how much 
> actual end 
> > user version devices differs from Nokias internal stuff in hackable 
> > point of view.
> 
> If you want just pure hacking, you could do with the maemo rootimage. 
> You was going to use it for some
> automation, so it is for that purpose fully hackable by 
> reflashing the 
> device. All you need to reflash the device.
> 
> > So are end users/3rd party developers who are buying their devices 
> > from stores able to login as root in their device, update its inner 
> > software or compile new kernel etc?
> 
> You need to reflash the device with the development rootimage 
> for that.
> The development rootimage is downloadable from the maemo.org. 
> There is a 
> limitation
> in that however, it can not contain license incompatible proprietary 
> software of course because it is freely
> available to anyone and for any device.

the development rootimage is not yet part of maemo.org and this is something
we working on. There is also some working going on Open Embedded integration.
http://downloads.kernelconcepts.de/maemo-oe.txt

br,
devesh

> 
> > Or is it in some kindergarden mode 
> 
> By default it is with certain limitations for the non-developer end 
> users, pls see above.
> 
> > which prevents user from breaking device or more advanced 
> people from 
> > modding it?
> >
> > Though 770 is not maemo, it is just first device for using 
> sdk, but in 
> > maemo webpages there is mostly info for making user-mode apps so if 
> > it's planned that platform is wide open then it would be 
> nice that in 
> > documentation there would be some info about deeper 
> modification also 
> > , or if sdk is just for user apps not then least some 
> comment about it.
> 
> The maemo can be as complete as you make it, currently the 
> maemo is not 
> as complete
> as the Nokia version. However, all you need to do to make it equal or 
> better is to start the implementation part :).
> You can compile anything in the scratchbox environment and hack 
> anything. You just can not
> do all that for the Nokia version - there are some 
> limitations in that.
> 
> >
> > So if here is somebody from Nokia who could answer this one.. ?
> 
> I am (still) on summer vacation, so answering from private e-mail.
> 
> Best Regards,
> Karoliina
> 
> 
> >
> > -- Kimmo
> >
> >
> > On Fri, 15 Jul 2005, Tommi Komulainen wrote:
> >
> >> Hi,
> >>
> >> I created a page in the wiki to collect documentation that 
> you feel is
> >> currently missing. So instead of banging your head to the 
> wall because
> >> there's nothing but a big bunch of undocumented features 
> you should head
> >> to the wiki and write down your concerns. That way we could get a
> >> better idea what is really needed rather than us guessing 
> what might be
> >> useful.
> >>
> >> The page is at http://maemo.org/maemowiki/DocumentationWanted
> >>
> >> I added UI guidelines as a skeleton example as it was 
> mentioned earlier
> >> on this list, but you'll probably want to elaborate it.
> >>
> >>
> >>
> > ___
> > maemo-developers mailing list
> > maemo-developers@maemo.org
> > https://maemo.org/mailman/listinfo/maemo-developers
> >
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] gtk+ and gnome-vfs, upstreamable or a fork?

[Devesh.Kothari]

idea is to move and merge as much as possible to mainstream, but for some 
changes it might be easy and some difficult, so this is a goal but IMHO would 
not happen for some time, especially some of the changes might make sense only 
for the embedded devices UI and hildon in particular and more difficult to pass 
and accepted in mainstream.

Devesh


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of ext Koen Kooi
> Sent: 31 May, 2005 15:57
> To: maemo-developers@maemo.org
> Subject: [maemo-developers] gtk+ and gnome-vfs, upstreamable 
> or a fork?
> 
> 
> Hello,
> 
> After poking through the patches, it seems both the gtk+ and gnome-vfs
> found in the repository require some incarnation of osso. I would like
> to use maemo apps on my Sharp Zaurus with a stock gtk+ and
> gnome-vfs-dbus, but that's not possible at the moment.
> Is it planned to clean up gtk+ and gnome-vfs, get patches 
> into upstream
> and use stock versions in later maemo releases, or will you 
> effectively
> fork gtk+ and gnome-vfs?
> 
> regards,
> 
> Koen
> 
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
> 
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers