mirror of
https://bitbucket.org/smil3y/kde-workspace.git
synced 2025-02-23 18:32:50 +00:00
plasma: remove irrelevant design files
things like notifications and tray are actually applets, the plasmoids are to be reimplemented and eventually even the declarative and scripting glue-code is going to get it Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
This commit is contained in:
Ivailo Monev
parent
470df939a9
commit
35b752c860
9 changed files with 0 additions and 361 deletions
|
|
@ -79,8 +79,3 @@ as a dialog, to the user.
|
|||
A settings dialog is provided for the DesktopView (a second page in the same dialog as the wallpaper)
|
||||
|
||||
This dialog allows selecting one trigger for each installed plugin.
|
||||
|
||||
Future Work
|
||||
-----------
|
||||
* Current UI in shells/desktop/ needs work.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,33 +0,0 @@
|
|||
|
||||
Context is about who i am, where i am, and what i'm doing. It's my identiity, my environment and my activities.
|
||||
|
||||
Identity
|
||||
---------
|
||||
|
||||
[note: I don't think I really grok this. someone please find a better way to explain it]
|
||||
My identity is... me. And my various hats. My logins for IM, facebook, email, etc. My status. The ability to have a separate identity for work? social desktop stuff?
|
||||
It's also your login - files, config, etc.
|
||||
|
||||
|
||||
Environment
|
||||
-----------
|
||||
|
||||
My environment affects a lot of little things. The room lighting affects the ideal brightness of my screen. Battery state affects how aggressive the laptop's powersaving should be. Time of day and location can be good predictors of what i'm working on (or whether silent mode is a good idea). Location can also indicate what timezone and weather is most useful. Network availabiity and my device formfactor affect what i can do. Who's with me is important too- i don't want my private stuff out when there are people looking over my shoulder. The computer can't detect all of those, but it should take advantage of whatever information it *does* have.
|
||||
|
||||
|
||||
Activities
|
||||
----------
|
||||
|
||||
My activities affect how i work. Each project tends to have its own files, resources and tools - with some degree of overlap, of course. When i'm working on one, i want everything for that task at my fingertips, and all unrelated things out of my way. I may even want a separate identity for some of them...
|
||||
|
||||
The current activity is what i'm doing *now*, and the others are things i have been doing (and probably will return to).
|
||||
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
|
||||
Activities have been implemented; identity and environment have not.
|
||||
|
||||
in libplasma, there is a Context class; this has become a class to hold context information that is *local* to a containment (like which activity it belongs to); each containment has its own Context*. global context, such as location, will probably be held elsewhere when it is implemented.
|
||||
|
||||
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
Random ideas for animations usage
|
||||
|
||||
== Animation code ==
|
||||
|
||||
- improve the design (in progress)
|
||||
- rewind the animation ............................................ done!
|
||||
- cache the animations ............................................ done!
|
||||
- cache the animation parameters
|
||||
- pulser using pixmap ............................................. done!
|
||||
- fix opacity in pulser
|
||||
- ZoomAnimation
|
||||
- GeoAnimation
|
||||
|
||||
|
||||
== Pimp my plasmoid ==
|
||||
|
||||
1) ublog
|
||||
- edit box moved to inside of scrollwidget scrollwidget::ensureitemvisible()
|
||||
- rotation when changing Timeline --> Replies --> Messages
|
||||
- pulse on link selection
|
||||
- fade in when selecting edit box
|
||||
- drop shadow on photo
|
||||
|
||||
|
||||
2) dictionary
|
||||
- new busy widget
|
||||
- kinetic scrolling
|
||||
|
||||
|
||||
3) rss reader
|
||||
- slide for post paging
|
||||
- pulse for selection
|
||||
|
||||
|
||||
4) weather plasmoid
|
||||
- slide left <----> right for details X "3 days views"
|
||||
- animated objects (sun, clouds, etc)
|
||||
|
||||
|
||||
== plasma-netbook ==
|
||||
|
||||
- pulse the whole applet when click the maximize button in the
|
||||
titlebar of the applets in the newspaper (maybe reuse it in plasma-desktop)
|
||||
- grow/shrink on selection
|
||||
- pulse on click
|
||||
- animated layouts .................................................. done!
|
||||
- kinetic scrolling: for scrollwheel events in panel ................ done!
|
||||
|
||||
|
||||
== plasma widgets ==
|
||||
|
||||
- port then to new plasma::Animator
|
||||
- tune up busy widget (small circles expand and fade out)
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
Notifications visualization
|
||||
===========================
|
||||
|
||||
Overview
|
||||
--------
|
||||
Plasma-desktop offers facilities to display the visual notifications confirming to the Freedesktop's notification specification, this document describes the component used to achieve the visualization in the most informative, while less distracting way.
|
||||
|
||||
Components
|
||||
----------
|
||||
* Notification dataengine: this exposes the org.freedesktop.Notifications interface, collecting notifications arriving from all applications, in a cross-desktop fashion.
|
||||
As all dataengines, it organizes the notification datafields in a Plasma::Dataengine::Data structure
|
||||
* Systemtray widget: (TODO: move out of systray) the widget connects to the Notifications dataengine and provides a proper visualization for the arriving notifications. An important distinction is done between the "alert" aspect of them and a pure informative one, providing two different user interfaces for them.
|
||||
|
||||
Visualization components
|
||||
------------------------
|
||||
|
||||
Alert
|
||||
|
||||
As soon as notifications arrive, they are placed in the NotificationStack widget: it is an automatic popup, so in order to disturb the user workflow as less as possible, the size is kept fairly small, limiting the maximum nuber of notification displayed. For the same reason ony one notification at a time is displayed: the oldest (newest?) one, with the others partially covered, but permitting to still see the title.
|
||||
Moving the mouse over the title of the semi-hidden notifications will show them completely.
|
||||
The NotificationStack window is always on top of every other window.
|
||||
When a new notification arrives it is added in the NotificationStack with the following strategy:
|
||||
* Let MAX be the maximum number of allowed notifications, usually 4
|
||||
* If the current displayed notifications is less than MAX place the new notification partially covered in the last position
|
||||
* If MAX notifications are already there
|
||||
* If there i at least one notification of the same application remove it (or the oldest if more than one)
|
||||
* Elese remove the oldest notification from the stack
|
||||
* Place the new notification partially covered in the last position
|
||||
|
||||
To view partially hidden notifications is enough to move the mouse over its title. the notification will show, hiding the previously showing one.
|
||||
Clicking on an action button, removes a notification from the stack.
|
||||
Clicking anywhere in the stack area hides the whole stack, but in order to prevent accidental closing, only after a second of timeout after
|
||||
* A new notification appeared
|
||||
* A notification was open, closing the old one
|
||||
|
||||
|
||||
Information
|
||||
|
||||
If the user missed some notification, it's possible to view the old ones by manually invoking a different ui by hitting the "i" button.
|
||||
The notifications are contained in a widget called NotificationScroller, that appears as a popup window. A tabbar lets the user filter the notifications by the sender application (useful for instance if the user is looking for informations about completition of an old running file tranfer or battery warning notices).
|
||||
Notifications are in a scrolling view that permits a fairly large amount of those to be displayed without using too much screen space.
|
||||
It features also the the following behaviour:
|
||||
* If a new notification arrives the current status of the widget is not changed, to not interrupt the user workflow. (current selected tab and scrollbar value)
|
||||
* If the user manually dismisses a notification, bot there and in the NotificationStack it goes away both in the NotificationStack and in the NotificationScroller
|
||||
|
||||
|
||||
Notifications and jobs
|
||||
----------------------
|
||||
|
||||
Alert
|
||||
|
||||
* Completed jobs are treated as any other notification. They appear in the NotificationStack at first and are left available for a while in the NotificationScroller
|
||||
* When there is at least one running job a tiny popup containing only a progressbar and a brief summary is always shown, unless the main popup with controls for each individual job is open. It shows the average of progress of all jobs, we will now refer to it as JobsOverview
|
||||
* JobsOverview is shown on top of every other window at first, but other windows that gain focus after it can cover the JobsOverview window
|
||||
* If the main popup is opened, JobsOverview is hidden, shown automatically again as soon as the main popup is closed.
|
||||
* When the NotificationStack appears, the JobOverview is automatically moved to make room for the notifications, and moved back again when NotificationStack is hidden.
|
||||
|
||||
|
||||
Information
|
||||
|
||||
When the user opens the main widget popup that contains the NotificationScroller, if there are running jobs, they are shown individually as ExtenderItems in the same popup. The extenderItem contains:
|
||||
* A title with the application icon, the job type (such as copying, moving or deleting) and controls to pause/stop or resume the job
|
||||
* The body contains
|
||||
* The source and destination URLs
|
||||
* A progressbar to show the job status
|
||||
* Optional extra informations such as file size, transfer speed and size already transfered
|
||||
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
Plasmoids
|
||||
=========
|
||||
|
||||
What is a widget?
|
||||
================
|
||||
In the context of Plasma, a "widget" is a single, self-contained graphical object on the canvas. They can be added and removed individually, configured separately from other widgets, etc. These "mini appliations" are sometimes referred to in other widget platforms as "applets", "apps", "gadgets", "karambas", "desklets". We chose the word "widget" for Plasma as it is used by other some other existing systems.
|
||||
|
||||
The API of a widget is defined by the host "ScriptEngine", with the exception of native Plasma widgets written in C++ which allows plugins in loadable librareis which use the API of the Plasma library directly. Currently Plasma supports both such "native" widgets written in C++, ones written in various dynamic languages (Plasmoids) as well as:
|
||||
|
||||
* SuperKaramba's karambas
|
||||
* Enlightenment 17 edje content
|
||||
* MacOS dashboard widgets (though not all)
|
||||
|
||||
These are loaded via host AppletScriptEngine plugins that bridge between the widget itself and Plasma's canvas.
|
||||
|
||||
What is a Plasmoid?
|
||||
==================
|
||||
A Plasmoid is a widget that can be loaded into Plasma that uses the native Plasma API and comes packaged in a single archive file that includes the code, metadata, images, configuration defintions, etc. Plasmoids may be currently written in the following languages / APIs:
|
||||
|
||||
* HTML/JavaScript widgets (essentially "web pages for Plasma"): they are limited to a small subset of the Plasma library API and DataEngines
|
||||
* Simplified JavaScript: these are written in JavaScript but use a managed set of API from the Plasma library and elsewhere; these are the most likely to be widely portable between Plasma instances and are the most securable.
|
||||
* Full JavaScript: a work in progress, this provides full access to the Plasma, KDE and Qt APIs
|
||||
* Ruby: full access to the Plasma, KDE, Qt and other Ruby APIs are provided
|
||||
* Python: full access to the Plasma, KDE, Qt and other Python APIs are provided
|
||||
|
||||
The Plasmoid Package
|
||||
====================
|
||||
A Plasmoid package is a single archive file compressed using the zip compression algorithm. By convention they have a .plasmoid suffix.
|
||||
|
||||
The layout of a Plasmoid package is as follows, starting with the root (/) being the top of the zip archive:
|
||||
|
||||
metadata.desktop: a .desktop file (INI format) following the standard KPluginInfo layout. See more about this file below.
|
||||
contents/
|
||||
code/ -> where all the scripts are kept
|
||||
main -> by default, the name of the script to start the Plasmoid from
|
||||
config/ -> KConfigXT and INI files describing configuration variables
|
||||
main.xml -> main config file, KConfigXT xml
|
||||
default-configrc -> default configuration, INI file
|
||||
configui/ -> Qt Designer files describing configuration dialog pages
|
||||
config.ui -> main configuration UI
|
||||
images/ -> image files of various formats
|
||||
translations/ -> po files for individual translations; each translation should appear in subdirectories named after the language code
|
||||
ui/ -> user interface description files, usually Qt Designer
|
||||
|
||||
The Metadata File
|
||||
=================
|
||||
The metadata.desktop file contains information about the widget that is critical to proper function. This file is a standard "INI format" file with one group in it called [Desktop Entry]. A typical such file appears below:
|
||||
|
||||
[Desktop Entry]
|
||||
Name=JavaScript Animations
|
||||
Comment=An example showing how animations can be used from JavaScript
|
||||
Encoding=UTF-8
|
||||
Icon=plasma
|
||||
ServiceTypes=Plasma/Applet
|
||||
Type=Service
|
||||
X-KDE-PluginInfo-Author=Aaron Seigo
|
||||
X-KDE-PluginInfo-Category=Examples
|
||||
X-KDE-PluginInfo-Depends=
|
||||
X-KDE-PluginInfo-Email=foo@bar.org
|
||||
X-KDE-PluginInfo-EnabledByDefault=true
|
||||
X-KDE-PluginInfo-License=BSD
|
||||
X-KDE-PluginInfo-Name=javascript-animations-example
|
||||
X-KDE-PluginInfo-Version=0.1
|
||||
X-KDE-PluginInfo-Website=http://foo.bar/
|
||||
X-Plasma-API=javascript
|
||||
|
||||
The icon can either refer to a file in the root of the package by the same name, or a standard icon theme icon name.
|
||||
|
||||
Important fields include:
|
||||
|
||||
* X-KDE-PluginInfo-Name= what the widget will be referred to internally and MUST be unique; as such a "reverse domain name" approach is a good idea, e.g. "org.foo.somewidget".
|
||||
* X-Plasma-API entry defines which language and API the widget is written for and dictates which ScriptEngine will be loaded for it.
|
||||
|
||||
Useful optional fields include:
|
||||
* X-Plasma-MainScript= path relative to the contents/ dir of the package; used to override the default of "contents/code/main"
|
||||
* X-Plasma-DefaultSize= a good initial size for the widget given in the form x,y
|
||||
|
||||
Installing and Replacing
|
||||
========================
|
||||
Plasmoid packages can be installed and removed from the Add Widgets interfaces of various Plasma applications, such as plasma desktop, or directly using the plasmapkg binary. See the output of `plasmapkg --help` for more information on using that utility.
|
||||
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
Standard Graphical Effects
|
||||
==========================
|
||||
|
||||
This document lists the standard effects provided by (or yet to be implemented) in libplasma.
|
||||
|
||||
CrossFade
|
||||
---------
|
||||
Fades between two images.
|
||||
|
||||
Parameters:
|
||||
* Source image
|
||||
* Destination image
|
||||
* Timelapse (0 -> use standard time setting)
|
||||
|
||||
Spin
|
||||
----
|
||||
Creates the illusion of spinning an item to show its back.
|
||||
|
||||
Parameters:
|
||||
* Source QGraphicsItem
|
||||
* Destination QGraphicsItem
|
||||
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
The system tray widget is divided into three parts: core, ui and protocols.
|
||||
|
||||
Core
|
||||
----
|
||||
Core provides the three basic concepts that drive the widget:
|
||||
* Task: an icon in the tray
|
||||
* Notification: a visual notification from an application
|
||||
* Job: a long running job such as a file transfer
|
||||
|
||||
Protocol implements a source for Tasks, Notifications and/or Jobs and has a set
|
||||
of signals used to announce the coming and going of its items. At its discretion,
|
||||
a Protocol can create (or destroy) Tasks, Notifications and Jobs at any time.
|
||||
|
||||
A Manager class is provided in Core that looks after and tracks the three kinds of items
|
||||
along with all the Protocols. The Manager instantiates the Protocols and relays the
|
||||
critical signals, allowing the widget to simply pay attention to the Manager and
|
||||
treat all Tasks, Notifications and Jobs as if they came from the same place. The Manager
|
||||
is able to treat all Protocols generically using the Protocol API.
|
||||
|
||||
All Task implementations provide a way to return a QGraphicsWidet for given host.
|
||||
The mapping between hosts and widgets is handled automatically by the Task class, and
|
||||
this, along with the central Manager, allows any Task to be shared simultaneously across
|
||||
multiple widgets.
|
||||
|
||||
Notifications and Jobs don't have this problem as they simply provide access to
|
||||
data which the ui is reponsible for showing in some way.
|
||||
|
||||
Also provided in the core is a Task specifically for managing the Extenders of a host
|
||||
Plasma::Applet for Jobs and Notifications call, rather creatively, ExtenderTask.
|
||||
|
||||
|
||||
Protocols
|
||||
---------
|
||||
The following protocols currently exist:
|
||||
|
||||
DBusSystemTrayProtocol: support for the dbus driven NotificationItem; it provides Tasks;
|
||||
for information on the design of this protocol, consult the
|
||||
KStatusNotifierItem documentation
|
||||
|
||||
FdoProtocol: support for the XEmbed based freedesktop.org system tray specification;
|
||||
it provides Tasks, though these tasks do not work properly in more than one
|
||||
widget at a time due to limitations in the XEmbed system
|
||||
|
||||
JobsProtocol: access to the applicationjobs DataEngine; it provides Jobs
|
||||
|
||||
NotificationsProtocol: access to the notificadtions DataEngine; it provides Notifications
|
||||
|
||||
PlasmoidProtocol: features Plasmoids-wrapped-in-Tasks; is not currently fully functional
|
||||
|
||||
|
||||
The UI
|
||||
------
|
||||
The user interface consists of a Plasma::Applet class, a layout class and a TasksArea which
|
||||
contains the Tasks published. The UI features the ability to order as well as hide items,
|
||||
register new Tasks, etc.
|
||||
|
|
@ -43,7 +43,6 @@ Defined categories for wallpapers include:
|
|||
* Single Image
|
||||
* Slideshow
|
||||
* Animated
|
||||
* OpenGL
|
||||
* Interactive
|
||||
|
||||
Component API
|
||||
|
|
@ -95,5 +94,4 @@ Wallpaper plugin for the Containment.
|
|||
|
||||
Future Work
|
||||
-----------
|
||||
* Wallpapers should be ScriptEngine-able
|
||||
* Ability to define which wallpapers a Containment is compatible with?
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
Widgets
|
||||
=======
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Within libplasma there are a collection of widgets (Plasma::PushButton, Plasma::Slider, Plasma::TabWidget, Plasma::WebContent, etc.) which all follow a common API theme. The intention of this API is to provide a very simple way for users to create plasma applets. Plasma is not primarily a widget library, and so a simple wrapping of native Qt widgets is provided.
|
||||
|
||||
By providing a consistent, simple API that hides details like QGraphicsProxyWidget, the bar is lowered to entry and the time to create Applets is reduced.
|
||||
|
||||
The API can be used both for scripting and from C++. For the simple ECMAScript API for instance, this API will be all that is provided allowing untrusted applets to be run with a great measure of safety as they will not have access to any dangerous facilities.
|
||||
|
||||
From C++ or more advanced scripting APIs (such as the 'full' ECMAScript bindings) you can gain access to a pointer to the underlying Qt widget contained within the QGraphicsProxy via the nativeWidget() method, allowing access all of its methods. For most simple uses however, this should be unnecessary as you can do most of the customisation using the Qt stylesheet facilities.
|
||||
|
||||
All widgets have a stylesheet, which is a string property containing a Qt stylesheet. This allows for simple but powerful configuration of the widgets - for example you can configure the alignment of the text in the label using the text-align property, or the font using the font property. Using this you can do some extremely advanced interfaces without having to learn how Qt works.
|
||||
|
||||
A nice side effect of the way this API is defined is that it is possible to implement the simple widget API inside a web browser using HTML, javascript and HTML stylesheets to provide the implementation.
|
||||
|
||||
Standardized API
|
||||
----------------
|
||||
|
||||
Properties, setters and getters are defined for:
|
||||
|
||||
* parent widget
|
||||
* text
|
||||
* image (supports SVG as well as pixmap)
|
||||
* stylesheet
|
||||
* native widget
|
||||
|
||||
Widgets may add to this standardized API the most commonly used or important signals, slots and properties from the widget in question. Plasma::Checkbox, for instance, adds the toggled(bool) signal and properties for the checked state. These additions should be kept the essentials only to keep within the spirit of the simplicity and safety of the API; remember that the full widget is available via nativeWidget().
|
||||
|
||||
Look and Feel
|
||||
-------------
|
||||
|
||||
For most widgets, we let the QStyle do the painting.
|
||||
|
||||
For certain widgets (e.g. Plasma::PushButton), the painting is overridden to blend in better with a Plasma based interface. This can be done without reimplemeting the entire native Qt widget by reimplementing the paint methods in either the QGraphicsWidget or a subclass of the native Qt Widget. Another approach is to use a custom QStyle, which is how Plasma::Slider gets its look with minimal code.
|
||||
|
||||
Creating a New Widget
|
||||
---------------------
|
||||
|
||||
Included with the libplasma sources is a make_widget.sh script and a set of templates in the widgets/ directory. Running it with the name of the widget to create (e.g. make_widget.sh CoolWidget) will create a base implementation of a widget using the standard API. From there, only the widget specific signals, slots and properties need be added.
|
||||
|
||||
Loading…
Add table
Reference in a new issue