
   == Declarative Desktop for Plasma ==


TODO:
* hide handle after short timeout
* fix user interaction with rotation
*


BUGS:
* drag input is blocked for folderview, debug, applet is dragged instead of rubberband or items
* folderview doesn't have "run associated application" action
* blackboard doesn't have "run associated application" action

DONE:
o ToolBox QML files move into their own package
o ToolBox is put on top of the scene in DeclarativeAppletScript::qmlCreationFinished()
o rename ToolBox.qml to ToolBoxItem.qml
o ToolBox-visible name to the runtime is ToolBox
o mouse drag expands over handle
    o move mouseventlistener into subitem to be able to manage its margins / position
    o everything else under the mouse *has to be* parented to this one, still
o minimum size for applethandle
o switch handle appearance when minimumSize is reached during resize
o implement rotation
    o rotate item
    o save rotation per item
    o restore rotation per item
o rename main to root
o rename itemgroup to AppletItem
o meaningful name for plasmoidgroup or merge into AppletItem?
o open associated app

OTHER:

/** Action Mapping for ToolBox

list-add                    Add Panel
list-add                    Add Widgets
preferences-activities      Activities                          Activities
configure-shortcuts         Shortcut Settings                   Shortcut Settings
configure                   $containment_name Settings          $containment_name Settings
object-locked               Lock Widgets
object-unlocked                                                 Unlock Widgets
system-lock-screen          Lock Screen                         Lock Screen
system-shutdown             Leave                               Leave

**/

[17:04:19] <notmart> sebas: i think should be in DeclarativeAppletScript::qmlCreationFinished, same thing as now checks if is a popupapplet and does compactrepresentation
[17:04:58] <sebas> notmart: hah, I've that file open as well
[17:05:05] <sebas> in init()
[17:05:50] <sebas> So I'll split out the toolbox into its own QML Package
[17:06:38] <sebas> but I'll still have to expose what is now InternalToolBox to the Containment
[17:06:52] <notmart> right now, to have something that works quickly, you may just load a single file
[17:07:07] --> Savago (~adenilson@200.160.100.16) has joined #plasma
[17:07:21] <sebas> it needs two elements anyway, so I suppose a package is fine
[17:07:28] <sebas> (button to open it, the toolbox itself)
[17:07:41] <notmart> aseigo: what do you think about that? ^^ (how to do toolbox)
[17:07:45] <sebas> I've basically the QML code for those already written
[17:07:54] <notmart> that's how i would do it, don't know if i'm overengineering
[17:08:05] <-> krake_ is now known as krake
[17:08:28] <sebas> I don't really see a problem with putting the toolbox directly into the containment, but I might be missing some plugin architecture behind it
[17:08:42] <sebas> and it should be possible to share the toolbox between containments
[17:08:49] <aseigo> terietor: m_namedFiles gets all the files with key names in the model...
[17:09:26] <aseigo> notmart: looks reasonable i think
[17:09:46] <aseigo> sebas: it gets used by several different containments
[17:09:50] <aseigo> folderview and desktop, e.g.
[17:10:00] <sebas> notmart, aseigo: is the InternalToolBox api-wise OK with you to expose to both containment and ToolBox?
[17:10:46] <aseigo> terietor: and then in PackageModel::data it assumes that the # of files listed == the # of keys (m_namedFiles)
[17:10:57] <notmart> sebas: looks sensible

