On Tue, 2007-11-13 at 16:21 +0100, Murray Cumming wrote:
> I remember seeing an iTunes-ish demo at GUADEC, showing a track listing
> in a "window". I think it scrolled. Is there some code I can look at for
> that or something similar, to see how you implemented that?
the list was created positioning actors inside a group and using
textures and rectangles to enforce the idea of a layout. that's more or
less how UIs should be written with Clutter; it gets easier with
ClutterScript, because you don't have to recompile to reload the scene
itself. it's possible to create fairly complex scenes with ClutterScript
and using effects for handling transitions.
handling scrollable actors is something we'd like to support, at least
at API level, but it usually boils down to (with Clutter trunk):
- use the captured-event signal on the stage to detect motion
events and start/stop the dragging phase
- use the delta between the initial press and the current motion
event coordinates
- move the wanted actor using the new coordinates
the captured-event makes this easier because:
i. you have a single entry point for all the panning/dragging
ii. you can intercept events before they reach the reactive actors
iii. you don't have to enable motion events on actors, as the
stage will always get the motion events
a Scrollable container/interface would probably be useful for
automagically clipping depending on a given set of values, so if someone
wants to cook up a container doing it I'd be happy to review the patch.
as for a row-oriented layout, you can look at how Woohaa (the toy video
player) implements a scrollable list view.
> What's the general plan with these higher-level building blocks in
> clutter? You already have ClutterEntry. Do you plan to add buttons,
> menus, etc,
Clutter core should always remain canvas-like. we are actually thinking
to remove all the layout containers (ClutterBox and children) and layout
interface (ClutterLayout) and keep just the free-form container for 0.6.
high-level "widgets" would go inside an ad hoc library, or even multiple
(competing) libraries, and if something general-purpose comes up we
could integrate it into Clutter itself.
for the intended type of applications and platforms, writing "standard
looking" UI elements *into* Clutter is not what we want. to be even more
clear, it's not that you can't re-implement GTK+ widgets with Clutter:
it's that those reimplementations would go into a Clutter-based toolkit
and not Clutter core.
> or do you plan to make regular GTK+ widgets appear less
> alien as clutter actors?
this depends on the ability of actually embedding GTK+ widgets inside a
Clutter scenegraph, which unfortunately doesn't depend on Clutter.
ciao,
Emmanuele.
--
Emmanuele Bassi, OpenedHand Ltd.
Unit R, Homesdale Business Centre
216-218 Homesdale Rd., Bromley - BR12QZ
http://www.o-hand.com
--
To unsubscribe send a mail to [EMAIL PROTECTED]
