[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: toolbox (and applethandle?) architecture rewamp
From:       Giulio Camuffo <giuliocamuffo () gmail ! com>
Date:       2010-08-09 19:20:30
Message-ID: 201008092120.31052.giuliocamuffo () gmail ! com
[Download RAW message or body]

In data luned́ 09 agosto 2010 19:40:08, Aaron J. Seigo ha scritto:
> under the design i suggested, this wouldn't be necessary because the
> control element would come from, and be owned by, the Applet. the handle
> wouldn't need to do anything. the Applet could connect a signal from the
> control element it creates to its appletTransformedByUser signal.
> 
ahhh, so you mean the ControlElements are created by the applet. I thought of 
make the applet tell the element types to the handle so that the handle itself 
could create them. Anyway that way it eliminates this problem, so ++.

> a simple QObject should do. that way the handle can decide how to present
>  them.
> 
> as for the event model .. the simple approach is just to pass on the mouse
> events. it may be more interesting to allow elements that are just
> "activatable" (such as the configuration button, which only cares that its
> been activated so it can launch a config dialog) as well as elements that
>  need pointer tracking (so ... a start point, movement, end).
> 
> i think it might make the most sense to start this off as an internal,
> non-exported class (so we can change it more easily in the meantime) and
> port all of the existing actions to this mechanism. we can then see exactly
>  what kind of interaction information we want to pass on to them.
> 
> what do you think?

Sure, it's ok with me. When i'll be back home in two weeks i'll start hacking on 
it.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[prev in list] [next in list] [prev in thread] [next in thread]