summaryrefslogtreecommitdiff
path: root/DeveloperNotes/Empathy_BOF_at_GCDS_2009.mdwn
blob: 3dfbf714d7e41caa7a59211d8f2e280d4257b4b6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

On Friday 10th July, at the Gran Canaria Desktop Summit 2009, a BOF was held to discuss the state of Telepathy and Empathy, and concerns, requirements and ideas for desktop integration. These notes were taken during the BOF. They're incomplete (it's hard to type as fast as people speak!) but should give some idea of what was discussed! 


## Cast of characters, not in order of appearance:

* Robert Mc``Queen 
* Bastien Nocera 
* Travis Reitter 
* Marco Barisione 
* George Goldberg 
* Davyd Madeley 
* Matthew Paul Thomas 
* Xavier Claessens 
* Olivier Crête 
* Guillaume Desmottes 
* John Carr 
* Alban Crequy 
* Arnaud Maillet 
* Will Thompson 
* Numerous other Collaborans and non-Collaborans, whose names and particular contributions your chronicler did not catch in the discussion (please do fill in gaps if you find them) 
* The Spirit of Rob Bradford, as represented by Messrs. Barisione and Reitter 

## Issues with using Empathy for IRC, or multi-user chats in general

* It's easy to accidentally quit MUCs by closing the window or hitting ^W. Also, some people want to be able to close MUC windows without leaving the MUC. 
* The icons in the tabs don't convey all the information they could (am i highlighted, or did someone just say something unrelated) 
* Various other papercuts 
* The consensus is that the small issues are easy to fix short-term: we can make Empathy keep MUCs in a separate window, with side tabs (top tabs don't scale well), and have confirmation for closing tabs when it means you'll leave a conversation permanently. 
* Longer term, we probably want a separate UI for IRC-like chat room usage. 
* Rob notes that we should avoid optimizing too much for developers who are in 17248 IRC channels 

## Speaking of current UI issues:

Matthew Paul Thomas spent quite some time during the day working with various Empathy developers on improving various aspects of the Empathy UI, focusing on the elements you see when you first start Empathy (including the accounts dialogue). When he's finished his designs, he'll relay them to the Empathy team; they can then be broken down into bug-sized chunks, discussed, and worked on. 


## Account Manager, Channel Dispatcher

Rob Mc``Queen gave an overview of the new API for managing accounts and dispatching communication channels to the appropriate interfaces, as implemented by Mission Control 5. Sjoerd has been working on porting Empathy to MC5; it'll be ready for testing soon. This will enable applications using Tubes not to depend on Empathy, and will make easier or feasible many of the desktop integration possibilities of Telepathy. (For instance, an application to auto-accept file transfers, or embedding a simple chat widget into Elisa to let you send quick replies to your friends while watching a film.) 

Bastien worries that the handling of multiple UIs for the same kind of channel will be confusing. 

* do we want to expose the choice between them in a UI, rather like Gnome's Preferred Applications dialogue 
* Rob explains that observers, approvers and handlers can (and should) collude to support desktop-specific preferences. For instance, if you're using the Gnome status applet, it can prefer to send channels to Empathy rather than Kopete. 

## Meta-contacts

Empathy doesn't currently have support for meta-contacts (that is, combining several contacts on different accounts which represent the same person). It should do so, whether with simplistic, Empathy-specific storage (like Pidgin does) or by using a desktop-wide address book (as is done on Maemo, for instance). 

Someone relayed Rob Bradford noting that once you merge contacts' vCards, you can't easily undo that. So if you accidentally merge Alice into Bob, you're screwed. 

* Travis and Marco said that we can store enough information in the address book (either EDS, or an RDF database) to make undo possible; this is a simple matter of programming. 
* Just store in each VCard who they are the same person as, and do the merging in the presentation level, asks Rob [[McQueen|McQueen]]? 
         * Marco says that this makes it painful for multiple applications to use the address book, since they all want to use the merged information 
         * Rob points out that you can have a library that does this for you 
         * George says that the point is not to have one library to do this, you should do this at the semantic desktop level 
         * Rob says that you have to at some point explicitly query the db, and then figure out what to do with it, and that's inevitably going to want some logic in the UI. 
Consensus is that in the short term, we really should just have a simple implementation in Empathy. 

Related to Rob Bradford's point, Will notes that if your contact list supports combining contacts with drag and drop, it's easy to mess up and lose contacts. Pidgin users often seem to do this: they drag a contact rather than clicking on them, and then can't figure out where they went. 

* Davyd suggests having a [[GtkInfoBar|GtkInfoBar]] saying what you just did with an undo button, rather like GMail. 
         * MPT says this sounds good 
* Travis suggests pulsing the target contact, rather like Banshee. 
Marco notes that Pidgin notices if you add a contact with the same ID as on another account, and offers to merge them for you; we should do this too. 


## Gnome Shell

* Want to be able to respond to messages and initiate conversations from the shell 
* Want to have some smartness to figure out how best to get the file to a contact: pick the right IM account, or fall back to email. This needs desktop-wide meta-contacts 
* How easy is it to use sophisticated D-Bus APIs from Javascript? 
         * “We've got D-Bus.” It should be fine. 
* Making a useful people panel is hard to do until we have a coherent metacontact system 
         * Have we looked at how the Palm Prē aggregates contacts from various sources? It would be nice to be able to do something similar 

## Zeitgeist

Perhaps we want to track when conversations occur in Zeitgeist? 

* Something needs to call D-Bus methods on Zeitgeist to say that a conversation's occurred. 
* Olivier thinks that every message should be in Zeitgeist. 
* Also Olivier thinks we need to cater for people who close the conversation window after every message, to avoid spamming their Zeitgeist log 
         * Rob thinks those people are neurotic. 
         * Sjoerd is one of those people. 
* We can have a heuristic in an observer that tells Zeitgeist what's going on. 

## libempathy-gtk

Guillaume raises the situation where every application is writing a contact picker to avoid depending on empathy-gtk 

* Xavier said that we shouldn't make standard widgets for this until we have a metacontact system, because this will influence what the chooser widget returns to the application 
* Sjoerd, Rob, others point out that at the end of the day, you only want to know a contact capable of doing foo. 
* We should move the contact selector to libtelepathy-gtk already, and not ship libempathy{,-gtk} 
* Xavier notes that if we have libtelepathy-gtk in C, and want to use it in Python, then we'd have to bind tp-glib in Python as well. 
         * One possible escape route is to provide just enough glue to use tp-python objects with libtp-gtk. 

## Launching collaborative applications

Arnaud has implemented sharing your desktop with a contact via a stream tube in Vino and Vinagre. The stalling point is where the UI for sharing your desktop should be, since there's no obvious place. This is a general issue. 

* Currently, we have a separate launcher application, Share My Desktop. 
         * Should Vino ship this? 
         * Should Empathy ship this? 
* Should Empathy have a right-click menu for every tube application? no, that doesn't scale 
* Maybe reverse tubes help this, because they let us put the UI for this into the VNC client UI 
         * Sjoerd notes that this only solves the VNC case 
* Rob doesn't want to have a registry of tube applications that Empathy would read and show a big list 
         * Guillaume wondered about looking at the running clients, and if there are less than 5 then show a menu? 
* Olivier wondered about "Share an application…" menu, and a big registry of stuff 
* In most cases, having the UI in the application you're sharing makes sense: 
         * in Banshee, a list of people in the sidebar 
         * in an editor, you're already in the document 
         * VNC-like cases are a special case 
                     * it can save the people who you're happy to share applications with 
* Xavier notes that this'll be easier to discuss when there are more applications using Tubes. 
* Short term, we can ship share-my-desktop in Empathy. 
* Rob asks John Carr: do you have any cunning plans for how to solve this in the glorious gnome-shell future? As we telepathise things, you need to choose the application and the person. made a person-chooser widget, apps can use it. play chess with -> john; entire ui lives inside the game. that doesn't give you the ability to launch chess from empathy, but having a big menu of games would be crap and hard. how do we make this good? 
         * mpt wonders how this will work in multi-player games; since the game needs to know these kinds of things, this would make sense to be in the game. 
         * john wants to be able to get the invitation inside the chat window. but you're still going to need ui in the applications, so... 
         * Ray Strode: initiating a conversation is different to starting a game. you're more likely to find a person and talk to them, and more likely to be editing a document/playing a game and then think about who to edit/play it with. 
Do we need some kind of application presence, so that you can differentiate between "my contacts can play tetrinet" and "my contacts are playin gtetrinet"? 

* at the moment we only signal the former, not the latter, or willingness to play 
         * just making a menu based on applications they *have* is a bad idea 
         * but just showing whether they *want* to play, or are already playing, is a good idea. we'd need to implement this. 

## Tracker and Gnome 2.28

Your chronicler didn't catch what was discussed (briefly) here; if you remember, fill in the gap!