Re: [MeeGo-dev] Is this a reliable way for app to know it's running on MeeGo Tablet vs. Netbook?
On Tuesday 30 August 2011 10:27:52 you wrote: > > And it starts with a QWidgets UI to maintain compatibility with Qt4.6, > > then switches to declarative if it is run on Qt4.7 and finally to a > > components based UI. > > That's not so easy. Let's take three MeeGo alternatives. MeeGo 1.2 > Harmattan Handset with swipe UI, MeeGo 1.2 Handset UI and MeeGo tablet UI. > All these have components based UI but different UX I think this is a separate issue - we were just talking about detecting and using the proper UX tech. The difference *between* the particular UX-es (and corresponding UX guidelines) is a different story. To draw a parallel - if your application comes with both a Qt and a GTK UI, the right way to launch the proper front-end would be to check for KDE/Gnome and Qt/GTK availability, not whether the application was run on Ubuntu, Kubuntu, XUbuntu, etc, or, worse yet, if it was an eeePC or ExoPC or... you get the idea On a side note: QtInfo *does* go to extreme lengths to be able to run on anything that has Qt 4.6 (maybe even Qt 4.5) all the way to a components based UI *with the same package/binaries*. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Is this a reliable way for app to know it's running on MeeGo Tablet vs. Netbook?
On Tuesday 30 August 2011 03:37:49 you wrote:
> The issue is that this suggestion doesn't tell the appropriate
> information, after all, this is about sofware, not hardware. For
> example, I could be running the tablet UX on the Lenovo s10-3t instead
> of Netbook UX. If that was the case, I'd want the nonstandard
> "tablet" way of handling, framing /decorating, and window-managing
> applications; if the application finds itself on a desktop or netbook
> UX, I'd use code that attempted
> http://standards.freedesktop.org/wm-spec/latest/ compliance.
>
> Is there some "portable" Qt or QML code to do this? or a
> meego-compatible equivalent of http://apidocs.meego.com/1.2/qmsystem/
> -- which is present on Nokia's Harmattan but appears missing from
> MeeGo. Otherwise using
> http://apidocs.meego.com/1.2/qmsystem/classMeeGo_1_1QmKeys.html seems
> like a potential API for your suggestion.
The mantra I hear is 'check for features', and in that vein you have
mobility's QSysInfo for hardware (i.e. check for keyboard), and for software
you could do something like
QDeclarativeEngine engine;
QDeclarativeComponent component(&engine);
component.setData(QLatin1String("import QtQuick 1.0\nimport com.nokia.meego
1.0\nWindow {}"), QUrl());
QDeclarativeItem *item = qobject_cast(component.create());
if (item) {
// load com.nokia.meego based ui
}
There is a project that has a dynamic UI selection based on tricks like the
above one:
http://projects.developer.nokia.com/qtinfo
And it starts with a QWidgets UI to maintain compatibility with Qt4.6, then
switches to declarative if it is run on Qt4.7 and finally to a components based
UI.
Best regards,
Attila Csipa
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] apps.formeego.org == Fedora reloaded ?
http://en.wikipedia.org/wiki/Fedora_%28operating_system%29 "The Fedora Project was created in late 2003, when Red Hat Linux was discontinued. The name of Fedora derives from Fedora Linux, a volunteer project that provided extra software for the Red Hat Linux distribution, and from the characteristic fedora used in Red Hat's "Shadowman" logo. Warren Togami began Fedora Linux in 2002 as an undergraduate project, intended to provide a single repository for well-tested third-party software packages so that non-Red Hat software would be easier to find, develop, and use. The key difference between the approaches of Fedora Linux and Red Hat Linux was that Fedora's repository development would be collaborative with the global volunteer community.[13] Fedora Linux was eventually absorbed into the Fedora Project, carrying with it this collaborative approach." Can we learn something from Fedora's history (and relation to RedHat) that will help us resolve the current situation around LF's decision and apps.formeego.org ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] File manager for Tablet Edition
On Saturday 02 July 2011 21:12:40 you wrote: > Why should > a document reader manage all my docs? Why should a pdf reader manage all > my pdf files, why should a media player manage all the audio/video for me? > Is the notion to "browse" your device all dead in these times? Cant I just > pick up my 64gb device with the intention of seeing what I have stored in > all these months of it in my ownership? In this scenerio I am picking up The point was that the lack of a file manager that directly exposes the file system DOES NOT imply that you need to manage content from content specific applications. To play devil's advocate a bit - people seem to forget that tag/content based browsing is a lot more persistent than filesystem browsing - if I use a MacBook, a MeeGo tablet and a Win7 desktop PC, do I really need to know the file hierarchy on all three even if I use the exact same applications/services on them ? iOS does this suckily - but that does not mean the goal or idea itself is flawed. Thus, consider carefully whether the "I need" in the statements does not originate at least a little bit from "I'm used to". /me ducks and hides in the trenches of his command line Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] File manager for Tablet Edition
On Saturday 02 July 2011 01:43:38 you wrote: > Stop trying to think in place of a pseudo average joe but instead try > to create things that are useful for you and the normal users will > follow. Can I use this as an excuse whenever somebody asks "why do I have to go to the command line/edit conf files" ? :) Arjan mentioned Apple as one example of this "Just works" and at the same time never too far from being hackable. The question is, as usual, how wide you can stretch your acceptance band. By now, it should be clear you can't have one interaction paradigm that will rule all, users, developers and random bystanders alike. The real problem is, thus, not that paradigm A or paradigm B is better or worse for a group of users, but that you limited yourself to ONE (usually along the lines of grab much, gain little) approach in the name of simplicity. > To come back at the subject of the need of a file browser, lets > suppose that you had a trip in a foreign country with friends and that > now you want to show them all that you have from the trip. Will you > prefer to have one folder with all the videos, photos, pdf scan of > documents or to open the photo viewer to show them the photos, then go > to the video player to browse the videos then to the pdf viewer to > browse the pdfs, then to go back in all those applications to export > to an usb key or import these data? This is more of a filesystem philosophy argument - what you want for these use cases is a tag-based filesystem (with another argument, how to get the tags there without annoying the user). You assumed one use-case here, but that works only as your context is "the trip" and "ALL data". What if you were looking for "pictures/videos of John", or have pictures in there that will get you on the sofa if the wife doesn't get to deselect them. The bottom line being is that a directory is an okay method for grouping data - it's just that it has the same limitations as it did 30 years ago, so trying to find better ways to organize data is not necessarily bad (with the caveats from my previous paragraph). Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Fwd: Call for ideas - preprocessor #define for meego version (Q_MEEGO_VER ?)
On Tuesday 14 June 2011 00:56:08 you wrote: > On 13 Jun 2011, at 22:30, Ville M. Vainio wrote: > > We all know and love Q_WS_MAEMO_5 and Q_OS_SYMBIAN for getting work done. > > > > However, as everybody ends up seeing,, there is no equivalent for meego. > > What do you want it for? MeeGo is Linux, it isn't an operating system. It doesn't matter if it's an OS or not. Whatever it is, it has *compliancy specifications*. It means that stuff HAS to be done in a certain way. No amount of feature-detection will tell you the required naming schemes, dependency rules and such. In fact, fancy target-agnostic feature detection will/can actually HURT you, because maybe your package could have been MeeGo API compliant, but you detected some lower level libs in there and included non- essential functionality that downgraded you to Platform API compliance. Therefore, when a package (or even executable !) is built is -HAS- to know that the target is MeeGo (OS, platform, kingdom, you name it) so that it could abide by the rules and create a proper package with the desired level of compliancy. Sure, I can prefix/inject a DEFINE in my qmake, but then what's the point in a multiplatform build system if I need to wrap in a multiplatform wrapper script. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Reference UX independent axis orientation
On Wednesday 08 June 2011 15:09:03 you wrote: > On Wed, Jun 8, 2011 at 13:00, wrote: > > Admittedly, sticking to ALWAYS-PORTRAIT default orientation kind-of > > solves the problem too. Taking into account the wide variety of devices > > that has been developed in the past and hopefully will be developed in > > the future, sticking to any pre-decided orientation cannot IMO be done. > > (And we already now conflict with the principle: Dali and Lankku, > > portrait, N900 landscape) > > As an application developer I want *Qt* to define a standard and be > able to program to that. Currently, that standard is poorly defined > with Symbian & MeeGo having sensors oriented to a vertically standing It's the MeeGo one sticking out, my tablet UX uses the same layout as Maemo5's mobility did originally. Symbian is also not an entirely clean case because there are devices that are portrait while having width > height (f.e. the E6). My biggest problem is that the definition is unclear (you have the image which do not define exactly what happens where on all verticals - even Pia's explanation, while better, is not perfect, what happens if there are multiple screens or if the device can be flipped open/transformed), and this seems to spawn device-specific defaults, which in turn create all these legacy cases (will MeeGo do the same putenv hack as the N900 to keep compatibility with existing applications in, say, AppUp ? Will the willingly choose the default that defies ALL Nokia devices ?). There is already too much per-device ifdeffing... Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Reference UX independent axis orientation
Hi, How does MeeGo feel about axis orientation in various UX-es ? There is a a reference at http://doc.qt.nokia.com/qt-mobility- snapshot/qaccelerometerreading.html but the axis names there are prone to interpretation, see for example the Tablet UX, which follow the original (but now sort-of deprecated) N900 style orientation (X for the wider axis). Note: This is not about portrait vs landscape UI - this is about linking the readings with physical device positions. Thoughts ? See also: http://bugreports.qt.nokia.com/browse/QTMOBILITY-1073 http://bugreports.qt.nokia.com/browse/QTMOBILITY-1044 Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] (not) refocusing meego-dev, was: Re: Howto lock screen orientation in MeeGo/Tablet 1.2 ?
On Monday 09 May 2011 18:22:17 you wrote: > > This has been discussed - and agreed before - but the changes never > > seemed to happen :-( > > The suggestion to rename the mailing lists was discussed but never > agreed to. I, for one, don't believe that renaming the list will solve the Just out of curiosity, who exactly needs to agree (or, to put it another way, who disagreed) ? I kind of recall pretty much everybody either agreeing or at least liking the idea at some point (see http://lists.meego.com/pipermail/meego-dev/2010-August/005082.html ) but then the whole thing seem to have taken a U turn somewhere off-list between that moment and the message you linked to. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo compliance and Qt Commercial license
On Monday 02 May 2011 16:50:32 you wrote: > the tools are there to help you make sure your bugfixes didn't > accidentally break things. They're not there to be watertight against > breaking the compliance rules by someone who wants to cheat the rules. One thing though - the original question was if you can *switch* licenses, and that situation is pretty clear. However, is there anything that would prevent you from having two sets of Qt libraries, on one side the stock LGPL ones, and a parallel set of packages, which would be the commercially licensed one (in a separate path, no dependency relations to the LGPL libs, etc), which you could use/customize for whatever you want to do with it within your blend of MeeGo, without affecting compliancy and/or compatibility ? Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Idle hands are the devil's tools, aka the MeeGo SDK installer
On Friday 25 March 2011 22:58:11 you wrote: > Absolutely, thanks for letting us know and taking the time to dig a bit > deeper into the issue. > > I do encourage you to file a bugzilla so this can be tracked, so that > this e-mail isn't the last one you will ever hear about that Sure thing, filed https://bugs.meego.com/show_bug.cgi?id=14925 (under SDK/Other until I find a better spot for it). Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Idle hands are the devil's tools, aka the MeeGo SDK installer
Please do. I would also recommend a *thorough* review for the whole script.
Checking the source further didn't instill confidence, for example it
happily does
rm -rf ${MADDE_PATH}/bin
without ever checking if MADDE_PATH is empty (this runs as root...). Yes,
there are different checks in place so it takes a perfect storm for this to
cause damage, but why not play it safe ? In other news, I'm trying to file a
bug report but the SDK installer seems to lack a component in the bugzilla
(or at least I can't quite find it)... Meta-bug time !
Attila
On Fri, Mar 25, 2011 at 8:54 PM, Foster, Dawn M wrote:
>
> On Mar 25, 2011, at 11:31 AM, Attila Csipa wrote:
>
> > Warning. Agitated rant ahead.
> >
> >
> > In a moment of Friday afternoon boredom following a tweet about a certain
> competition I decided to check out the state of the 'official' offering and
> got the Linux install from
> http://appdeveloper.intel.com/en-us/meego-sdk-suite. Smallish thing, an
> installer I think to myself, okay... Are you sure ? Of course I'm sure. It
> says it wants sudo and stuff... well, okay, I would have preferred to do the
> apt-getting myself if that's what it does anyway... I know, what kind of
> idiot sudos some random installer from the Internet... Well, I did happen to
> have a previous install on my otherwise bog-standard Lucid hack-machine and
> the installer happily offers to remove 6-7 packages from that. Says continue
> with existing not recommended, well, okay, then proceed with remove... And
> yes, I know, that's a double fail, I asked for it (cue laugh). As it turns
> out, the eager beaver installer apt-get bloody *force* removed pretty much
> all of my Kubuntu install, all the way down to kdm. WTF ? But you said just
> 6-7 packages... (haha, sucker !). But a fail is a fail only if you don't
> learn from it, so let's see what we can learn from this incident (apart from
> saying 'no thanks' to stupid sudo-requiring installers even if they come
> from official sources). Checking out the installer script you can see what
> caused the meltdown:
> >
> > echo " MeeGo SDK components found."
> > echo $PKGS
> > setFontColor "red"
> > echo -e " The following packages are installed and will be uninstalled\n"
> \
> > "prior to installing the MeeGo SDK:"
> > echo " $PKGS"
> > setFontColor "blue"
> > echo -e " Would you like to uninstall all previously " \
> > "installed MeeGo SDK components now?\n" \
> > "\t(u)ninstall now\n" \
> > "\t(s)kip uninstall and proceed (not recommended)\n" \
> > "\t(e)xit installation"
> > read -p " Select option (u/s/e): "
> > setFontColor "default"
> > if [ "$REPLY" == "u" ] && [ "$REPLY" != "U" ]; then
> > if [ "$OS" == "Ubuntu" ]; then
> > apt-get autoremove -y $PKGS \(is this safe / necessary ?)
> >
> > I don't know who asked that there, but let me answer. I don't know if
> it's necessary, but it's VERY not safe (I'll refrain from using derogatory
> terms this time). You display the packages YOU want to uninstall and then
> tell apt to remove whatever IT thinks is right (along with, you know,
> dependencies). What the frack happened to apt-get --just-print (dry-run) and
> then proceeding ? And I thought the QtSDK is sometimes a bit rough around
> the edges and people are sometimes too heavy criticizing error-prone SDK
> setups... but that's peanuts compared to this monster-fail, seeing apt kill
> your install was not a pleasant sight (now I know how people accidentlaly
> typing rm -rf / feel). Not. Frackin'. Funny. At. All. Sorry about the
> agitated mail, now I have the weekend fun of a devel machine to setup,
> instead of doing something productive like the initial idea from an hour ago
> of publishing something to AppUp developer challenge by using the official
> tools in the process. I guess you can call that learning the hard way. End
> of rant. And have a nice day.
> >
>
> I'm looking into this now to get that installer pulled off of the website
> and fixed.
>
> Dawn
>
>
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Idle hands are the devil's tools, aka the MeeGo SDK installer
Warning. Agitated rant ahead. In a moment of Friday afternoon boredom following a tweet about a certain competition I decided to check out the state of the 'official' offering and got the Linux install from http://appdeveloper.intel.com/en-us/meego-sdk-suite. Smallish thing, an installer I think to myself, okay... Are you sure ? Of course I'm sure. It says it wants sudo and stuff... well, okay, I would have preferred to do the apt-getting myself if that's what it does anyway... I know, what kind of idiot sudos some random installer from the Internet... Well, I did happen to have a previous install on my otherwise bog-standard Lucid hack-machine and the installer happily offers to remove 6-7 packages from that. Says continue with existing not recommended, well, okay, then proceed with remove... And yes, I know, that's a double fail, I asked for it (cue laugh). As it turns out, the eager beaver installer apt-get bloody *force* removed pretty much all of my Kubuntu install, all the way down to kdm. WTF ? But you said just 6-7 packages... (haha, sucker !). But a fail is a fail only if you don't learn from it, so let's see what we can learn from this incident (apart from saying 'no thanks' to stupid sudo-requiring installers even if they come from official sources). Checking out the installer script you can see what caused the meltdown: echo " MeeGo SDK components found." echo $PKGS setFontColor "red" echo -e " The following packages are installed and will be uninstalled\n" \ "prior to installing the MeeGo SDK:" echo " $PKGS" setFontColor "blue" echo -e " Would you like to uninstall all previously " \ "installed MeeGo SDK components now?\n" \ "\t(u)ninstall now\n" \ "\t(s)kip uninstall and proceed (not recommended)\n" \ "\t(e)xit installation" read -p " Select option (u/s/e): " setFontColor "default" if [ "$REPLY" == "u" ] && [ "$REPLY" != "U" ]; then if [ "$OS" == "Ubuntu" ]; then apt-get autoremove -y $PKGS \(is this safe / necessary ?) I don't know who asked that there, but let me answer. I don't know if it's necessary, but it's VERY not safe (I'll refrain from using derogatory terms this time). You display the packages YOU want to uninstall and then tell apt to remove whatever IT thinks is right (along with, you know, dependencies). What the frack happened to apt-get --just-print (dry-run) and then proceeding ? And I thought the QtSDK is sometimes a bit rough around the edges and people are sometimes too heavy criticizing error-prone SDK setups... but that's peanuts compared to this monster-fail, seeing apt kill your install was not a pleasant sight (now I know how people accidentlaly typing rm -rf / feel). Not. Frackin'. Funny. At. All. Sorry about the agitated mail, now I have the weekend fun of a devel machine to setup, instead of doing something productive like the initial idea from an hour ago of publishing something to AppUp developer challenge by using the official tools in the process. I guess you can call that learning the hard way. End of rant. And have a nice day. Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Academic Survey for MeeGo Community Contributors
On Monday 29 November 2010 23:29:07 you wrote: > Did you get express permission from the MeeGo community council (Dawn, > Quim, etc?) to post this to this list? On a side note (I know you know), just to point out before some people get confused, there is (sadly) no such thing as a MeeGo community council. maemo.org has a community council and Dawn/Quim are not related to it. As for the rest of this thread, I would like to point to an excellent session we had on the conference - http://conference2010.meego.com/session/community- anti-patterns and would leave the task of finding just how many of these are present in this thread as an exercise to the reader. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] NQS vs MeeGo SDK [Re: MeeGo 1.1 SDK beta released]
On Thu, Nov 11, 2010 at 12:05 PM, Ville M. Vainio wrote: > On Thu, Nov 11, 2010 at 11:43 AM, Attila Csipa wrote: > > > these targets). That said, I would really like to see a properly packaged > > NQS not just a blob installer. > > I've thought of this as well, but ended up with the conclusion that it > wouldn't be all that valuable. > > Think of NQS like you think of Eclipse - it's a framework for running > plugins that you manage within the application itself. Packaging > system has very little to offer for an application like that. Since > NQS has to serve users of lesser operating systems as well (Windows > and Mac), such a component manager needs to exist anyway. Making a > separate solution for Debian/Ubuntu would be nice for those users, but > would overall deliver so little value that it's not worth the effort. > > Not necessarily a completely inpendent solution, just something that plays along perhaps a bit more nicely with the rest of the OS. In case of Ubuntu, I would, for example, be happy to be able to use triggers on those updates, to install the NQS for all users without tweaking, having a proper relation between VCSs and QtCreator... that sort of stuff. Nothing major, just something that minimizes the itches. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] NQS vs MeeGo SDK [Re: MeeGo 1.1 SDK beta released]
On Thu, Nov 11, 2010 at 10:48 AM, Andrew Flegg wrote: > I think the distinction *is* useful as Ubuntu (and I don't know about other > distros) has a Qt Creator package. I'd rather manage my packages through the > system utilities (even if it's a PPA), rather than Windows-style "Update > $APP" menu entries. > IIUC The biggest problem with that is support - the version of QtCreator means little in terms of what targets you are actually using in there (the distro supported one is usually limited to the desktop Qt version the distro ships with). However, if you decide you want to use THAT QtCreator with Maemo5/6/MeeGo1.1/1.2/SymbianS60/S3/YouNameIt targets, it suddenly gets very very murky (esp since there is no Qt version/feature equivalency across these targets). That said, I would really like to see a properly packaged NQS not just a blob installer. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Minimal RAM requirements for MeeGo-Handset UX
On Wed, Oct 13, 2010 at 9:41 PM, Auke Kok wrote: > > I fail to see what the motivation of your post is... > > Would you like me to program MeeGo so that it tests the memory size and > stops the boot process if the memory size doesn't adhere to the compliance > spec? > I merely wanted to point out the difference between the dicussion about profile requirements (I recall the OP's initial question being what the handset profile *required* RAM minimum is) as opposed to the subjective measure of device usability in terms of particular hardware. If this makes no sense, I apologize and disregard my mail, I did not mean to hijack the thread. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Minimal RAM requirements for MeeGo-Handset UX
On Wed, Oct 13, 2010 at 8:15 PM, Auke Kok wrote:
>
> I also don't think there's an official stance on the amount of memory
> required to ""run MeeGo"". In general, with 512mb most devices see a lot
> better performance than with 128mb, so you can draw your conclusions on
> whether it's 'good enough' for everyone or just 'good enough' for *you*.
>
>
It has been previously stated[0] that the MeeGo compliance specs will
contain exactly that - strictly defined minimum hardware req for particular
profiles in order to call them compliant ('real', if you wish). Even the OP
formulated the question like that by saying 'minimum RAM required'. With
enough hackery, you certainly could get MeeGo (and Linux in general) to run
on very modest hardware or benefit from extra memory, but the question is
what the official number for a particular device profile is (it's a
different story that we don't have those numbers officially yet, just saying
that 'how high/low can you hack/endure it' was not really how I understood
the question).
[0] http://lists.meego.com/pipermail/meego-dev/2010-September/005963.html
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Refocusing mailing lists, was: Re: A note "SIGSEGV" pop up when using QToolBar
On Mon, Sep 27, 2010 at 6:16 PM, Foster, Dawn M wrote: > > MeeGo application development questions should be posted > in the meego-sdk mailing list. Here is a page with clear descriptions > of each mailing list and which ones to use for which types of > questions: > http://wiki.meego.com/Community_communication > > I believe there was a general agreement that it might be beneficial if the lists were renamed to maybe better reflect their focus area and intended target audience, thereby lessening the number of misplaces posts. Are there any obstacles to making that idea a reality and if so, can we help somehow ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [compliance] Different view on app compliance
On Tue, Sep 21, 2010 at 3:05 PM, Jeremiah Foster < jeremiah.fos...@pelagicore.com> wrote: > >> Can applications using non-OSS libraries from 3rd parties be compliant? > > > > No - if someone uses for example Nokia Ovi Store specific APIs, how > > can this expect to run on all MeeGo devices? > > Except of course if Nokia uses Nokia specific APIs, then it is > automatically compliant. > It doesn't matter - it would if the non-OSS libraries (regardless if they are vendor or 3rd party) were packaged in a non-braindead manner, but with the proper licensing clause, you can make perfectly compliant packages, in your project file you just += the blob .so that contains the API and voila ! You have a perfectly compliant MeeGo app (the fact that it might actually be breaking your compatibility promise is a different matter). In fact, it seems that to allow 'inclusion of non-OSS libraries from 3rd parties' is one of the main reasons why the compliance was drafted as it was - you're not expected to be (re)using OSS components (apart from those that make up the MeeGo API itself) anyway :( Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Creating a Python project for MeeGo
On Mon, Sep 20, 2010 at 10:28 PM, Arjan van de Ven wrote: > PyGTK is not part of the core and not part of the compliance set for > example... > > Since I got quoted - the point is if Qt is you official toolkit and you are already having Python in Core (as compliancy does specify Python) then having the Python binding for Qt in Core is a no-brainer. The only real discussion can IMHO be about the maturity and hence the timeline of inclusion. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Creating a Python project for MeeGo
On Mon, Sep 20, 2010 at 8:26 PM, Matti Airas wrote: > > In my opinion, Core OS, absolutely. There's already a world of pain in > Maemo 5, with Python being just in Extras and thus effectively prohibited > from Ovi Store. Yet, 20% of maemo.org apps are written in Python, so > there's a significant developer base there. We're working on Harmattan to > have the Ovi Store situation changed, and having to revert the stance once > more in MeeGo proper would be, well, quite strange. > > Additionally, Per's point of having PyGTK present in Core is a good > reference: I think it would be a rather suboptimal situation if you could > develop MeeGo-compliant Python applications for the Handset UX only with GTK > but not with Qt. > > +1 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Upstart in MeeGo?
On Monday 20 September 2010 16:45:32 you wrote: > > There was discussion on meego-community about them *going* to be set > > up, but I seem to have missed the announcement about what new mailing > > lists *have* been established (both on the web and cross-posted to all > > the current lists, I'd've said). > > Sorry, Quim's post was incorrect. Yes, that mailing list has been "created" > but I have not yet finished configuring it, and none of the architects are > subscribed yet. Please continue architecture discussions here until you > see an announcement from me that the list is ready to use. I believe architecture discussions to be closer to platform SDK discussions than application development, so technically, it's still the wrong list (just as you have rightly pointed it out in the case of the Harmattan question). On a side note, I recall there was a plan to rename the lists in a "refocusing meego-dev" thread so we could perhaps lower the number of misplaced threads like these two, but I lost track what happened to that activity... Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Mon, Sep 20, 2010 at 6:52 AM, wrote: > > Why do we go back a few steps and figure out what goals we want to > > achieve with this and then we can find the best way to go about it. > > "Simply put, we want to make it possible for an application developer to > write a MeeGo compliant application once and run it on any MeeGo compliant > device." > http://wiki.meego.com/Quality/Compliance > The trouble is that is a rigid goal and I'd say a slight conflict of interest between that path and the approach of having various profiles (even without the whole dependency story). I mean, that 'any' in the statement already expands to 'with a given architecture and given UX and given hardware'. > The Qt / Qt Mobility / Web Runtime game combined with the different UXs is already more complex than the setup offered by Android and iOS. Then why agree to fight the battle on their terms ? Why go for diversity as your main strength and then try to compete in terms of monolithic development models ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Monday 20 September 2010 01:30:18 you wrote: > Again we are basically back to two types of "compliant" apps. I strongly > believe that is a mistake we cannot afford to make - we need to avoid > fragmenting our application ecosystem. We know we want to have bundled commercial apps targeting stores. We know we want to have a repository/repositories (Extras/Surrounds/Staging/whatever) using OSS practices on meego.com. How does declaring only one of those MeeGo compliant reduce fragmentation (already present over hardware architecture and device UX/profile) in any way ? > > Then get the Marketing team to decide on how those MeeGo Core Apps will > > be branded in the outside world. My suggestion: "MeeGo World -- a > > world of apps for all MeeGo devices". The MeeGo 1.1 version of the > > branding rules will state that only apps that meet the defintion of > > "MeeGo Core Apps" can call themselves "MeeGo World" apps. > > I want to make the marketing team job really simple - market "MeeGo > Compliant Applications" How about we use the name "MeeGo Store Compliant" ? Since that's what this is really about. That way meego.com/community repositories are not labeled with the derogatory "not MeeGo Compliant" stamp, vendors can decide whether they want to be MeeGo Store Compliant or 'meego.com' compliant anyway, MeeGo is not ridiculed to be the only Linux distro in the known universe whose compliancy program does not allow non-system dependencies, and marketing can happily chirp with a single, non-technical message ? Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Saturday 18 September 2010 21:48:04 you wrote: > Before we require compliant devices to support apps with external > dependencies, I think we need to demonstrate that the value of that > justifies the cost and complexity. For example - show what can be done > with MeeGo Extras following this model. We can add this to a future > version of compliance if everyone says "wow, that's great - I really want > this on my next device" Maemo Extras (different package format, same idea): 1400+ apps 30+ million downloads Operational and field proven on the Nokia N900 Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [compliance] Different view on app compliance
On Saturday 18 September 2010 21:20:09 you wrote: > The challenge is that if we dilute this, we risk that people dump in, > let's say, SDL and it would conflict with another repository also > hosting SDL. We won't see people putting same application in multiple > places, I would hope.. I think we talked about this... Shouldn't package namespace management (proposed in the draft, even if not quite final) take care of that ? I mean, if you're afraid SDL can pop up in another repo, so can any inconsiderately named app, too... Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Saturday 18 September 2010 19:05:52 you wrote: > >> Instead, why not leave "MeeGo Compliant Apps" alone and carve room in > >> the spec for "MeeGo Extras." Either allow only one "Extras" repos. Or > >> PREFIX > > > > Saying 'oh, not being compliant is not a big deal, look, we have > > thousands of non-compliant apps that are safe and run just fine !' > > sounds really bad from the aspect of the future value of term MeeGo > > Compliant for *users and developers*. > > Except that's *not* what I said. Maybe it's just me. but that is how it sounds, if those apps in Extras *are* hosted and/or encouraged by meego.com, but *not* part of the MeeGo Compliance program. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Saturday 18 September 2010 15:48:07 you wrote: > First, this is a NO-OP. It basically says "applications must depend on a > package set that ultimately is only depending on MeeGo." Of course! > Otherwise it won't run. No. Compliancy is more than just fulfilling dependencies, that's whole point of the story. It means that each of the depending packages are fulfilling requirements prescribed by the compliancy program (for example not placing their files in places where they could conflict, or not using private APIs). > Instead, why not leave "MeeGo Compliant Apps" alone and carve room in the > spec for "MeeGo Extras." Either allow only one "Extras" repos. Or PREFIX Saying 'oh, not being compliant is not a big deal, look, we have thousands of non-compliant apps that are safe and run just fine !' sounds really bad from the aspect of the future value of term MeeGo Compliant for *users and developers*. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Saturday 18 September 2010 15:48:07 you wrote: > > process through negotiation: > >"this app needs X=,Y,Z"... "OK, can meet"..."here's the app" > > But app Q=,T,F > > But app T installs a file /usr/share/icons/kewl.png > And app Y also installs a file /usr/share/icons/kewl.png > > Since T and Y conflict (rpm won't let you install both unless you're a > ninja), so does Q and X. Very uncool, especially since they are all > "compliant" according to your definition. Then both T and Y and non-compliant as they install stuff outside their own directories and X and Q would still be conflicting (and non-compliant) if they bundled T and Y instead of depending on them externally. We're running in circles. If your dependency conflicts with something, so would your package if it bundled it, external dependecies do not change this in any way (if anything, they can ease constraints as by depending on virtual packages). Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Friday 17 September 2010 20:29:06 you wrote: > On the other hand, what are the deep issues underneath this long > discussion? Let me try: > > - The belief that the MeeGo official AOPI is not enough to satisfy > developers. If this is true then it's a problem in itself and needs to > be fixed by improving the API. It cannot be fixed through the API for 2 major reasons: - you are bloating the API to kitchensink proportions. Every API class you add in means more hardware requirements for *everyone* and, on the long term, makes maintenance more and more difficult (as you promised API stability) - the API update cycle is too slow. The libraries you would be wrapping have their own release cycles - add the MeeGo development, freeze, QA, and it means you are dealing with stuff from a year ago in no time > - The belief that there will be a significant amount of apps using other > APIs / toolkits. Which ones, though? PySide? KDE libs? Hildon? This > discussion would be better grounded if sustained by real maintainers of > these toolkits & bindings. My scripts show that 60%+ of ALL Maemo applications depend on at least one package which is not found in the firmware or manufacturer repo. (am playing with some repo stats to gauge extras-testing status). And that's with plain Hildon and Ovi apps in the 'compliant' camp. Another number that might be of interest - these apps account for 75% of the 30+ million downloads on maemo.org > - Even the perception that the Compliance restrictions go somehow > against free software development. I would accept this one if the MeeGo > project would refuse the idea of hosting an own Extras/Surrounds repo. > But if this exists then developers concerned about software freedom can > use them, and users concerned about software freedom can buy devices > open enough to run that software. In any case, I see some mis-alignment between what you say and: On Wed, Sep 15, 2010 at 7:13 PM, Skarpness, Mark wrote: >> If compliant apps are allowed to have external dependencies - then >> someone has to pay to host and maintain those dependencies so they are >> available worldwide to many millions of devices. > > Won't that be the MeeGo repository? No, probably not - the meego project infrastructure is not set up to support commercial product deployments. The device vendor and / or service provider would need to host this (as they would also host updates, etc). SNIP Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Fri, Sep 17, 2010 at 12:40 AM, Nicolas Dufresne < nicolas.dufre...@collabora.co.uk> wrote: > Actually users will have problems when two repositories start providing > same package (name clash or file clash) and user problems result in customer > support fees. > > The name clash is actually talked about in the spec (lines 144-155), though I'm not convinced the current suggestion is a long term solution. File clash is not possible due to the compliancy requirement of the (/var)/opt/packagename placement of compliant packages. Shared resource clash (like TCP sockets) is possible, but that is no different that in the case of bundled components. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Fri, Sep 17, 2010 at 12:23 AM, Tim Teulings wrote: > > So bobapp's web page and package description would say: > * This is the wonderful bobapp. It is Meego compliant for Device Zupp and > Device Wusch but not for Device ExtraLess. > > Is this the kind of complicance statement that e.g. marketing has ordered > ;-)? Would such compliance statement be of any help? > > The bobapp statement holds anyway, if the vendor of ExtraLess decides not to allow it. In those terms Compliancy has limited value for the *user* as it does not guarantee in any way that bobapp will or will not be obtainable/allowed on a certain device. Unless marketing wants to get into the business of saying 'well that means it COULD run it, not that YOU can run it'. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Friday 17 September 2010 00:44:43 you wrote: > this is where you get in trouble if vendor Z ships libbar but in a > different configuration/version for some widgety nifty thing that they > do... ... and that version/configuration is not ABI compatible. ...which is not that much of an issue, because with proper path/rpath handling those libraries would not conflict the vendor supplied ones (Compliant ones can't dump their stuff in /usr/lib anyway, right ?), and if they do conflict, due to some shared resources like ports or magic files/sockets somewhere, the same would happen if libbar was statically linked into fooapp. Been there, done that (this has come up in Maemo between Nokia repos and Extras, and has been acted upon, so Extras now contain even alternative versions of Qt). Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 7:24 PM, Skarpness, Mark wrote: > > If MeeGo then permits Surrounds-dependent apps to be labelled "Compliant" > then > > there is no addidional burden placed on a vendor since they can simply > refuse to > > allow them on their device/store? > No - that is a different problem. If compliance says that compliant apps > can have external dependencies, then every compliant device MUST support > those dependencies and ensure they are available to every device. That is > the burden we are debating. > Even though they might never ever allow an application with those dependencies to reach the device ? That sounds like quite a bit of dead weight, especially if, say, Python apps start aspiring for MeeGo compliancy at some point. > > This demonstrates *exactly* what I expected and I fully support and > comprehend > > it. Vendors are *NOT* obliged to support compliant apps so allowing some > apps to > > be labelled "compliant" does not put any mandatory burden on vendore or > app stores. > Device vendors are obliged to have the ability to run every compliant app. > They are not obliged to allow the user to install every compliant app. > > That's OK. I'm curious, though, how this reflects on, say, hardware limitations - for example if someone submits an app that requires 1GB of RAM, there can be devices that cannot provide those resources and hence no ability to run it, while others will. Does that mean that devices can 'lose' compliancy over time, or that, depending on hardware, Compliant application might still not work on Compliant devices even with the same UX and same target API version, depending on actual resource requirements ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thursday 16 September 2010 17:28:19 you wrote: > > *IF THEY WOULD* and you downloaded a MeeGo compliant app that used a > > Surrounds library would it work? > > So in case of a road death, who is liable for this Surrounds library > exactly? In case of a road death, who is liable for the MeeGo compliant application that has the same library bundled within it (as that is the alternative of not having Extras/Surrounds) ? Though I would ask myself first why anyone would allow Joe Coder's 3D pacman (MeeGo compliant or not) to run on mission critical hardware in the first place ? I'm still not sure if we are all on the same page here. The original stated compliance program goal was that if something is MeeGo compliant, it should be *ABLE* to run on a MeeGo compliant device and not that it *must* be allowed to run on it. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 2:20 PM, David Greaves wrote: > > Some may choose to be draconian fearing US litigation; others may go for a > more liberated approach to the market. > > Why is MeeGo compliance mandating the draconian and forbidding the > liberated? > > I can't emphasize this enough - where is the need to transform vendor choices into OS policies coming from ? Vendors can lock down/filter repositories all they want and that's OK, it's their product - it's their call. After all, if the vendor is (for whatever reason) against installing a certain app (or any app for that matter), it doesn't matter how big your MeeGo Compliant sticker is - you're not getting on that device. But I don't really see why that, existing, valid choice is considered as a good baseline policy *for MeeGo* as such ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 1:15 PM, Jeremiah Foster < jeremiah.fos...@pelagicore.com> wrote: > On Thu, Sep 16, 2010 at 1:02 AM, Skarpness, Mark > wrote: > >> Yes, that's exactly what we expect. One version for every MeeGo compliant >> device. Device-specific tailoring will be the exception - it's expensive, >> time consuming, and results in an app that will run on fewer devices. >> > > This certainly makes sense from a developer/vendor standpoint. > Unfortunately, I'm not so sure about the user angle as they don't care if an > app works on OTHER devices than their own. > > > I disagree. Users want to move their photos easily from their phone to > their TV, move their phone calls from the phone to the car, etc. > That I believe still falls under "their own devices" :) What I was saying is that an N8 owner doesn't care much if an Epic Citadel type of thing runs on a C7 or not (let's pretend for a moment that those two are MeeGo devices). If compliance means forcing developers to go for a single lowest common denominator version of the MeeGo APIs, you will never see cool stuff on MeeGo once the first wave of devices passes (and that's something high-end device users DO care about). > > The Symbian experience so far is suggesting that quite a few developers > believe that having generic apps able to run on a hundred different devices > are a dubious match for apps tailored to maximize user experience on a small > number of bestseller devices. > > > If you have _one_ OS with _one_ well defined API, you will gain a great > deal from a developers standpoint. > > With the various UXes it already is failing on that promise, but that is not the point. The problem is that it's a black and white setup with a conflict of interest. You want developers to only use your API (so make it as all-encompassing as possible), but also have the need to make this API as small as possible due to financial/technical constraints. For example, MeeGo currently has no gaming or social networking oriented APIs, which are a must have category on many of its device categories. Existing Linux libs/apps *can* mitigate this if done properly. The only trick is to make the compatibility/compliancy thing a CONTAINS relation, and make proper, clear names for them, so that whatever compatibility level you are aiming at, you know exactly what is beneath that - MeeGo Core, UX, Extras, Surrounds, etc... Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 16, 2010 at 1:02 AM, Skarpness, Mark wrote: > Yes, that's exactly what we expect. One version for every MeeGo compliant > device. Device-specific tailoring will be the exception - it's expensive, > time consuming, and results in an app that will run on fewer devices. > This certainly makes sense from a developer/vendor standpoint. Unfortunately, I'm not so sure about the user angle as they don't care if an app works on OTHER devices than their own. The Symbian experience so far is suggesting that quite a few developers believe that having generic apps able to run on a hundred different devices are a dubious match for apps tailored to maximize user experience on a small number of bestseller devices. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Wednesday 15 September 2010 19:13:43 you wrote: > devices: "we need to know the maximum footprint of the OS on the device", I don't really see how the maximum OS footprint differs in cases if a package is installed from a store compared to another (peer reviewed, MeeGo compliant) repository... Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Wed, Sep 15, 2010 at 3:19 AM, David Greaves wrote: > As an app-store owner; you have a policy. If you only accept apps that > don't use Surrounds then that's fine. I assume we are not mandating that app > stores *must* accept all applications submitted to them? > > MeeGo of course should allow app stores who actually have the competence to > support dependencies to do so. Several design solutions have been proposed > and our 'reference' app store should have no problems. > > My favourite is that the app store sends a dependency list to the > application manager and when the client side application manger confirms > that all dependencies are installed, the application can be downloaded. > Seems like another well understood solution (zypper/yum/apt) > > A *huge* benefit of having MeeGo Surrounds is that we have *one* place > where this kind of shared application dependency needs to be looked for. > > *PLEASE* listen to the hell that Maemo endured when they had a multitude of > such repos (commercial or community) > Just in case that this community repo talk and maemo.org doesn't really sound like something that should be learned from - currently Ovi for the N900 uses similar requirements as what is outlined here for MeeGo, even though the tech is slightly different. To be compliant you can depend on what ships with the firmware, which is the functional equivalent of MeeGo Core. If you depend on something else, you bundle. From the standpoint of a system already in function - while simple and predictable for vendors, it is not the strategy that lights developers on fire (except from frustration, when people discover that versions with fixed bugs or whole libraries, sometimes developed by the same vendor, are not usable by their apps if they want to be compliant). There were already plenty of discussions in public Maemo forums about this - I hope it is not necessary to rehash those here, too (again). Let's put the decades worth of Linux and the several years of Maemo, Moblin and Ovi experience to good use. We have the advantage of not having to be rethorical. Most, if not all concerns and cases here are a been there, done that. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Tue, Sep 14, 2010 at 10:19 PM, Skarpness, Mark wrote: > Allowing applications to have arbitrary external dependencies that are > resolved at install time adds a great deal of complexity and uncertainty for > a device manufacturer (substitute "MeeGo software stack provider" for > "device manufacturer" if you wish). > > I want to create a simple "contract" between the device manufacturer and > the application developer: the device manufacturer promises to provide a > defined set of packages and the application promises to install and run > correctly using only those packages. Perfectly understandable. But (always that but) the question is if that is the ONLY possible "contract". Again, it doesn't matter how this, extras or surrounds, compliance is called, as long as the name itself is not grounds for exclusion from the MeeGo ecosystem. Since it would obviously not be part of the MeeGo device compliance itself, vendors can freely omit this option if it's too much for them (and then deal with the flak of users facing the reduced number of apps). One of the greatest advantages of Linux is the extendability and huge repository of existing code and documentation. I highly doubt developers/publishers will have qualms about leveraging that and making huge bloated packages if they are denied proper repository/dependency support (existing proprietary linux apps are a prime example of this), which in turn means that such a rigid limit - despite the best of intentions - might not really solve much, just transfer a problem from one domain to another (from a repository QA/availablility issue to a package QA/availability issue). Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Tuesday 14 September 2010 04:09:46 you wrote: > Yeah, as David says, I think that's actually worse if you let them > use Extras, than if you force them to include everything in their > bundle... I don't think people are going to stop using libs - it > just means that if you let them depend on extras they can share it > between apps. > > i.e. if you have 100 games that use SDL, in the case of bundling libs, > then you have 100 copies of the SDL libs on your device. But if you > let them use Extras, then you only have one copy of SDL shared by all > of the games... Also, the hidden benefit is that you actually SEE what are the popular libs on your platform (=no need to speculate what people MIGHT want to use) and thus which ones are good candidates for inclusion into the MeeGo stack at some level - which again benefits all those apps (you don't need to be a rocket scientist to see that Python will be No. 1 on that list, but other, not-so- apparent things might float up, too). As for the question of QA - I really don't think that community QA of a lib (done by ALL developers/users of that lib) is worse than the QA done by those same guys (if any) in a particular developer studio/university, split over several different versions and builds. If you have a 100 SDL apps, having them bundle SDL separately is not just a waste of space, IMHO it's actually a waste (=lack of guarantee, or statistical nature) of QA, too. I agree there should be BIG WARNING LETTERS about where a package is coming from, so everyone can make the choice of whether to be MeeGo Core compliant, or MeeGo Extras compliant. If we have to thing up a name for it not to taint something, we can call it MeeVerse or whatever, but then I feel we would just be diluting the MeGo brand - something that IMHO at this point it doesn't need at all. I think David's Surround is a better description than Extras, but I also feel that there is a language barrier there and the nuances the Surrounds term carries might not as easily/plainly understood by non-native English speakers - but that's just my language geek opinion. Best regards, Attila Csipa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 9, 2010 at 2:32 PM, Ville M. Vainio wrote: > > Making Extras a "blessed" repository of packages would nicely solve that > > issue - you can restrict further dependencies to "libraries which are > > included in the core, or MeeGo compliant libraries available in Extras". > > It's unlikely that extras would be deemed bless-worthy; it's not > controlled by central authority that could be blamed when things > break. That's why we need a gatekeeper that is held responsible for > the app developers (and will answer the angry phone calls late at > night ;-). > > Certainly - I don't think anyone expects Angry Birds 2 to depend on libfoo from MeeGo Extras. I also understand Arjan's point that vendor X might decide to include a libfoo in their particular blend on MeeGo UX and then things would get tricky if libfoo also existed in Extras. The question is still - how do we make repository 'owners', regardless if they are device vendors, software companies or community efforts cooperate ? If it's just MeeGo Core, and beyond that every man, woman and child for him/her/itself, it will likely mean serious fragmentation from day 1 (do we really need to go through the pains of various JSRs, Symbian API jungles all over again ?). Should this central Extras maybe just be a 'reference' or upstream repository from which then packages can be promoted to vendor/device repositories (so from there on it's their community/QA/patchset/whatever) ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, Sep 9, 2010 at 7:28 AM, Arjan van de Ven wrote: > The first model is what Maemo used to be, there was only one Maemo; the > second model is what Moblin used to be, with many variants. > > Frankly, I see MeeGo only be able to follow the second model; there is more > than one company doing products with MeeGo (heck, Novell already has a > variant), and thus there will be variants. > The moment you have variants, where you allow the variants to add their own > stuff on top, you can't have an "Extras" repository that works for all of > these variants anymore, only one that works > for the reference. > Let's take a step back for a moment here, and take a look at Ubuntu. Look, there are plenty of variants of it, Ubuntu, Kubuntu, XUbuntu, etc. These have their very different presets and default packages but DO retain compatibility across Ubuntu repositories, even with universe, multiverse and all. We have thus arrived to the bottom line - what *IS* MeeGo's stance on people requiring libraries or components not present in Core ? Let's try to see if there a solution that keeps Core from bloating as much as it keeps the apps themselves for bloating. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Wed, Sep 8, 2010 at 4:41 PM, Warren Baird wrote: > Seems to me like the wind is blowing in the other direction, at least > on this mailing list... For commercial dependencies it might make > sense to include everything in one package, just to simplify pricing > and distribution. But for open-source dependancies I really don't > think it makes sense to disallow non-meego dependancies... > > Take a look at any modern linux distro. How many packages are there > that depend on other 3rd party libraries and tools? It's going to > make the open-source developers life a lot more complicated if they > have to bundle *everything* in their package - not to mention the > wasted disk space, which can be at a premium on a handset... > There is quite a lot of precedents on the topic actually. Repositories on linux were born as a natural need for a centralized way of distributing interdependent components for a particular platform - and were maintained by platform people, porters, etc - people usually quite unrelated to what the end-users actually used. Commercial (not quite the right term though) on the other hand had to be self-sufficient and self-maintained, so could not afford the luxury of 'proper' dependencies and QA over the myriad of Linux distributions and hence the preferred blob-style distribution (whether it's a deb, rpm, or even tar.gz is in this sense irrelevant). The real question here is/was - will there be a platform level choice in favor of one of these groups ***in a way that is detrimental to the other one*** ? IMO there shouldn't be - it would be a poor choice to make the delineation of commercial/community (or if you wish store/3rp party repo) made in a way that reduces both the amount of available software AND introduces entry barriers to developers, regardless if they are hobbyists, open source enthusiasts or paid hardcore professionals. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Wed, Sep 8, 2010 at 3:48 PM, Thiago Macieira wrote: > > too), can help here: It remembers the 'origin' of a package, and only > > allows updates to it from the same origin. > > > The security framework in Harmattan (which I think is coming to MeeGo, Then I propose we do that when we have safety measures, not sooner. > > That means MeeGo 1.1 should not have it. We're past feature freeze and I am > still clueless about what the Harmattan Security Framework is. (And I work > for > Nokia) > For a light introduction, see http://www.slideshare.net/reshetov/maemo-platform-security-fosdem Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Tue, Sep 7, 2010 at 1:20 PM, Marius Vollmer wrote: > The thing that the MeeGo platform can contribute here is to require that > all compliant MeeGo devices must have the standard repositories > configured. I am not sure whether that will be required. Is it? A > related question is OS updates: Is a compliant MeeGo device required to > have the OS update repositories configured? > > > In other words, if I buy an app from the Ovi Store, I don't want to > > find out after buying it that it won't install because I needed to buy > > some emoticons too. > > Yes, very true. It's a problem of how the Store works and how it > interacts with the on-device package management, but forbidding all 3rd > party packages to require other 3rd party packages to solve it would be > going too far, I'd say. > > > Think of two games that share a common engine: when buying any one of > the games, you will implicitly buy the engine, too, and the store will > give you permission to download both the game package as well as the > engine package. Then when the game is installed, the engine is > installed at the same time (invisibly to you). When you buy the second > game later, you already gave the engine. > > If we also figure out how to present updates to the engine package to > the user, then this should work, no? > There are several points that need to be addressed if you are sharing components/engines/etc QA - a package can be tested with one version of the engine but that does not necessarily mean it will work just as well with others, so an innocent update to one can break the other (who said libsdl-ttf2.0 ?). In Maemo this worked most of the time mostly because we were reusing libraries from desktop distro's where they usually already underwent some checks. Security - to avoid leaking of user data (config, passwords) from one package to the other - the fact that app A depends on Qt and app B depends on Qt should not mean that B can read A's config/data automatically. That's why most of the time these big, reusable runtimes and libraries are part of the system - so that they can undergo serious testing, integration checks and controlled updates. Now, before someone misunderstands this as an argument NOT to allow dependencies on 3rd party packages - the whole point is IF you have a shared repository, you must have a procedure/agreement of how you update/modify/publish stuff there in order to prevent it from becoming a jungle/huge pile of unsolvable intertwined dependencies. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Sun, Sep 5, 2010 at 2:25 AM, Gabriel Beddingfield wrote: > If you are the upstream OS (MeeGo, Fedora, RHEL, Debian, etc.) then > you work through this issue with policies and negotiations on mailing > lists, etc -- because you're making it a part of your OS. In this > case, we're talking about making it "add-on." > > By installing to /opt... then foo puts everything in /opt/foo and bar > puts everything in /opt/bar. No (or at least, fewer) collisions. > > The key question is if ALL of the various system services support such a layout. I.e. if you want the apps REALLY contained in their (/etc)/opt/foo dirs, then DBUS, icon management, upstart, etc must also know about this scheme and scan those dirs accordingly (this is a thing Maemo has never gotten around to and hence the sucky nature of optification). Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Looking for a right way to create daemons on MeeGo
On Fri, Sep 3, 2010 at 10:35 PM, Sivan Greenberg wrote: > On Fri, Sep 3, 2010 at 10:22 PM, Auke Kok > wrote: > > On 09/03/10 09:42, Epshteyn, Eugene wrote: > >> > >> Are there instructions for MeeGo similar to what exists for Debian > >> (http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html) > >> about setting up daemons? I have some software that needs to run as > >> a daemon, and I would like to learn what's the right way to do that > >> on MeeGo (e.g., creating separate user/group, adding to init.d, > >> what's a good place for the daemon to dump log files, etc.) > > > > MeeGo currently assumes no new system-wide daemons will be added, we > prefer > > that services are started on-demand where possible, and/or run from the > > user's session instead of running system-wide. D-bus activation is a > popular > > and well-proven method for doing this. > > What's the proper canonical way to use dbus in such way to trigger > local service startup ? > See http://freedesktop.org/wiki/IntroductionToDBus under Activation. Though some think using DBus for such things isn't a great idea, see http://upstart.ubuntu.com/faq.html#replace-dbus for some background. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Refocusing meego-dev
On Sat, Aug 21, 2010 at 12:47 AM, Foster, Dawn M wrote: > However, I've never tried to rename a mailing list. We'd probably need to > set up some forwards, and I'm curious if there are any other technical > gotchas in renaming a mailing list? > See http://www.gnu.org/software/mailman/faq.html under "how do I rename a list". It's not exactly trivial, but the upside is it needs to be done only once (okay, twice as we were talking about two lists :) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Refocusing meego-dev
On Thursday 19 August 2010 21:16:31 Foster, Dawn M wrote: > I know this is a little complicated, but I would rather solve the current > issues with meego-dev than create new issues by adding a bunch of new > developer lists that we probably don't really need. This isn't to say that > we won't create new lists (we will), but there needs to a compelling reason > for new development lists that isn't a variant of "I need a new list > because I don't like meego-dev". I'm thinking that maybe the naming of the lists has something to do with it. I did a quick poll among colleagues and (while not obviously the most scientific method) discovered that without additional information, they too would have posted application issues in meego-dev and platform/sdk related issues in meego-sdk. Note that a similarly named list (running for several years now), maemo-devel IS used for application development issues, also acts as a sort of precedent that adds to the confusion. If it was up to me, I would rename this list to meego-platform-dev and the sdk one to meego-application-dev, unnervingly long list names be damned. But it's not up to me, so I'll end my mail here :) Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Access to meego OBS
On Wednesday 04 August 2010 00:30:06 David Greaves wrote: > Oh, incidentally, how would you feel about a build system that can target > MeeGo, Fremantle and Harmattan? Would that be helpful? I can't stress enough the importance of this if MeeGo wants to attract current Maemo developers or appear as any sort of evolutionary next step to them. We're (maemo.org) already (running dangerously close to) bleeding devs to other platforms, and if Fremantle (and, more importantly, Harmattan) are shut out, I fear that will run the risk of ignorement of OBS and mainline MeeGo until Nokia ships a device that utilizes OBS, which might take a while. I fully understand the importance of (and support) keeping things clean and Free, but be aware of the price both Maemo and MeeGo will be paying. David already talked about the special case of Fremantle and Harmattan both existing in some form when MeeGo was announced - and while I agree this is the classic grandfather clause, I would like to ask everyone to think it through from the aspect of developer community continuity before they say yes or no. Do policies determine our goals or do our goals determine our policies ? Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Advise on upgrading hardware for Meego
On Tuesday 27 July 2010 14:05:40 Thiago Macieira wrote: > Application SDK. That's developing the platform. That's what *this* mailing > list (meego-dev) is about. This has been a recurring issue... Makes me wonder if that hints that our mailing list names are not named as obviously as originally hoped ? I'm not at all sure if I would guess correctly if coming from a clean slate background. I'm under the impression the SDK confuses people (as in they think it is tied only to things related to the SDK itself, not what is produced with it). Maybe meego-platform-dev and meego-app-dev would cause less confusion. Or not :) Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] PyQt
On Monday 26 July 2010 10:30:34 Sivan Greenberg wrote: > That was not my intention, well, in better- I meant heading to bind > some new libs that did not exist when PyQt was created Just a smallish note from someone who follows PyQt development fairly closely - I would not be surprised if those new libs (or at least a major subset of them) popped up as supported under PyQt. My OBS-foo is not yet strong enough to allow me to tinker with bindings under MeeGo, but it is on my (rather longish) to-do list, as, though some might disagree, I still feel there is some advantage of having two bindings. OTOH I do think MeeGo should (have) push(ed) for full platform level python availability from day 1, picking a preferred/official binding if necessary. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Difference between MeeGo and Android?
On Wednesday 21 July 2010 16:30:14 Randall Arnold wrote: > Felipe, that's not accurate.� MeeGo has just as many companies involved > as Android if not more. It's a bit difficult to compare at this point. Android is just one facet of the Open Handset Alliance, and there is not really an equivalent to OHA in the MeeGo world (though it would have been probably fair to mention at least the Linux Foundation as a stakeholder). Also, at this point it is hard to tell how many under-the-radar development goes on outside of Nokia/Intel. There was that famous letter of support, but that still does not say much about actual vendor commitment. Plus you have this weird combination of companies that are (at least on paper) supporting both. Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Corporate email use? (Was Re: MeeGo deliberately incompatible with other distros)
On Monday 12 July 2010 13:09:16 Rémi Denis-Courmont wrote: > On the one hand, it makes any potential conflict of interest self-evident. > On the other hand, it puts some pressure on the author not to post anything > in disagreement with his/her employer's position, which, while legal, is > against employment policies (sic) and work ethics. And while we are at it, I don't understand advocating employer email addresses as a way of better understanding, and then make it a local, mailing list phenomenon - if you take a look at the MeeGo forum, barely anyone (including people who voiced those concerns on this list) wears a company sticker, the best what you'll get most of the time is a reference in the person's profile/about. It really is a case of damned if you do, damned if you don't. Matters get even more complicated as simple emails do not reveal the position of the person. Personally, I don't care whether someone's email ends with @nokia or @intel. However, when someone says something that makes me cross-eyed with regard to the main goals, technical aspects of MeeGo, or simply goes against something that has been agreed upon I sure want to know his/her position in the MeeGo hierarchy. If we insist on the 'understand thy fellow poster' aspect, that is. PS. This whole thread should be in meego-community, as the topic applies to all things MeeGo, not just development. Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] After handset day one - a plea for openness
On Wednesday 07 July 2010 18:51:59 Dirk Hohndel wrote: > In reality we are giving a HUGE gift to competitors here. But we are > being attacked for that huge gift not being 100% complete. It feels like > an alternative reality at times. Intel has put hundred of man years of > development into this project by now - and all of that is available in > open source. As an fruity company guy says, if you think about it as a gift, you're doing it wrong. If you want to treat it as a gift (which I doubt), your license of choice should have been MIT/BSD-ish (or downright public domain). However, IMHO neither Intel nor Nokia are in this for purely altruistic reasons (though it might be a welcome side-effect), but because it helps their business models in some way. The little guys (yes, that's us devs and enthusiasts lingering around even though there are no products) are also investing something that is, unlike the impersonal gazillions of company man-hours, very personal and touchable for them - their own free time, enthusiasm and expertise. That's why you should not go into pissing contests and company rationales with these people even if they only offer eggs against your ham. If an AMD or NVidia guy came here and bashed Intel for not doing their own work, I'd back you up 100%, that really is their job (even though there IS a question of reaching out even to those competitors - there is a difference to say 'whoever wants can join' and 'we want to make this an industry standard'). But I digress, this is NOT only about companies here (otherwise, this place is no better than what Android is/has). The COMMUNITY, if it is to become anything serious in MeeGo land, does not deserve such an attitude. Should have sent this to the community list, anyway... Best regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] multimedia architecture
On Tuesday 22 June 2010 18:34:32 Thiago Macieira wrote: > > It is said that the MeeGo API is based on the Qt API, thus it sounds > > interesting to have a MeeGo architecture discussion (especially one that > > touches on features used directly by developers) without taking Qt into > > account on some level. > > Yes, there will be MeeGo APIs that are not cross-platform. MeeGo should > have APIs that serve its own needs and should not be limited by what other > platforms have. In fact, MeeGo should have APIs that other platforms *do > not* have. :-) Perfectly understood, it's just there is a fundamental difference in thinking about an API that is a superset of something (Qt in this case) or thinking about an API that is a union of libs that are loosely related at best. Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] multimedia architecture
On Tuesday 22 June 2010 18:18:55 Tomas Frydrych wrote: > Sure, but you build the tools for the platform, driven by your vision of > what the platform as a whole should deliver. You do not put the tools > people into the driving seat and build your platform around existing > tools and their limitations, that will compromise the platform as whole. Just out of curiosity, in your context of tools people and driving seats, who is the 'you' in 'your vision' ? Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] multimedia architecture
On Tuesday 22 June 2010 17:32:40 Tomas Frydrych wrote: > This is entirely irrelevant; MeeGo *is* Linux, and we are not discussing > Qt architecture here, but MeeGo architecture. It is said that the MeeGo API is based on the Qt API, thus it sounds interesting to have a MeeGo architecture discussion (especially one that touches on features used directly by developers) without taking Qt into account on some level. Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo dictionary/glossary
Some of you might have noticed my blog post about MeeGo terms - and as per Robin Burchell's suggestion, I intend to merge it into the Glossary page in the Wiki. Before that, however, I would like to gather some feedback and submit it to review/corrections. Without further ado, visit http://wiki.meego.com/Meegodict and edit away (note: I was focusing on technical/architectural terms, not organizational, let's keep it that way for now). Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo compliance
On Wednesday 19 May 2010 19:35:18 Arjan van de Ven wrote: > > Maybe distros that are binary-compatible with MeeGo but aren't building > > on top of MeeGo need a separate sticker. This could include the > > .deb-based distros. > > I don't think that at this point that would be called compliant. It has to be, in some form, unless the announced MeeGo compatibility/rebranding of certain Moblin and Maemo versions is to be accepted as an axiom and not as a fulfillment of certain technical criteria. Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Voting in bugs.maemo.org
On Wednesday 12 May 2010 21:37:47 Graham Cobb wrote: > And, in any case, votes are purely informative -- they don't change the > priority, just provide more information, allowing you to change a priority > if you wish to. +1. This is key here. The voting is not a replacement for the technical evaluation part, it is complementary to it. Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Community repositories kicking off
On Friday 30 April 2010 10:27:51 tero.k...@nokia.com wrote: > - How the QA will be handled in the Community Apps? Initially it will be > human based, but can we get automation to help in some phase? As some of the people on the list already know, there is a QA procedure for community apps on Maemo with quite a history now, and which is still being tweaked to find that ever-elusive thin line between not stepping on developer toes and bringing some sort of basic QA assurance to the end users. I hope to see the lessons and experiences of that process brought over to MeeGo. With MeeGo, I think the task is significantly more difficult, however, as we have more platforms, potentially more devices, more OS versions, etc, to the point that I actually doubt we can apply the human testing as used on Maemo (which even there proved to be a bottleneck). Automation can and should be employed, but that will largely be limited to packaging related things. In any case, I very much would like to hear suggestions on this, what do you think applies from the Maemo/Moblin QA ancestry, and what doesn't. Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Instructions for ARM / N900 (was Re : Day 1 is here ...)
On Thursday 01 April 2010 07:44:07 Thiago Macieira wrote: > Nokia did present 300 Maemo developers with N900 devices back in October > last year, in the Maemo Summit. That was a great (surprise) move, undoubtedly. I just wish we had more than one month to play with MeeGo on them. After that, hello chroot (until we get dual boot IIUC). Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] qtcreatore+madde
On Tuesday 16 March 2010 14:47:58 Bernd Stramm wrote: > Another point of view is that the excellent portability provided by Qt > comes from the libraries. Tying this to any particular IDE is really > bad. It generates programming styles and project build structures that > have nothing to to with the Qt libraries or the application problem. > This is not a good thing, regardless of how fine a product Qt Creator > is. >From what I understand, MADDE is something quite separate from Qt Creator. Qt Creator is fairly modular, and in this case, is extended to handle MADDE. This does imply loosing the ability of calling MADDE with the appropriate paramers yourself should you not like Qt Creator for some reason, and I hope the MADDE team keeps the CLI mode in the future, too. As for styles and project build structures... well, from my experience Qt creator is fairly agnostic in that regard, especially if you use qmake and .pro files. From all the all-in-one development enviroments I have used, Qt Creator is definitely in the less-intrusive group. Regards, Attila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
