So, as I mentioned in my previous entry (http://blog.rburchell.com/2010/02/future-of-n900-what-meego-means.html), there isn't a huge need to worry about MeeGo.
After doing some more reading around the internet, I thought I'd best address another facet of this - that of application compatibility.
A lot of people seem to be of the assumption that MeeGo will be completely incompatible with everything out there, and really, this isn't the case.
For starters, take Maemo. MeeGo has a very similar stack to Maemo. It's basically Linux. It has X, Qt and Gtk+, and all the other things you're used to. Software using it will continue to work. It might need some packaging work, but that's not a big deal, and better minds on mine will hopefully come up with ways to minimise the amount of work needed here.
For Qt applications, this will already be very minimal with tools like MADDE helping cross compilation and packaging, and one can only presume that this *will* get better. In fact, Qt if anything, as with Maemo, is *helping* application compatibility, as software written for totally different platforms is easier to get running, due to Qt doing most of the heavy lifting for just about all parts of an application (audio, video, graphics..).
Again, I'd like to appeal for some sanity and a sense of calm here. This isn't the end of things, it's the start of something *much* bigger, and we're all a part of it.
Planet maemo: category "feed:a93f39245539231538463d349e184dd2"
Hopefully I've helped settle a few minds with this post to meego-dev.
After a lot (and boy, do I mean a lot) of reading, writing, and
discussing the RPMvsDEB scenario ad nauseum, and a more recent
discussion, I thought it might be good to put some positive energy
into the discussion, so here goes.
I'm sorry to add yet more fuel to this fire, but hopefully this will
help douse the flames, rather than raise them higher.
RPM - Why?
----------
Full disclaimer - I am not a packaging expert, but am writing this to
try summarise what I know for the benefit of the community as a whole
so that we can all channel the energy that has been devoted into this
issue into something more productive and exciting.
I would welcome any commentry on this. Should it be seen as suitable,
perhaps it might be an idea to put something similar to this up as an
FAQ item, as this certainly has been asked frequently.
--
A lot of discussion and questions have arisen over the past few days
through the Maemo and Moblin merge into MeeGo, with a lot of it
centering around one particular issue: that of RPM vs DEB packaging.
The current state of things is as such - Moblin uses RPM, Maemo uses
DEB - but this issue is not as simple as a packaging format, it's an
entire toolset. I'd also like to very quickly and emphathetically note
that this is purely addressing RPM and DEB, not Fedora and Debian, or
yum vs apt-get, or anything like that.
Maemo's toolset, in the form of scratchbox, sbmock, autobuilder and
co) has a number of kinks which have caused all sorts of fun issues,
but at the end of the day, have worked.
Moblin's toolset has equivilents to do package building - but then, a
lot more, which is not currently available for Maemo. There are
various other tools which are needed to further aid development, such
as the image creator
(http://moblin.org/documentation/moblin-image-creator-2/using-moblin-image-creator).
With this in mind, it is clear that Moblin's toolset has a number of
more capabilities to add that will infinitely benefit development and
QA, which is definitely an advantage to MeeGo, unfortunately, some
elements within this chain do not work with RPM.
It may of course be theoretically possible to rework these tools to
work with a different format (or multiple formats), but let us take a
step back and consider how pragmatic a decision that is, when at the
end of the day, we are talking about a format - both of which bear a
lot in common.
While possible, perhaps - just perhaps - there are other more
important priorities to focus on, and a bigger picture - above the
religious warfare - to keep in mind: that while we have gained RPM, we
have also gained organisation, a solid process and great tools built
to engage the wider community.
There's been a lot of chatter recently about the Maemo+Moblin merger, particularly, a lot of fear from N900 owners about the future of their devices, and how MeeGo fits into that. This isn't anything new, I might add - there has been a huge storm on talk.maemo.org the past month about Maemo 6 on the N900. From my perspective at least, this is all fairly ill founded, and I think that a measure of patience and calm is needed.
There isn't a lot of technical reasons why it won't happen with either of them, and with MeeGo at least, it is fully open and community driven, so there should be no *other* obstacles to people teaming up and making it happen. There has already been discussion on #meego about making this happen, and it's only day two!
In the meantime, more updates for Maemo 5 are sure to follow - PR 1.2, the next reasonably sized update is being talked about increasingly on #maemo on freenode, which hopefully means it isn't too far away.
It's very easy to be pessimistic, it's very easy to worry that your device won't be unusable.
Don't take the easy route: fit into the MeeGo community and make things happen.
There isn't a lot of technical reasons why it won't happen with either of them, and with MeeGo at least, it is fully open and community driven, so there should be no *other* obstacles to people teaming up and making it happen. There has already been discussion on #meego about making this happen, and it's only day two!
In the meantime, more updates for Maemo 5 are sure to follow - PR 1.2, the next reasonably sized update is being talked about increasingly on #maemo on freenode, which hopefully means it isn't too far away.
It's very easy to be pessimistic, it's very easy to worry that your device won't be unusable.
Don't take the easy route: fit into the MeeGo community and make things happen.
Second tutorial for PySide, this time focusing on Qt's signals and slots system, trying to provide a simple example of how they can be chained together to provide simpler code.
# Written by Robin Burchell
# No licence specified or required, but please give credit where it's due, and please let me know if this helped you.
# Feel free to contact with corrections or suggestions.
#
# We're using PySide, Nokia's official LGPL bindings.
# You can however easily use PyQt (Riverside Computing's GPL bindings) by commenting these and fixing the appropriate imports.
from PySide.QtCore import *
from PySide.QtGui import *
#from PyQt4 import *
#from PyQt4.QtCore import *
#from PyQt4.QtGui import *
import sys
class MyMainWindow(QWidget):
def __init__(self):
QWidget.__init__(self, None)
vbox = QVBoxLayout()
# Let's create two sliders widgets.
# http://doc.trolltech.com/4.6/qslider.html
sone = QSlider(Qt.Horizontal)
vbox.addWidget(sone)
stwo = QSlider(Qt.Horizontal)
vbox.addWidget(stwo)
# Link the first slider to the second.
# Think of this as an event and listener system - a signal is an event, and it can have multiple listeners.
# A slot is a listener to an event.
#
# Signals are generally used whenever an action occurs which might require a reaction, or feedback - for example,
# a user clicking on a button, or a slider value changing.
#
# A signal can provide one (or more) parameters, which can then be used in the corresponding slot(s).
#
# In this example, we're linking the valueChanged signal to setValue on the second slider, meaning that whenever the
# first slider is moved, the second slider will move with it.
#
# This might look strange when compared with the .NET and other typical methods of doing it, but it
# really is much more natural and easier to express.
# See also:
# http://doc.trolltech.com/4.6/signalsandslots.html
self.connect(sone, SIGNAL("valueChanged(int)"), stwo, SLOT("setValue(int)"));
# Set the layout on the window: this means that our button will actually be displayed.
self.setLayout(vbox)
if __name__ == '__main__':
app = QApplication(sys.argv)
w = MyMainWindow()
w.show()
app.exec_()
sys.exit()
I recently met an acquaintance around Maemo (hi Khertan!) who was having problems coming to grips with how to use Qt in general. He's a python developer currently, with exposure to Gtk+, so I thought I'd write up some help for him to read over.