MeeGo wiki - User contributions [en]

MeeGo Touch Framework

2010-08-27T16:22:18Z

Bzhbok:

MeeGo Touch is a Qt based application development framework targeting mobile touch screen devices. It is part of MeeGo API (along Qt 4.7). It provides all the necessary building blocks for creating native applications that follow the MeeGo Handset UX guidelines . The framework itself is built on top of the Qt Graphics View Framework.

The source code is here : [http://meego.gitorious.org/meegotouch]

The documentation is here : [http://apidocs.meego.com/mtf/]

== Architecture ==
(to do)
(see documentation)
== Relation to Qt ==
The Framework sits on top of Qt. It extend it and adapt it to touchscreen interface, providing convenient classes and widget for a MeeGo Application on a touch screen.

== Should I use this framework to write an application for MeeGo ? ==
This topic was discuss in the forum here : [http://forum.meego.com/showthread.php?t=524]

The quick summary : if you value application portability and API stability it is probably better to stick with pure Qt. It is the encouraged way to built application for MeeGo.

MeeGo Touch framework may interest you only if :

* You are building an application UI specifically for MeeGo handset UX.
* You want to adopt the MeeGo style (see MeeGo handset guidelines).
* You are interested in using MeeGo widgets and notifications, automatic screen rotation.
* You can cope with future change in API. MeeGo Touch framework is still evolving. For instance, part (or all) of it may be included in future version of Qt. Though you can be confident that MeeGo Touch will continue to exist and improve.

Also an other new way to code Qt apps exist : Qt Quick. it is still very new, but it could be interesting to write fast a small UI.

== How to install it ? ==

You can clone the git repositories in the source page and compile it (./configure, qmake, make install) or use the version included into MeeGo handset images.

Also it must be run into a MeeGo chroot environment (see [[Getting started with the MeeGo SDK for Linux (Original)]]) or a MeeGo test device ([[ARM/N900]])

MeeGo Touch Framework

2010-08-27T16:17:34Z

Bzhbok: /* Should I use this framework to write an application for MeeGo ? */

MeeGo Touch is a Qt based application development framework targeting mobile touch screen devices. It is part of MeeGo API (along Qt 4.7). It provides all the necessary building blocks for creating native applications that follow the MeeGo Handset UX guidelines . The framework itself is built on top of the Qt Graphics View Framework.

The source code is here : [http://meego.gitorious.org/meegotouch]

The documentation is here : [http://apidocs.meego.com/mtf/]

== Architecture ==
(to do)
(see documentation)
== Relation to Qt ==
The Framework sits on top of Qt. It extend it and adapt it to touchscreen interface, providing convenient classes and widget for a MeeGo Application on a touch screen.

== Should I use this framework to write an application for MeeGo ? ==
This topic was discuss in the forum here : [http://forum.meego.com/showthread.php?t=524]

The quick summary : if you value application portability and API stability it is probably better to stick with pure Qt. It is the encouraged way to built application for MeeGo.

MeeGo Touch framework may interest you only if :

* You are building an application UI specifically for MeeGo handset UX.
* You want to adopt the MeeGo style (see MeeGo handset guidelines).
* You are interested in using MeeGo widgets and notifications, automatic screen rotation.
* You can cope with future change in API. MeeGo Touch framework is still evolving. For instance, part (or all) of it may be included in future version of Qt. Though you can be confident that MeeGo Touch will continue to exist and improve.

Also an other new way to code Qt apps exist : Qt Quick. it is still very new, but it could be interesting to write fast a small UI.

== How to install it ? ==

You can clone the git repositories in the source page and compile it (./configure, qmake, make install).

Also it must be run into a MeeGo chroot environment (see [[Getting started with the MeeGo SDK for Linux (Original)]]) or a MeeGo test device ([[ARM/N900]])

MeeGo Touch Framework

2010-08-27T16:16:08Z

Bzhbok:

MeeGo Touch is a Qt based application development framework targeting mobile touch screen devices. It is part of MeeGo API (along Qt 4.7). It provides all the necessary building blocks for creating native applications that follow the MeeGo Handset UX guidelines . The framework itself is built on top of the Qt Graphics View Framework.

The source code is here : [http://meego.gitorious.org/meegotouch]

The documentation is here : [http://apidocs.meego.com/mtf/]

== Architecture ==
(to do)
(see documentation)
== Relation to Qt ==
The Framework sits on top of Qt. It extend it and adapt it to touchscreen interface, providing convenient classes and widget for a MeeGo Application on a touch screen.

== Should I use this framework to write an application for MeeGo ? ==
This topic was discuss in the forum here : [http://forum.meego.com/showthread.php?t=524]

The quick summary : if you value application portability and API stability it is probably better to stick with pure Qt. It is the encouraged way to built application for MeeGo.

MeeGo Touch framework may interest you only if :

* You are building an application UI specifically for MeeGo handset UX.
* You want to adopt the MeeGo style (see MeeGo handset guidelines).
* You are interested in using MeeGo widgets and notifications.
* You can cope with future change in API. MeeGo Touch framework is still evolving. For instance, part (or all) of it may be included in future version of Qt. Though you can be confident that MeeGo Touch will continue to exist and improve.

Also an other new way to code Qt apps exist : Qt Quick. it is still very new, but it could be interesting to write fast a small UI.

== How to install it ? ==

You can clone the git repositories in the source page and compile it (./configure, qmake, make install).

Also it must be run into a MeeGo chroot environment (see [[Getting started with the MeeGo SDK for Linux (Original)]]) or a MeeGo test device ([[ARM/N900]])

MeeGo Touch Framework

2010-08-27T16:14:41Z

Bzhbok:

MeeGo Touch is a Qt based application development framework targeting mobile touch screen devices. It is part of MeeGo API (along Qt 4.7). It provides all the necessary building blocks for creating native applications that follow the MeeGo Handset UX guidelines . The framework itself is built on top of the Qt Graphics View Framework.

The source code is here : [http://meego.gitorious.org/meegotouch]
The documentation is here : [http://apidocs.meego.com/mtf/]

== Architecture ==
(to do)
(see documentation)
== Relation to Qt ==
The Framework sits on top of Qt. It extend it and adapt it to touchscreen interface, providing convenient classes and widget for a MeeGo Application on a touch screen.

== Should I use this framework to write an application for MeeGo ? ==
This topic was discuss in the forum here : [http://forum.meego.com/showthread.php?t=524]

The quick summary : if you value application portability and API stability it is probably better to stick with pure Qt. It is the encouraged way to built application for MeeGo.

MeeGo Touch framework may interest you only if :

* You are building an application UI specifically for MeeGo handset UX.
* You want to adopt the MeeGo style (see MeeGo handset guidelines).
* You are interested in using MeeGo widgets and notifications.
* You can cope with future change in API. MeeGo Touch framework is still evolving. For instance, part (or all) of it may be included in future version of Qt. Though you can be confident that MeeGo Touch will continue to exist and improve.

Also an other new way to code Qt apps exist : Qt Quick. it is still very new, but it could be interesting to write fast a small UI.

== How to install it ? ==

You can clone the git repositories in the source page and compile it (./configure, qmake, make install).

Also it must be run into a MeeGo chroot environment (see [[Getting started with the MeeGo SDK for Linux (Original)]]) or a MeeGo test device ([[ARM/N900]])

MeeGo Touch Framework

2010-08-27T16:00:35Z

Bzhbok: /* Should I use this framework to write an application for MeeGo ? */

MeeGo Touch is a Qt based application development framework targeting mobile touch screen devices. It is part of MeeGo API (along Qt 4.7). It provides all the necessary building blocks for creating native applications that follow the MeeGo Handset UX guidelines . The framework itself is built on top of the Qt Graphics View Framework.

The source code is here : [http://meego.gitorious.org/meegotouch]
The documentation is here : [http://apidocs.meego.com/mtf/]

== Architecture ==
(to do)
(see documentation)
== Relation to Qt ==
The Framework sits on top of Qt. It extend it and adapt it to touchscreen interface, providing convenient classes and widget for a MeeGo Application on a touch screen.

== Should I use this framework to write an application for MeeGo ? ==
This topic was discuss in the forum here : [http://forum.meego.com/showthread.php?t=524]

The quick summary : if you value application portability and API stability it is probably better to stick with pure Qt. It is the encouraged way to built application for MeeGo.

MeeGo Touch framework may interest you only if :

* You are building an application UI specifically for MeeGo handset UX.
* You want to adopt the MeeGo style (see MeeGo handset guidelines).
* You are interested in using MeeGo widgets and notifications.
* You can cope with future change in API. MeeGo Touch framework is still evolving. For instance, part (or all) of it may be included in future version of Qt. Though you can be confident that MeeGo Touch will continue to exist and improve.

Also an other new way to code Qt apps exist : Qt Quick. it is still very new, but it could be interesting to write fast a small UI.

MeeGo Touch Framework

2010-08-27T15:56:33Z

Bzhbok:

MeeGo Touch is a Qt based application development framework targeting mobile touch screen devices. It is part of MeeGo API (along Qt 4.7). It provides all the necessary building blocks for creating native applications that follow the MeeGo Handset UX guidelines . The framework itself is built on top of the Qt Graphics View Framework.

The source code is here : [http://meego.gitorious.org/meegotouch]
The documentation is here : [http://apidocs.meego.com/mtf/]

== Architecture ==
(to do)
(see documentation)
== Relation to Qt ==
The Framework sits on top of Qt. It extend it and adapt it to touchscreen interface, providing convenient classes and widget for a MeeGo Application on a touch screen.

== Should I use this framework to write an application for MeeGo ? ==
This topic was discuss in the forum here : [http://forum.meego.com/showthread.php?t=524]

The quick summary : if you value application portability and API stability it is probably better to stick with pure Qt. It is the encouraged way to built application for MeeGo.
MeeGo Touch framework may interest you only if :
- You are building an application UI specifically for MeeGo handset UX.
- You want to adopt the MeeGo style (see MeeGo handset guidelines).
- You are interested in using MeeGo widgets and notifications.
- MeeGo Touch framework is still evolving. For instance part or all of it may be included in future version of Qt. You can cope with future evolution.

Also an other new way to code Qt apps exist : Qt quick. it is still very new but could be interesting to write fast a small UI.

MeeGo Touch Framework

2010-08-27T15:25:34Z

Bzhbok: Created page with "MeeGo Touch is a Qt based application development framework targeting mobile touch screen devices. It is part of MeeGo API (along Qt 4.7). It provides all the necessary building …"

Talk:MeeGo Desktop

2010-08-06T00:24:50Z

Bzhbok:

I like the idea to make a desktop release of MeeGo. To base this desktop experience on the "netbook UX" is probably the fastest way to get started, but I think it would be even better in the longer term if the "desktop UX" could be derived from KDE :
* KDE 4 is now a mature and awesome desktop shell.
* KDE has a rich and powerfull community. Making KDE the MeeGo "Desktop UX" could boost their interest in MeeGo.
* KDE has a lot of great application for the desktop.
* KDE is completely Qt-based, so it is a smart choice considering the central role of Qt in MeeGo.
* I have read (planetkde.org or a youtube video?) that there is KDE devs interested in porting KDE to MeeGo.
[[User:Bzhbok|Bzhbok]] 21:46, 3 August 2010 (UTC)

Bzhbok,

Thanks for your comments! Using "netbook UX" helps to develop applications for MeeGo Netbook. So it should be kept. KDE or GNOME can be two add-on options.

[[User:maxayu|maxayu]] 4 August 2010

Thanks for the rapid reply. I'm not sure to understand why using the "netbook UX" helps to develop applications for MeeGo Netbook : I thought that the prefered way to make apps for MeeGo is to write it in pure Qt, regardless of the targeted UX. So the choosen desktop shell should have little impact on the way to write applications, no ?
[[User:Bzhbok|Bzhbok]] 19:54, 4 August 2010 (UTC)

Good question!

What I mean is that currently we do not have a defined set of look & feel for plain Qt apps. So if using "netbook UX", we can develop apps that have similar look & feel with "netbook UX" easier. But this does not sound like a strong reason.

Besides, I would like to expand "MeeGo for Netbook" to "MeeGo for Netbook and Desktop", so "netbook UX" can be kept.

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

[[User:Maxayu|Maxayu]] 02:58, 5 August 2010 (UTC)

I understand your desire to extand the "Netbook UX" to the desktop and it is a nice project! And your doing the coding while I'm not ( I would love to but I don't have enough time currently ) ... It is quite a difference ;-) . I haven't used much the meego netbook shell, so I wonder how suited it will be for the desktop.
Anyway the rational of my argumentation is that KDE is a very nice desktop that lacks a "flagship" distribution, like Ubuntu for Gnome. Considering the emphasize on Qt in MeeGo I was thinking it was on a good position to do that. If in a few month (since desktop is not the primary target in MeeGo) MeeGo could announce that it goes to the desktop with KDE, I'm sure it would get a lot of momentum and mindshare in the linux communities... and I would love to see something like that happening !

So the two main advantages I see for KDE :
* It is a very advanced project completelly suited for the desktop
* It has a big community of devs and users. It could be an advantage over the intel internally develloped netbook shell to get mindshare and momentum on the desktop.

[[User:Bzhbok|Bzhbok]] 00:23, 6 August 2010 (UTC)

Talk:MeeGo Desktop

2010-08-06T00:23:41Z

Bzhbok:

I like the idea to make a desktop release of MeeGo. To base this desktop experience on the "netbook UX" is probably the fastest way to get started, but I think it would be even better in the longer term if the "desktop UX" could be derived from KDE :
* KDE 4 is now a mature and awesome desktop shell.
* KDE has a rich and powerfull community. Making KDE the MeeGo "Desktop UX" could boost their interest in MeeGo.
* KDE has a lot of great application for the desktop.
* KDE is completely Qt-based, so it is a smart choice considering the central role of Qt in MeeGo.
* I have read (planetkde.org or a youtube video?) that there is KDE devs interested in porting KDE to MeeGo.
[[User:Bzhbok|Bzhbok]] 21:46, 3 August 2010 (UTC)

Bzhbok,

Thanks for your comments! Using "netbook UX" helps to develop applications for MeeGo Netbook. So it should be kept. KDE or GNOME can be two add-on options.

[[User:maxayu|maxayu]] 4 August 2010

Thanks for the rapid reply. I'm not sure to understand why using the "netbook UX" helps to develop applications for MeeGo Netbook : I thought that the prefered way to make apps for MeeGo is to write it in pure Qt, regardless of the targeted UX. So the choosen desktop shell should have little impact on the way to write applications, no ?
[[User:Bzhbok|Bzhbok]] 19:54, 4 August 2010 (UTC)

Good question!

What I mean is that currently we do not have a defined set of look & feel for plain Qt apps. So if using "netbook UX", we can develop apps that have similar look & feel with "netbook UX" easier. But this does not sound like a strong reason.

Besides, I would like to expand "MeeGo for Netbook" to "MeeGo for Netbook and Desktop", so "netbook UX" can be kept.

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

[[User:Maxayu|Maxayu]] 02:58, 5 August 2010 (UTC)

I understand your desire to extand the "Netbook UX" to the desktop and it is a nice project! And your doing the coding while I'm not ( I would love to but I don't have enough time currently ) ... It is quite a difference ;-) . I haven't used much the meego netbook shell, so I wonder how suited it will be for the desktop.
Anyway the rational of my argumentation is that KDE is a very nice desktop that lacks a "flagship" distribution, like Ubuntu for Gnome. Considering the emphasize on Qt in MeeGo I was thinking it was on a good position to do that. If in a few month (since desktop is not the primary target in MeeGo) MeeGo announce that it goes to the desktop with KDE, I'm sure it get a lot of momentum and mindshare in the linux communities... I would love to see something like that happening !

So the two main advantages I see for KDE :
* It is a very advanced project completelly suited for the desktop
* It has a big community of devs and users. It could be an advantage over the intel internally develloped netbook shell to get mindshare and momentum on the desktop.

[[User:Bzhbok|Bzhbok]] 00:23, 6 August 2010 (UTC)

Talk:MeeGo Desktop

2010-08-04T19:54:31Z

Bzhbok:

User talk:Maxayu

2010-08-03T22:01:02Z

Bzhbok: Created page with 'I would be interested in your opinion on this: http://wiki.meego.com/Talk:MeeGo_Desktop ~~~~'

I would be interested in your opinion on this:
http://wiki.meego.com/Talk:MeeGo_Desktop
[[User:Bzhbok|Bzhbok]] 22:01, 3 August 2010 (UTC)

Talk:MeeGo Desktop

2010-08-03T21:46:47Z

Bzhbok: Created page with 'I like the idea to make a desktop release of MeeGo. To base this desktop experience on the "netbook UX" is probably the fastest way to get started, but I think it would be even b…'

Main Page

2010-02-22T13:00:01Z

Bzhbok:

=== Scope ===
This wiki is the MeeGo community sandbox and documentation tool. Use it as you wish.

Expected content:
* ''Agile'' web space for community tasks and projects e.g.
** [[Maemo and Moblin community assets]]
** [[Proposal for a Community working group]]
** [[Proposal for a Localization working group]]
** [[Proposal for a Repository working group]]
** [[Meeting agenda]]
* Developer documentation.
** [[Packaging]]
** [[Packaging/Guidelines]]
** [[Build System]]
** [[Image Creation]]
** [[Image Creation For Beginners]]
** [[ARM Support]]

* FAQs, Tips & Tricks and other forms of casual documentation and collaborative content.
**[[Meego irc]]
**[[Who's who]]
**[[Glossary]]

Right now the wiki is still fairly empty - not a lot of users got a chance to see it... we didn't want to just migrate stuff over from other wikis (but we may end up doing some of that, eventually).

=== Contributors ===

Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on.

Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Structure ===
Currently there is no content and no structure. What will happen over time is up to us.

It's worth commenting that http://wiki.maemo.org contains around 1000 pages, many of them relevant here now that the Maemo platform is evolving into MeeGo. There is an active [http://wiki.maemo.org/Maemowiki_Action_Group Maemowiki Action Group]. Please feel at home in this wiki.

Main Page

2010-02-22T12:58:43Z

Bzhbok:

=== Scope ===
This wiki is the MeeGo community sandbox and documentation tool. Use it as you wish.

Expected content:
* ''Agile'' web space for community tasks and projects e.g.
** [[Maemo and Moblin community assets]]
** [[Proposal for a Community working group]]
** [[Proposal for a Localization working group]]
** [[Proposal for a Repository working group]]
** [[Meeting_agenda]]
* Developer documentation.
** [[Packaging]]
** [[Packaging/Guidelines]]
** [[Build System]]
** [[Image Creation]]
** [[Image Creation For Beginners]]
** [[ARM Support]]

* FAQs, Tips & Tricks and other forms of casual documentation and collaborative content.
**[[Meego_irc]]
**[[Who's_who]]
**[[Glossary]]

Right now the wiki is still fairly empty - not a lot of users got a chance to see it... we didn't want to just migrate stuff over from other wikis (but we may end up doing some of that, eventually).

=== Contributors ===

Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on.

Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Structure ===
Currently there is no content and no structure. What will happen over time is up to us.

It's worth commenting that http://wiki.maemo.org contains around 1000 pages, many of them relevant here now that the Maemo platform is evolving into MeeGo. There is an active [http://wiki.maemo.org/Maemowiki_Action_Group Maemowiki Action Group]. Please feel at home in this wiki.

Main Page

2010-02-19T16:33:51Z

Bzhbok:

=== Scope ===
This wiki is the MeeGo community sandbox and documentation tool. Use it as you wish.

Expected content:
* ''Agile'' web space for community tasks and projects e.g.
** [[Maemo and Moblin community assets]]
** [[Proposal for a Community working group]]
** [[Proposal for a Localization working group]]
** [[Proposal for a Repository working group]]
* Developer documentation.
** [[Packaging]]
** [[Packaging/Guidelines]]
** [[Build System]]
** [[Image Creation]]
** [[Image Creation For Beginners]]
** [[ARM Support]]

* FAQs, Tips & Tricks and other forms of casual documentation and collaborative content.
**[[Meego_irc]]
**[[Who's_who]]
**[[Glossary]]

Right now the wiki is still fairly empty - not a lot of users got a chance to see it... we didn't want to just migrate stuff over from other wikis (but we may end up doing some of that, eventually).

=== Contributors ===

Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on.

Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Structure ===
Currently there is no content and no structure. What will happen over time is up to us.

It's worth commenting that http://wiki.maemo.org contains around 1000 pages, many of them relevant here now that the Maemo platform is evolving into MeeGo. There is an active [http://wiki.maemo.org/Maemowiki_Action_Group Maemowiki Action Group]. Please feel at home in this wiki.

Main Page

2010-02-18T08:20:01Z

Bzhbok:

=== Scope ===
This wiki is the MeeGo community sandbox and documentation tool. Use it as you wish.

Expected content:
* ''Agile'' web space for community tasks and projects e.g.
** [[Maemo and Moblin community assets]]
** [[Proposal for a Community working group]]
** [[Proposal for a Localization working group]]
** [[Proposal for a Repository working group]]
* Developer documentation.
*** [[Packaging]]
*** [[Build System]]
*** [[Image Creation]]
*** [[Image Creation For Beginners]]

* FAQs, Tips & Tricks and other forms of casual documentation and collaborative content.
**[[Meego_irc]]

Right now the wiki is still fairly empty - not a lot of users got a chance to see it... we didn't want to just migrate stuff over from other wikis (but we may end up doing some of that, eventually).

=== Contributors ===

Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on.

Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Structure ===
Currently there is no content and no structure. What will happen over time is up to us.

It's worth commenting that http://wiki.maemo.org contains around 1000 pages, many of them relevant here now that the Maemo platform is evolving into MeeGo. There is an active [http://wiki.maemo.org/Maemowiki_Action_Group Maemowiki Action Group]. Please feel at home in this wiki.

Meego IRC

2010-02-18T03:44:16Z

Bzhbok:

Information collected/summarized about MeeGo from irc ('''#meego at irc.freenode.net''').

The purpose of this page is to collect initial unstructured information, however, it is expected to be deleted once detailed info is available. '''All information here is highly unofficial and speculational sometimes, reflecting individual opinions only.''' Full IRC log is available at [http://mg.pov.lt/meego-irclog http://mg.pov.lt/meego-irclog] .

== End-users ==

* qgil did not confirm or deny official release of MeeGo for N900 on irc ;)

== Community ==

* how the meego community will look like is mostly decided by maemo and moblin communities themselves

== Developer ==

* applications developed in Qt will run on N900 (probably PR1.2), MeeGo handheld and MeeGo netbook variants too.
* first MeeGo sources are expected to be public around first week of March 2010
* MeeGo will have an SDK and it won't be Windows-only
* wiki page for [[Packaging]] is now up
* There is very early packages imported from Moblin in [http://repo.meego.com/ http://repo.meego.com/]

== Devices ==
* MeeGo will have both ARM and Intel CPU support.
* Maemo 6/Harmattan name is now changed to MeeGo/Harmattan.

Meego IRC

2010-02-18T03:41:20Z

Bzhbok:

Information collected/summarized about MeeGo from irc ('''#meego at irc.freenode.net''').

The purpose of this page is to collect initial unstructured information, however, it is expected to be deleted once detailed info is available. '''All information here is highly unofficial and speculational sometimes, reflecting individual opinions only.''' Full IRC log is available at [http://mg.pov.lt/meego-irclog http://mg.pov.lt/meego-irclog] .

== End-users ==

* qgil did not confirm or deny official release of MeeGo for N900 on irc ;)

== Community ==

* how the meego community will look like is mostly decided by maemo and moblin communities themselves

== Developer ==

* applications developed in Qt will run on N900 (probably PR1.2), MeeGo handheld and MeeGo netbook variants too.
* first MeeGo sources are expected to be public around first week of March 2010
* MeeGo will have an SDK and it won't be Windows-only
* wiki page for [[Packaging]] is now up
* There is very early package imported from Moblin in [http://repo.meego.com/ http://repo.meego.com/]

== Devices ==
* MeeGo will have both ARM and Intel CPU support.
* Maemo 6/Harmattan name is now changed to MeeGo/Harmattan.

Main Page

2010-02-18T03:00:48Z

Bzhbok: /* Scope */

=== Scope ===
This wiki is the MeeGo community sandbox and documentation tool. Use it as you wish.

Expected content:
* ''Agile'' web space for community tasks and projects e.g.
** [[Maemo and Moblin community assets]]
** [[Proposal for a Community working group]]
** [[Proposal for a Localization working group]]
** [[Proposal_for_a_Repository_working_group]]
* Developer documentation.
** [[Packaging]]
** [[Build_System]]
** [[Image_Creation]]
* FAQs, Tips & Tricks and other forms of casual documentation and collaborative content.
**[[Meego_irc]]

Right now the wiki is still fairly empty - not a lot of users got a chance to see it... we didn't want to just migrate stuff over from other wikis (but we may end up doing some of that, eventually).

=== Contributors ===

Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on.

Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Structure ===
Currently there is no content and no structure. What will happen over time is up to us.

It's worth commenting that http://wiki.maemo.org contains around 1000 pages, many of them relevant here now that the Maemo platform is evolving into MeeGo. There is an active [http://wiki.maemo.org/Maemowiki_Action_Group Maemowiki Action Group]. Please feel at home in this wiki.

Main Page

2010-02-17T22:35:39Z

Bzhbok:

=== Scope ===
This wiki is the MeeGo community sandbox and documentation tool. Use it as you wish.

Expected content:
* ''Agile'' web space for community tasks and projects e.g.
** [[Maemo and Moblin community assets]]
** [[Proposal for a Community working group]]
** [[Proposal for a Localization working group]]
** [[Proposal_for_a_Repository_working_group]]
* Developer documentation.
**[[Packaging]]
* FAQs, Tips & Tricks and other forms of casual documentation and collaborative content.
**[[Meego_irc]]

Right now the wiki is still fairly empty - not a lot of users got a chance to see it... we didn't want to just migrate stuff over from other wikis (but we may end up doing some of that, eventually).

=== Contributors ===

Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on.

Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Structure ===
Currently there is no content and no structure. What will happen over time is up to us.

It's worth commenting that http://wiki.maemo.org contains around 1000 pages, many of them relevant here now that the Maemo platform is evolving into MeeGo. There is an active [http://wiki.maemo.org/Maemowiki_Action_Group Maemowiki Action Group]. Please feel at home in this wiki.

Main Page

2010-02-17T22:30:53Z

Bzhbok:

=== Scope ===
This wiki is the MeeGo community sandbox and documentation tool. Use it as you wish.

Expected content:
* ''Agile'' web space for community tasks and projects e.g.
** [[Maemo and Moblin community assets]]
** [[Proposal for a Community working group]]
** [[Proposal for a Localization working group]]
* Developer documentation.
**[[Packaging]]
* FAQs, Tips & Tricks and other forms of casual documentation and collaborative content.
**[[Meego_irc]]

Right now the wiki is still fairly empty - not a lot of users got a chance to see it... we didn't want to just migrate stuff over from other wikis (but we may end up doing some of that, eventually).

=== Contributors ===

Editing permissions are restricted to registered users. [http://meego.com/user/register Register in the main MeeGo site] and you will have single sign-on.

Consult the [http://www.mediawiki.org/wiki/Help:Contents User's Guide] for information on using the wiki software.

=== Structure ===
Currently there is no content and no structure. What will happen over time is up to us.

It's worth commenting that http://wiki.maemo.org contains around 1000 pages, many of them relevant here now that the Maemo platform is evolving into MeeGo. There is an active [http://wiki.maemo.org/Maemowiki_Action_Group Maemowiki Action Group]. Please feel at home in this wiki.

Packaging

2010-02-17T21:23:16Z

Bzhbok:

= Creating Packages for MeeGo =

The build infrastructure is not announced yet, so information here is speculative.

What is known:

*The package format used by MeeGo is RPM.

* MeeGo build tools and Infrastructure will probably derive from Moblin's (see [http://moblin.org/documentation/moblin-distro-developers-guide/moblin-infrastructure] and [http://moblin.org/documentation/moblin-distro-developers-guide/build-system]) with hopefully better support for ARM targets.

* MeeGo will use [http://en.opensuse.org/Build_Service openSUSE Build Services (OBS)].

= Upstream =

As Maemo has Debian as an upstream distribution, there have been lots of questions on what will be MeeGo's upstream, and why Maemo's relationship with Debian will be dropped. The answer is that '''MeeGo is an upstream distribution''' : the only upstream is the projects included into MeeGo such as : kernel.org, X.org, Qt, etc. MeeGo policy is to push all bug fixes to upstream projects.

Why not be Debian-based ? Having an upstream distribution has advantages and disadvantages.
Advantages : you benefit from all the packaging done in the upstream distribution, thus there is a large selection of available ported software.
Disadvantages : you have to align your build infrastructure with your upstream. You are dependent on the release cycle and architecture choices of upstream.

The choice is to have no upstream for MeeGo. It makes it easier to tailor MeeGo for its target devices, which is quite specific compared to Debian's. Maybe the Debian rhythm of updates would also be inadequate for MeeGo (smartphone OSs are currently evolving at a very rapid pace). The Moblin build tools would also not have been compatible with Debian as upstream (this is mostly nonsense, see Mer). Nonetheless MeeGo will be Linux Standard Base (LSB) compliant and its specific components will probably be available in Debian at some point.

= RPM vs DEB =

RPM and DEB in themselves are package formats with roughly equivalent features. So the question to use one or the other is more related to the build tools you decide to use. The choice for MeeGo is to use Moblin Tools and openSUSE Build Services (OBS). The RPM choice is mainly a consequence of this (this is again nonsense, see Mer).

= Some link =
*[http://lists.meego.com/pipermail/meego-dev MeeGo-dev mailing list]
*[http://www.allmeegodevices.com/2010/02/17/meego-a-whole-new-linux-ballgame/ A nice article about why no upsteam]

Packaging

2010-02-17T20:07:44Z

Bzhbok: /* Upstream */

= Creating Packages for MeeGo =

The build infrastructure is not annouced yet, so information here is to take carefully.

What is known:

*The package format used by MeeGo is RPM.

* MeeGo build tools and Infrastructure will probably derived from Moblin's one (see [http://moblin.org/documentation/moblin-distro-developers-guide/moblin-infrastructure] and [http://moblin.org/documentation/moblin-distro-developers-guide/build-system]) with hopefully better support for ARM build.

* MeeGo will use [http://en.opensuse.org/Build_Service OpenSuse Built Service (OBS)].

= Upstream =

As Meamo has Debian as an upstream distribution, there have been lots of questions on what will be MeeGo's upstream, and why to drop the relation of Maemo with Debian. The answer is that '''MeeGo is an upstream distribution''' : the only upstream is the projects included into MeeGo such as : kernel.org, X.org, Qt ...etc. MeeGo policy is to push all bug fixes to upstream projets.

Why not be Debian-based ? Having an upstream distribustion is both an advantage and a drawback.
Avantage : you benefit from all the packaging done in the upstream distribution, thus there is a large choice of software easy to port.
Drawback : you have to align the built infrastructure with the upstream. You are dependant on the release cycle and architecture choices of upstream.

The choice is to have no upstream for MeeGo. It makes it easier to tailor MeeGo for it's target devices, which is quite specific compared to Debian's one. Maybe the Debian rythm of updates would also be inadequate for MeeGo (smartphone OS are evolving at a very rapid rythm currently). The Moblin build tools would also not have been compatible with Debian as upstream. Nontheless MeeGo is Linux Standard Base (LSB) compliant and its specific component will probably be available in Debian at some point.

= RPM vs DEB =

RPM and DEB in themselves are package format with quite equivalent features. So the question to use one or the other is more related to the build tools you are willing to use. The choice for MeeGo is to use Moblin Tools and OpenSuse Built Services (OBS). The RPM choice is mainly a consequence of this.

Packaging

2010-02-17T20:07:15Z

Bzhbok: /* Upstream */

= Creating Packages for MeeGo =

The build infrastructure is not annouced yet, so information here is to take carefully.

What is known:

*The package format used by MeeGo is RPM.

* MeeGo build tools and Infrastructure will probably derived from Moblin's one (see [http://moblin.org/documentation/moblin-distro-developers-guide/moblin-infrastructure] and [http://moblin.org/documentation/moblin-distro-developers-guide/build-system]) with hopefully better support for ARM build.

* MeeGo will use [http://en.opensuse.org/Build_Service OpenSuse Built Service (OBS)].

= Upstream =

As Meamo has Debian as an upstream distribution, there have been lots of questions on what will be MeeGo's upstream, and why to drop the relation of Maemo with Debian. The answer is that '''MeeGo is an upstream distribution''' : the only upstream is the projects included into MeeGo such as : kernel.org, X.org, Qt ...etc. MeeGo policy is to push all bug fixes to upstream projets.

Why not be Debian-based ? Having an upstream distribustion is both an advantage and a drawback.
Avantage : you benefit from all the packaging done in the upstream distribution, thus there is a large choice of software easy to port.
Drawback : you have to align the built infrastructure with the upstream. You are dependant on the release cycle and architecture choices of upstream.

The choice is to have no upstream for MeeGo. It makes it easier to tailor MeeGo for it's target devices, which is quite specific compared to Debian's one. Maybe the Debian rythm of updates would also be inadequate for MeeGo (smartphone OS are evolving at a very rapid rythm currently). The Moblin built tools would also not have been compatible with Debian as upstream. Nontheless MeeGo is Linux Standard Base (LSB) compliant and its specific component will probably be available in Debian at some point.

= RPM vs DEB =

RPM and DEB in themselves are package format with quite equivalent features. So the question to use one or the other is more related to the build tools you are willing to use. The choice for MeeGo is to use Moblin Tools and OpenSuse Built Services (OBS). The RPM choice is mainly a consequence of this.

Packaging

2010-02-17T19:56:04Z

Bzhbok: /* Creating Packages for MeeGo */

= Creating Packages for MeeGo =

The build infrastructure is not annouced yet, so information here is to take carefully.

What is known:

*The package format used by MeeGo is RPM.

* MeeGo build tools and Infrastructure will probably derived from Moblin's one (see [http://moblin.org/documentation/moblin-distro-developers-guide/moblin-infrastructure] and [http://moblin.org/documentation/moblin-distro-developers-guide/build-system]) with hopefully better support for ARM build.

* MeeGo will use [http://en.opensuse.org/Build_Service OpenSuse Built Service (OBS)].

= Upstream =

As Meamo has Debian as an upstream distribution, there have been lots of questions on what will be MeeGo's upstream, and why to drop the relation of Maemo with Debian. The answer is that '''MeeGo is an upstream distribution''' : the only upstream is the projects included into MeeGo such as : kernel.org, qt ...etc. MeeGo policy is to push all bug fixes to upstream projets.

Why not be Debian-based ? Having an upstream distribustion is both an advantage and a drawback.
Avantage : you benefit from all the packaging done in the upstream distribution, thus there is a large choice of software easy to port.
Drawback : you have to align the built infrastructure with the upstream. You are dependant on the release cycle and architecture choices of upstream.

The choice is to have no upstream for MeeGo. It makes it easier to tailor MeeGo for it's target devices, which is quite specific compared to Debian's one. Maybe the Debian rythm of updates would also be inadequate for MeeGo (smartphone OS are evolving at a very rapid rythm currently). The Moblin built tools would also not have been compatible with Debian as upstream. Nontheless MeeGo is Linux Standard Base (LSB) compliant and its specific component will probably be available in Debian at some point.

= RPM vs DEB =

RPM and DEB in themselves are package format with quite equivalent features. So the question to use one or the other is more related to the build tools you are willing to use. The choice for MeeGo is to use Moblin Tools and OpenSuse Built Services (OBS). The RPM choice is mainly a consequence of this.

Packaging

2010-02-17T19:49:32Z

Bzhbok: /* RPM vs DEB */

= Creating Packages for MeeGo =

The build infrastructure is not annouced yet, so information here is to take carefully.

What is known:

*The package format used by MeeGo is RPM.

* MeeGo build tools and Infrastructure will probably derived from Moblin's one (see [http://moblin.org/documentation/moblin-distro-developers-guide/moblin-infrastructure] and [http://moblin.org/documentation/moblin-distro-developers-guide/build-system]) with hopefully better support for ARM build.

* MeeGo will use [http://en.opensuse.org/Build_Service| OpenSuse Built Service (OBS)].

= Upstream =

As Meamo has Debian as an upstream distribution, there have been lots of questions on what will be MeeGo's upstream, and why to drop the relation of Maemo with Debian. The answer is that '''MeeGo is an upstream distribution''' : the only upstream is the projects included into MeeGo such as : kernel.org, qt ...etc. MeeGo policy is to push all bug fixes to upstream projets.

Why not be Debian-based ? Having an upstream distribustion is both an advantage and a drawback.
Avantage : you benefit from all the packaging done in the upstream distribution, thus there is a large choice of software easy to port.
Drawback : you have to align the built infrastructure with the upstream. You are dependant on the release cycle and architecture choices of upstream.

The choice is to have no upstream for MeeGo. It makes it easier to tailor MeeGo for it's target devices, which is quite specific compared to Debian's one. Maybe the Debian rythm of updates would also be inadequate for MeeGo (smartphone OS are evolving at a very rapid rythm currently). The Moblin built tools would also not have been compatible with Debian as upstream. Nontheless MeeGo is Linux Standard Base (LSB) compliant and its specific component will probably be available in Debian at some point.

= RPM vs DEB =

RPM and DEB in themselves are package format with quite equivalent features. So the question to use one or the other is more related to the build tools you are willing to use. The choice for MeeGo is to use Moblin Tools and OpenSuse Built Services (OBS). The RPM choice is mainly a consequence of this.

Packaging

2010-02-17T19:38:14Z

Bzhbok: Trying to sum up what was said in MeeGo-dev mailing list, so that the same answer don't have to be made again and again. NEEDS IMPROVEMENT

= Creating Packages for MeeGo =

The build infrastructure is not annouced yet, so information here is to take carefully.

What is known:

*The package format used by MeeGo is RPM.

* MeeGo build tools and Infrastructure will probably derived from Moblin's one (see [http://moblin.org/documentation/moblin-distro-developers-guide/moblin-infrastructure] and [http://moblin.org/documentation/moblin-distro-developers-guide/build-system]) with hopefully better support for ARM build.

* MeeGo will use [http://en.opensuse.org/Build_Service| OpenSuse Built Service (OBS)].

= Upstream =

As Meamo has Debian as an upstream distribution, there have been lots of questions on what will be MeeGo's upstream, and why to drop the relation of Maemo with Debian. The answer is that '''MeeGo is an upstream distribution''' : the only upstream is the projects included into MeeGo such as : kernel.org, qt ...etc. MeeGo policy is to push all bug fixes to upstream projets.

Why not be Debian-based ? Having an upstream distribustion is both an advantage and a drawback.
Avantage : you benefit from all the packaging done in the upstream distribution, thus there is a large choice of software easy to port.
Drawback : you have to align the built infrastructure with the upstream. You are dependant on the release cycle and architecture choices of upstream.

The choice is to have no upstream for MeeGo. It makes it easier to tailor MeeGo for it's target devices, which is quite specific compared to Debian's one. Maybe the Debian rythm of updates would also be inadequate for MeeGo (smartphone OS are evolving at a very rapid rythm currently). The Moblin built tools would also not have been compatible with Debian as upstream. Nontheless MeeGo is Linux Standard Base (LSB) compliant and its specific component will probably be available in Debian at some point.

= RPM vs DEB =

RPM and DEB in themselves are package format with quite equivalent feature. So the question to use one or the other is more related to the build tools you are willing to use. The choice for MeeGo is to use Moblin Tools and OpenSuse Built Services (OBS). The RPM choice is mainly a consequence of this.