RE: Any early QtWRT adopters flying with us?
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.cohttp://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
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
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...)
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] Too busy to accept help? I'm not complaining
-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 other hand, desktop users are used to crappy software and expect all the latest whizbang USB
RE: [maemo-developers] Too busy to accept help? I'm not complaining
-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] GMP - available on 770?
-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
-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] Maemo 2.0 API changes, signals andproperties (was: ANN: Eagle)
-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] Maemo 2.0 API changes, signals and properties
-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] Too busy to accept help? I'm not complaining
-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 benefits of one technology over another here, I'm simply making the point of how the business was and was not well handled in my opinion. Regards, Philippe -- |
RE: [maemo-developers] Too busy to accept help?]
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] Maemp 1.2 SDK ?
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
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
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] SDK upgrade failed
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] gtk+ builtin stock icons removed
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
