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.
For now, it's just a containment (mainly stole from plasma-desktop and netbook). I have implemented an applet to toggle the expose effect in the n900. 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). 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. On Mon, Nov 23, 2009 at 10:39 PM, Aaron J. Seigo <ase...@kde.org> wrote: > On November 23, 2009, you wrote: > > > it's close, but there will be things in it that just don't fit very > well. > > > fortunately, plasma encourages a highly modular design and so parts > that > > > do make sense can be shared between plasma-netbook and plasma-mobile > > > without much effort at all. > > > yes; it could also be something more custom-fitted to a small screen, > > > particularly when it comes to application transitions. see, for > instance, > > > what the palm pre or even the iphone does in this area. > > > > So basically we would need a much more finger friendly smaller/compressed > > plasma containment. > > Whih shouldn't be too hard if we would "fork" the netbook maybe? > > perhaps; i'd suggest starting with an intended user experience design and > work > from there, taking what we can from other places. > > > > when it comes to the n900 itself, they use an expose-like effect which > > > would mean a different Plasma::View for each widget on the canvas. > this > > > is actually not uncommon (it's how popup applets work in the > > > icon-and-dialog state, e.g. when in a panel in plasma-desktop). > 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. > > > > I would really like to keep the "footprint" as low as possible not just > Pointless for now, make things works fine and then you optimize. > > from a performance point of view but also from a position that we would > > have to port KWin to this special platform which could be worked around > by > > adding the needed pieces upon the ready made plasma right? > > 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. > well, the n900 already provides this out of the box. we don't need to do > anything there. > > there's the additional route of "creating a shell for any phone and do it > from > the ground up"; personally, i think we should target the n900 as step 1 and > then generalize it from there. the reasons are: > > * we have n900s to actually run stuff on right now > * it allows us to grow the project step by step instead of having to do > everything at once > > 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. > > > > would have the issue that you would get quite scared because most of > > > > the mobilephone apps would have to be placed there. > > > > > > why would this be a problem? I'm not sure i'm seeing the issue here :) > > > > From what I've seen on the plasma newspaper the user would either (1) > need > > to always drag the applet upon the newspaper or (2) KEEP all the > plasmoids > > for these phone special stuff upon the newspaper conatinment which makes > > it either a hell of a mess or too much to load smooth enough for a daily > > workflow. > > it again comes back to what user experience plasma-mobile should offer. > > one possibility is: > > * there is a "home" screen that allows one to put multiple widgets on the > screen at the same time; basically a tiny version of plasma-desktop's > desktop > view > > That is my goal. > * widgets can also be launched as a "full application", or full screen. in > that case we create a separate View and show the widget in that view. > > 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. > the question is if we allow multiple applications to run or just one at a > time. if just one at a time, then there is just one view and it can > load/delete widgets on request. lower resource usage, but also slower > switching between apps. this is the iPhone approach fwiu. > if multiple, then its up to the user to not launch too many at once, > closing > those they don't need/want. perhaps with some automatic management added in > as > well to keep it from getting out of hand. > > as for things like the phone dialing pad, contacts .. those could be > handled > separately and created/shown on demand. > > > > > So one of the things that would need to be inplace would be > information > > > > for people who are not yet involved in the development. For now > small > > > > wrap up on the mailing list would help to get first pointers upon > from > > > > where to tackle all these issues. > > > > > > if you ask questions, we can provide answers :) > > > > Oki doke. I'll start off . It would be nice if you could give out > pointers > > to the needed svn repositories etc. > > svn.kde.org for the moment, with plasma-mobile in playground/base as i > pointed > out earlier. > > It doesn't compile out of kdebase. I need to fix that :D. > > I haven't come around to do that. To > > encurage people to join us we should also to document it so others can > > have a look at it. > > agreed; we have a few steps first, particularly defining what user > experience > goal we want to shoot for. > > > When we do actually start to write application code for the > > sms/phonecall/contacts apps for the mobile device which actual ibraries > > should be taken to manage that. Will we pick the freesmartphone > libraries > > or will we pick on the meamo platform and keepit there? > > if the telephony features are put into dataengines and services, this > becomes > a non-issue. we can target the n900 or freesmartphone libs and use the same > UI > on each, just by changing which dataengine/service mix is on the device. > > 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. > -- > Aaron J. Seigo > humru othro a kohnu se > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 > > KDE core developer sponsored by Qt Development Frameworks > > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel