[GSoC]Integration of kde-telepathy into the Plasma Workspace
Francesco Nwokeka
francesco.nwokeka at gmail.com
Thu Mar 31 15:33:16 CEST 2011
On Tuesday 29 March 2011 17:39:46 George Goldberg wrote:
> On 29 March 2011 16:36, Francesco Nwokeka <francesco.nwokeka at gmail.com>
> wrote:
>
> <snip>
>
> > Document collaboration: an "invite" will be sent from one user to
> > another. A new component will have to be created and integrated into
> > kde-telepathy to allow users to work on the same document at the same
> > time
>
> Document collaboration is probably about 6 months work just to get the
> basics alone done. You are talking about it here as if it is something
> trivial that can be done in a few days.
>
> > Shared folders: the user will have the possibility to create a shared
> > folder per client. Dropbox style
>
> Is this supported at the Telepathy Connection Manager level? I don't
> believe it is, so you'd need to investigate that, and maybe implement
> it. Again, this is probably an entire summer of code project on it's
> own.
>
> > KDE-games: an "invite to game" action will be created for every kde-game
> > the user has installed on his/her computer ( as i think they all support
> > online gaming ) and an invite will be sent. If the recieving contact
> > doesn't have the requested game a response will be sent back telling the
> > user that che contact is missing the game
>
> Likewise - kdegames integration with telepathy would make an entire
> project in itself.
>
> >> >> With this feature the user will have his/her favorite contacts on the
> >> >>
> >> >> plasma-workspace not even a
> >> >
> >> > click away so instead of opening a contact list and searching for the
> >> >
> >> > contact, all the user has to do is click on the desktop plasmoid.
> >> >
> >> >
> >> >
> >> > There will also be the possibility to group these contact-plasmoids in
> >> >
> >> > custom groups defined by the user to satisfy his/her needs and with a
> >> >
> >> > grouping method which best suits him/her. All this in a lightweight
> >> >
> >> > plasmoid that will be designed not to be invasive and not to clutter
> >> > the
> >> >
> >> > workspace.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > To be able to satisfy the previously described features, the following
> >> >
> >> > need to be met ( also included in my project ) :
> >> >
> >> >
> >> >
> >> > * implement a collaboration feature for kde-telepathy
> >>
> >> What does this mean?
> >
> > Using Telepathy tubes I was thinking of creating a component in
> > kde-telepathy able to handle collaboration between two users for the same
> > document
>
> How? You need to give details, not just a wishlist of ideas.
> Otherwise, how do we know that you are up to the task?
>
> Please don't be discouraged by this. You just need to be a little more
> focused, and maybe pick just one of these tasks to work on. You also
> need to go into a lot more detail about *how* you intend to implement
> it.
Absolutley not discouraged at all. Here is more info about my ideas. The following will be
integrated into my previous proposal. You'll find that I haven't put down a timeline yet. I'm waiting
for your ok and to have the final proposal before setting that.
Here is another draft for my GSoC proposal as requested hoping to be able to explain myself better
and satify all curiosities.
I first came up with the QML integration idea around my first week in kde-telepathy as the guys were
thinking about something new to bring to the chat. As this is a new project, quite young and open to
new ideas I thought to myself, "why not?" and came up with the plasma integration ideas explained in
my previous mails [1].
So I intend to stick with this proposal for I see it as something that can change things for KDE and
the way to use instant messaging.
In this mail I will explain, as requested, how I intend to work on my project.
My project goals are the following:
* group all kde-telepathy functions into two simple QML plasmoids
* develop these two plasmoids to be easy to use, intuitive and non invasive
* make these highly customizable to fit majority of users needs
Following is an explanation on how I intend to develop my ideas.
The two plasmoids will be the "contactlsit" and the "contact" plasmoid.
There will be a third plasmoid used to create custom contact groups to keep the contact plasmoids of
the user's favorite contacts.
ContactList: this plasmoid will consist of two visualizations. The common "list" view and the unused
"gridview".
- List view
The list view will be highly configurable regarding visualization options. For example the user will
be able to modify visualization options for the contacts avatars, names, display order alfabetically
and via status. I also intend to let the user decide "how" he/she would like their contacts
information layout.
I'll explain better the last point.
To do this, the user will be presented with a window where in a dock ( left or right, doesn't matter
) there will be all the elements neccessary to build a contact delegate ( for delegate I intend a
template that defines each element in the view ). The user can then decide how to build his/her own
delegate for contact viewing as best suits him/her. This will be done by simply drag-n-drop actions.
The user will also be able to act on these elements once placed on the empty form for example by
setting the contact avatar position, size etc and so for all the other elements.
- Grid view
The gridview will have a default visualization based simply on the contact avatar and alias. I was
thinking of keeping the delegate for this view not customizable as I aim to keeping this view as
simple and with little "noise" as possible.
On hover over the contact avatar, the normal contact interaction actions will appear, sliding out
under the contact icon, for the user to click ( initiate chat, file trasnfer, call ).
The grid view will have the possibility to be ordered like the list view. That is by groups,
alfabetically, left-to-right ( viceversa ), contact size etc. I will implement an "unordered" or
"custom order" option in which it's the user that chooses how his/her contacts are organized. This
will be done by simply moving the contacts around the plasmoid area obtaining the desired layout and
order. To add some eye candy when doing this I might add some effects to the contacts when being
moved around like "wobble effect" or "shake effect". But this is the last thing to do.
Contact: this plasmoid will be made to rappresent a single contact. It will be interactable and the
normal contact ations ( initiate chat, file trasnfer, call ) will be available.
For this plasmoid it will be possible to customize it's information layout as with the
ContactList::Listview plasmoid thus giving the user full power over the plasmoid.
These plasmoids will be crated by an appropriate action from the contact list plasmoid or by drag-n-
drop from the contact list to the desktop.
The third plasmoid in mind is a simple "group" plasmoid.
It's main function is to group 1 or more contacts and keep them in one place. This plasmoid will
have a title that can be set by the user so he/she can recognize the contacts in the group is more
than one is present on the desktop. Even a customizable colored background will be settable if the
user wishes.
Regarding the "unclutter" part of my project, this is my idea to keep the desktop tidy.
One is the "group" plasmoid explained above.
The other idea is a function that can be attributed to all plasmoids. This function is the ability
to hide the plasmoids out of site from the desktop and make them callable via a simple plate on the
border of the screen. ( see attachment, i'm not good at mokups but I hope you get the idea )
As you can see, the only visible part will be the name of the groups made by the user. Once clicked
upon, this group will slide out showing its contents. When the label is clicked upon again, this
will slide back in out of sight and leaving the desktop tidy.
[1] http://mail.kde.org/pipermail/kde-telepathy/2011-March/001121.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-telepathy/attachments/20110331/cc3d611a/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unclutter-example.png
Type: image/png
Size: 11006 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-telepathy/attachments/20110331/cc3d611a/attachment-0001.png
More information about the KDE-Telepathy
mailing list