Well i've started the mobile shell, and it's not far... I just come back from vacations so i will start again hacking on it.<div><br></div><div>For now, it's just a containment (mainly stole from plasma-desktop and netbook).<div>
<br></div><div>I have implemented an applet to toggle the expose effect in the n900.</div><div><br></div><div>The road is long in order to have something usable on the n900. The applet handle should be redisign, many applets are not finger enabled (though some of them works quite nice).</div>
<div><br></div><div>And then the main problem is the lack of the documentation in the maemo side. I had to reverse engineered the dbus server to find out which signal trigger the expose effect.<br><br><div class="gmail_quote">
On Mon, Nov 23, 2009 at 10:39 PM, Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On November 23, 2009, you wrote:<br>
> > it's close, but there will be things in it that just don't fit very well.<br>
> > fortunately, plasma encourages a highly modular design and so parts that<br>
> > do make sense can be shared between plasma-netbook and plasma-mobile<br>
> > without much effort at all.<br>
> > yes; it could also be something more custom-fitted to a small screen,<br>
> > particularly when it comes to application transitions. see, for instance,<br>
> > what the palm pre or even the iphone does in this area.<br>
><br>
> So basically we would need a much more finger friendly smaller/compressed<br>
> plasma containment.<br>
> Whih shouldn't be too hard if we would "fork" the netbook maybe?<br>
<br>
</div>perhaps; i'd suggest starting with an intended user experience design and work<br>
from there, taking what we can from other places.<br>
<div class="im"><br>
> > when it comes to the n900 itself, they use an expose-like effect which<br>
> > would mean a different Plasma::View for each widget on the canvas. this<br>
> > is actually not uncommon (it's how popup applets work in the<br>
> > icon-and-dialog state, e.g. when in a panel in plasma-desktop).<br></div></blockquote><div><br></div><div>I've actually hacked something else, a full screen app...So maemo popups works well, like when somebody call for instance. Even the compositor do its job.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
><br>
> I would really like to keep the "footprint" as low as possible not just<br></div></blockquote><div><br></div><div>Pointless for now, make things works fine and then you optimize.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> from a performance point of view but also from a position that we would<br>
> have to port KWin to this special platform which could be worked around by<br>
> adding the needed pieces upon the ready made plasma right?<br>
<br></div></blockquote><div><br></div><div>KWin works out of the box without anything, it just doesn't have OpenGL support mainly because KWin effects are using raw OpenGL which is different from OpenGL ES 2.0. I don't think we need for now to replace the window manager. Matchbox works quite fine.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
</div>well, the n900 already provides this out of the box. we don't need to do<br>
anything there.<br>
<br>
there's the additional route of "creating a shell for any phone and do it from<br>
the ground up"; personally, i think we should target the n900 as step 1 and<br>
then generalize it from there. the reasons are:<br>
<br>
* we have n900s to actually run stuff on right now<br>
* it allows us to grow the project step by step instead of having to do<br>
everything at once<br>
<div class="im"><br></div></blockquote><div><br></div><div>Having a plasma-mobile, with couple of useful applets, finger oriented. Plasma mobile can works in full screen (in addition to the current hildon-desktop) would be nice for a step 1. Then we can think of creating an applet for calling and so on.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> > > would have the issue that you would get quite scared because most of<br>
> > > the mobilephone apps would have to be placed there.<br>
> ><br>
> > why would this be a problem? I'm not sure i'm seeing the issue here :)<br>
><br>
> From what I've seen on the plasma newspaper the user would either (1) need<br>
> to always drag the applet upon the newspaper or (2) KEEP all the plasmoids<br>
> for these phone special stuff upon the newspaper conatinment which makes<br>
> it either a hell of a mess or too much to load smooth enough for a daily<br>
> workflow.<br>
<br>
</div>it again comes back to what user experience plasma-mobile should offer.<br>
<br>
one possibility is:<br>
<br>
* there is a "home" screen that allows one to put multiple widgets on the<br>
screen at the same time; basically a tiny version of plasma-desktop's desktop<br>
view<br>
<br></blockquote><div><br></div><div>That is my goal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
* widgets can also be launched as a "full application", or full screen. in<br>
that case we create a separate View and show the widget in that view.<br>
<br></blockquote><div><br></div><div>Kate for instance is already running. The problem is Oxygen and the UI, it's not device enabled. KDE needs lot of work in that side. Plasma is probably one of the easiest component to have on the N900 because its flexibility.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
the question is if we allow multiple applications to run or just one at a<br>
time. if just one at a time, then there is just one view and it can<br>
load/delete widgets on request. lower resource usage, but also slower<br>
switching between apps. this is the iPhone approach fwiu.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
if multiple, then its up to the user to not launch too many at once, closing<br>
those they don't need/want. perhaps with some automatic management added in as<br>
well to keep it from getting out of hand.<br>
<br>
as for things like the phone dialing pad, contacts .. those could be handled<br>
separately and created/shown on demand.<br>
<div class="im"><br>
> > > So one of the things that would need to be inplace would be information<br>
> > > for people who are not yet involved in the development. For now small<br>
> > > wrap up on the mailing list would help to get first pointers upon from<br>
> > > where to tackle all these issues.<br>
> ><br>
> > if you ask questions, we can provide answers :)<br>
><br>
> Oki doke. I'll start off . It would be nice if you could give out pointers<br>
> to the needed svn repositories etc.<br>
<br>
</div><a href="http://svn.kde.org" target="_blank">svn.kde.org</a> for the moment, with plasma-mobile in playground/base as i pointed<br>
out earlier.<br>
<div class="im"><br></div></blockquote><div><br></div><div>It doesn't compile out of kdebase. I need to fix that :D.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
> I haven't come around to do that. To<br>
> encurage people to join us we should also to document it so others can<br>
> have a look at it.<br>
<br>
</div>agreed; we have a few steps first, particularly defining what user experience<br>
goal we want to shoot for.<br>
<div class="im"><br>
> When we do actually start to write application code for the<br>
> sms/phonecall/contacts apps for the mobile device which actual ibraries<br>
> should be taken to manage that. Will we pick the freesmartphone libraries<br>
> or will we pick on the meamo platform and keepit there?<br>
<br>
</div>if the telephony features are put into dataengines and services, this becomes<br>
a non-issue. we can target the n900 or freesmartphone libs and use the same UI<br>
on each, just by changing which dataengine/service mix is on the device.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>Me as a first step i would see Plasma running in addition of the existing GTK framework, as an alternative to hildon-desktop (better widgets, better freedom). Having KDE replacing the complete high level stack is for now too much work. For instance simple things like config dialogs in Plasma (KDialog) are completely unusable, they need a rewrite, i don't speak about konqueror, dolphin, kate and so on.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5">
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Qt Development Frameworks<br>
</div></div><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br>
<br></blockquote></div><br></div></div>