>> On the other hand, it was a lot easier to start the same from scratch on >> Startup wizard with Clutter because there >> was not the incompatible way of thinking as a barrier between the desired >> functionality and what is already there because there was >> nothing there already, just start from grass root level from atomic blocks >> (start by building a custom ClutterActor) >> and then figure out how to stack Actors and how to animated them to get e.g. >> a kinetic scroll list done. As there was no base widget, there >> was no limitations of the base widget and no associated problems, just >> putting some lego blocks together and it was done. With some >> adjustable parameters and then fine tuning the feel with these parameters, >> it was actually quite efficient to do it. >Sure but the question here is not to make super customized widgets but >rather to use widgets the way they should be used in an interface, >following the established guidelines to provide the user with a nice >experience. > >If you have custom widgets in every program on a system, users will find >it harder to use. They will not know what to expect when they tap on a >widget they never saw before... that's the point of having guidelines.
Please read my sentences above. I meant about replicating the functionality of the widget done with other technology with another and ending up with exactly the same user experience. It is possible and the guidelines can be followed to create the new widgets. There is nothing that prevents that, it is just some additional work required for the developer as there are hildon widgets lacking from the selection of widgets on the Qt side. If you compare the kinetic scroll list on the startup wizard to the kinetic scroll list elsewhere, you may find that it functions the same way, despite that is Clutter and elsewhere it is Gtk. Similarly I am sure it can be done also with the Qt in the same way, so that as end user you can't see the difference (except that on different toolkits there may be slight performance differences, e.g. pure clutter can be obviously faster than Gtk and similarly the performance may differ on the Qt version to direction or another depending on the case). It just requires accurate tuning for all the parameters to get the scroll behavior exactly the same and then basically the end result is the same. It is possible, and not even hard, it just needs some work and fine tuning. The Qt port is implemented with the community and the community and community can propose patches to Antonio/Kate instead so that the implemented widgets can be joined to the their port rather than everybody implementing their own versions without contributing them to the port ending up with different results on each program. Of course nobody prohibits people to do that either, this is free software and you have the freedom of choice always to do one way or the another. What comes to the kinetic scroll list, it has certain little details that are important, otherwise it will feel different (and not right): - edge bounce - easing on edge bounce (the movement decelerates before it stops instead of stopping mechanically) - friction - inertia - scrolling speed (comes from the physics of the friction, inertia, and the initial speed given by the finger) - finger following - item selection sensitivity from touch - item deselection sensitivity from following movement - stoppable movement (despite of high inertia, stopped finger stops the movement immediately) To get these right, it really requires trying out on the device how it feels. When doing the startup wizard we found that some sensitivities (e.g. selection sensitivity) need to be a bit different when operated on mouse than when operated on finger on the device. Once the list is perfected, all the other widgets are easily composited from these lists and other widgets. So it is a good idea to start from making a list on Qt to function exactly like it functions on the Hildon. Best Regards, Karoliina _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
