Log of UDS Maverick sessions
This is a concatenation of the gobby documents for each session held during the UDS for Maverick in Belgium. Some notes are missing, due to a gobby incident during the first part of the week.
Contents
-
Log of UDS Maverick sessions
- DX Roundtable
- dx-m-indicator-network
- 2nd session on connman
- dx-m-indicator-me
- dx-m-indicator-sound-v2
- dx-m-multi-touch-overview
- dx-m-indicator-keyboard
- dx-m-app-menubar
- dx-m-app-indicators
- dx-m-multi-touch-and-kernel
- dx-m-indicator-messages
- dx-m-clock-indicator
- dx-m-qa-workflow
- dx-m-indicator-power
- DX / Desktop Roundtable
DX Roundtable
Plan for this week * indicator sessions
- - network
- Tuesday handle network menu
- Discussion about conman and how it can be used in UNE
Perhaps we need to have a seperate session just for ConMan?
- Three parts to effort:
- Menu - the ability to reflect the system status on panel, requires help from Cody
- Preferences - needs lots of development in this area for a clean streamlined interface
- Integration Between Parts - Ensure the user experience is "proper and consistent"
- New design for battery menu already exists
- Requires significant engineering investment to make mockups a reality
- Determine if GNOME Power Manager is going to stay with us in the distant future
- Ability to move application menu bars directly on the panel to save space
- Specific to UNE
- Ideally will quickly develop a toolkit for upstream adoption, similar
- to indicators last cycle
- Prototype has been prepared and may be demo'd later this week (Wed @ 5PM in Flamboyant)
- Discuss integration across toolkits (patching? modules? )
- Possible side benefit for Mac OS GTK team
- Properly handle multiple menu bar applications
- Other testing issues
- Integration works across both KDE and GNOME panels
- No session on transition
- Slow transition away from dated systray technology
Qt Comment: The new protocol is needed in Qt and they seem to want it
- : Needs to be inside of toolkit, small technical issue
- Will be a session on keyboard menu
- Domain expert required to help ensure design works for all different languages
- especially languages we do not speak or commonly use
- Input methods need to be looked at
- Ensure iBus and xkb work together, or if not do what it takes to have a consistent state
- Three parts
- Timezone preferences
- Calendar widget
- ???
- Please join the session if you are interested in improving this part of Ubuntu
- Session dx-m-indicator-clock is on Friday from 11:00 to 11:55
- No session available on this, may be more useful to track Cody down directly
- Work primarily performed by Cody Russell durring Lucid cycle
- Attempt to land work early on in Maverick cycle
- Review issues from Lucid and for some tracking and fixing
- Has both a design and engineering session on window indicators
- Technology building blocks are present however concept is still at design stage
- Tomorrow afternoon 4:15PM lead by Conor!
- Two main points
- Integration with applications
- mpris standard evaluation, especially with major players (rhythmbox and banshee)
- Session this afternoon 3PM after lunch
- Some form of indication for the broadcast menu
- Work to help provide better user feedback
- No more string freeze == yay
- Look at overlaps between messaging menu and the me menu as they work closely together
- Design team will need to digest feedback from lucid on this problem
- Integration with Gwibber
- Gwibber has gone through rapid development in last cycle
- Need to ensure we have better feedback mechanism with gwibber
- Ensure we communicate the status of the message to the user (avoid double tweets)
- First category indicator, started with Intrepid Ibex
- May not be impacted too much for Maverick
- Some minor issues that need to be worked out
- Preferred applications needs to be implemented
- Ensure messaging menu elemented can be re-used
- General feedback seems to be posit ive. Community has been very supportive.
- Suffered from time constraints during Lucid.
- Label case needs to be covered, KDE discussion needed
- Scroll wheel support
- Integrating KDE with GTK icons
- Custom icons are not on the list of things to do
- Definately going to use GTK symbolic icons
- Stance on tooltips or their replacement needs to be clarified
* Unity
- - design sessions (discussion on how to manage files etc...) - eng. session (scheduled later this week)
* Multi touch
- - MT overview - MT kernel support - Ensure first class citizen in unity - Kernel support for multi touch, particularly with regard to extending support
- for other devices
dx-m-indicator-network
https://wiki.ubuntu.com/NetworkSettings
1. Scope of work for Maverick
- - UNE - Indicator menu - Preferences, network settings
- ConMan backend & intermediate service (fd
Status; Timeframe; Who's involved
2. Walkthrough the new menu
Questions from awe:
- - how will you get the on/off toggles?
- yes, we cody will do the magic (ido)
- yes, we can update the menu in real-time
3. Main use-cases
- [system] Display the connection status on the panel indicator
- Connect or switch to another network
- Browse the list of available networks
- Connect to an Ethernet network
- Connect to a Wi-Fi network
- Connect to a 3G network
- Configuring network settings
- Editing a network connection
- Mobile setup
- VPN setup
- Creating a network connection
- Configuring other network settings
- [system] Help the user with troubleshooting network issues
- [system] Warn the user that there is a link issue
Suggestion from repete:
- Consult network connection information (do to troubleshooting, ie when calling user support saying "the Internet is broken")
- - what's required: IP, 3G, kill_switch info (warning, maybe tricky)
-> mpt is taking further notes in his specification
4. Issues
- We should have a single “Flight Mode” ("airplane mode") that turns of wireless, Bluetooth, and 3G.
- detect/guess when people have hit the hardware kill switch
- the "Connect to Wireless Network" dialog could use a list instead of a combo box
- use cases for explicit "Disconnect":
- - all the wireless is bad and you want to switch to 3G/wired - DHCP problem (could also be satisfied by reselecting the selected network)
- disabling wireless doesn't power it off
Whether/when should we reconnect to a network that you have explicitly disconnected from? - suggestion (principle of least surprise): if the user said disconnect, do not reconnect automatically
- How do we show previously-connected hidden networks?
- what exactly does NetworkManager do?
- - Tony Espy: doesn't explicitly scan for previously-used hidden networks - Rick Spencer shows/auto-connects to previously-used hidden networks
- You connect a 3G dongle: what happens?
- - should popup something offering to connect, currently you have to manually go to the network applet
- You have internal 3G but no SIM: what happens?
gnome-bluetooth talks to NetworkManager
- show 3G signal strength when not connected?
- - this may require powering it
- how to handle credentials
- - hammer gnome-keyring into usable submission?
- - Rick Spencer: this is a potential target for Maverick - Unsafe storage should be an explicit option rather than done by entering a blank password
- - hammer gnome-keyring into usable submission?
Handle the upgrade process from NetworkManager to ConnectionManager
- - networks and passwords
- when connecting, the icon should make it obvious that the network is /not/ connected (ie have an animation that is distinguishably different from the icon set used when the network is connected)
- - Keep the password dialog open until it's successful, and make that dialog say connecting
- - in the case of previously connected networks, we may need to do something else (maybe a notification only in this case)
- - Keep the password dialog open until it's successful, and make that dialog say connecting
4. Action items
- Update spec:
- - Other networks dialog should have a list instead of dropdown view - Prefer unlocked networks on top 5 list
- design 3G mobile setup (either builtin or when plugged in)
- review the security requirements for storing the passwords and ensure that the exchange between the system level to the UI is made in a secure way
- suggestion: we don't need to protect WPA enterprise passwords with the same level of security as the low-grade WEP passwords; the user may not even care; different security levels make the case for different grades of keyrings
- Modify the keyring dialog to make it more obvious what to do (and perhaps more obvious to use unsafe storage rather than entering no password)
- - this is in gnome-keyring scope rather than here
- add the on/off toggle item in ido
- add a new menu grid layout to support icons both on the left and the right
2nd session on connman
(thanks Mikkel for the backup!)
ConnMan for Ubuntu UNE 10.10
Agenda for the session
- Intro.
- Description of the proposed system
- Discussion of the Maverick scope
- Discussion of the backup plan
- Review of the action items
Introduction
- follows the session held on the redesign of the network menu itself
- this session focuses on conman and the different backends that we want to use in Maverick
- reminder: we're targetting UNE only, the desktop is out of scope
Scope for Maverick
Maverick scope
- Wifi - in particular ensure that the broadcom chipsets are well supported (popular in all the newest OEM designs)
- 3g modem support (important for OEMs)
-> need a list of target chipsets / devices (manufacturer, dev. id, etc.)
- awe suggests to look at the NM bug list
- separate manual ip and dhcp services for wired
- connection status support
- PPA containing dev. packages + test scripts
DX Scope
--------------------- --------------------- | network indicator | | | |-------------------| | perfs/settings UI | | network menu | | | --------------------- ---------------------
"layer-cake" (warning: crude ascii-art)
---------------- ---------------- -------------
| | | Connection- | | |
| wpa-supplic. | --> | Manager | -> | ofono |
---------------- |--------------| / | |
| ofono plugin | - | |
---------------- -------------
out of scope for Maverick
- vpn: vpnc, openvpn, pptp, (strongswan?)
- eap: ttls, leap (?)
- ipv6
Test plan
HW testing
- OEM/QA have HW
- - need to share the list of devices available
- PPA containing dev. packages + test scripts
- maybe build specific USB images to facilitate "crowd testing"
Scripts / programs to facilitate testing
- checkbox? other?
- apport support? other?
Integration work items
Backup plan
- NM is still present on the desktop session
- Solutions in case CM doesn't work on UNE
- switch to the desktop session
- use nm-applet with an app. indicator patch
- worse case scenario: re-enable the systray on UNE
DX delivery scope
(and content of the PPA)
- connman
- ofono
- wpa_supplicant
On ensuring that NM continues working (and potentialy fixing integration issues), OEM/tony will help.
Action items
* [platform] - ensure CM & NM can be installed at the same time; ensure they cannot run at the same time - A2 * Pete will check which VPNs are often requested * [DX] Create a lucid PPA containing dev. packages * [DX] publish that PPA in the blueprint thus any subscribers get informed * [DX] add test scripts later in the cycle * [DX] raise the QA team attention about NM, ie raise the priority of integration bugs * [desktop/chrisccoulson] getting wpa 0.7 by A2 * [desktop] make MIR request for ofono * [DX/desktop] migration of crendentials? * Check that the NetworkManager emulation done by ConnMan keeps apps happy * Kalle: prioritized work list shared with connman maililng list * Assess wpasupplicant 0.7's impact on NetworkManager * seb128 wants someone to maintain the NetworkManager stack (packaging + code)
- Chris and Kalle will be on this. Matthew also has in depth knowledge here
sameo's prioritized work list
- ipv6
- NTP
- on demand connection
- libsupplicant
Sameo also notes that Meego recommends and ships wpasupplicant 0.7
Material for the discussion
missing features (before session):
- pppoeals (gnome keyring?)
- wi-fi ad-hoc
- bt dun
- connection sharing
- a wifi connection based on BSSID
needed for testing (before session):
- connman and ofono nightly builds
- wpa_supplicant 0.7.x
- preferably also wpa_supplicant night builds
- project for the indicator-network
- web pages/wiki, instructions
- ubuntu specific mailing list for discussions/feedback
- bug handling
dx-m-indicator-me
Agenda for the session
- user feedback from Lucid
- bug reports
- potential v2 spec. elements
- actions items
User feedback
First, the feedback was positive! 
* account dialog, was unclear when the first thing it displayed was flickr, whereas Twitter immediately rang a bell(someone correct my poor english?) https://wiki.ubuntu.com/MeMenu#Use cases * People didn't necessarily understand what Ubuntu One was for in the me menu
- - What is it for anyway?
* need a char. counter * need a better feedback mechanism: having a notification saying "message sent"
- add parameter for Send method in gwibber for "notify" as True or False
* don't understand what the broadcast field is about * confused by menu entries ("broadcast" accounts)
Bugs: see https://bugs.launchpad.net/indicator-me/+bugs
2. Phase 1 - fixing the bugs
This will include: - ui improvements
- Hint text on the broadcast field ("Broadcast a message..." or similar
- - disappears on click - helps answer question "what does this field do" and "what is a broadcast account"
Remove Ubuntu One from Me menu (have it live elsewhere, like System->Preferences)
- Color the broadcast account boxes in the case of multiples of the same type (use the Gwibber colors)
- - This way you can tweet to yellow twitter and red twitter and both
- gwibber changes
- add method to gwibber to return message count
- consider a method where gwibber returns an error code
- investigate displaying of me-menu broadcast field and how we decide to display it
- the "about-me" question
- gnome upstream is changing the about-me capplet
- replaced by Fedora user accounts dialog
- the me menu should call that new module
- ...while we consider an even better u.a. dialog in U1
Consider allowing users to set alternate apps for me menu integration, perhaps set in System>Preferences>Preferred Applications (needs someone that cares to submit a merge request)
Bug discussion:
- "sent from gwibber" (#524358) - ryan happy to get a patch for that
- - sabdfl pet bug - need to list, per-network, ways of fixing the issue
users don't see what the U1 entry is about -> should remove it
3. Phase 2 - me menu v2 research - further user research - potential items
4. Work Items
*
Scheduling, we'll see that on Friday
For A2 (phase 1)
For A3
For A4 - 11.04
dx-m-indicator-sound-v2
1. New Sound Menu V2 design
Walkthrough
The sound menu becomes a category indicator.
- can control the sound system from a single menu
- can remote control music players
Mark comments that the driver behind turning the sound menu into a category indicator was to be able to control m.p. working in the background, ie without a visible UI.
Question on totem integration:
- not planned for Maverick
- possible, as this is an open API
- however, there is not really a case for putting a full *video* player (with a visible UI, as opposed to a bg service)
The main new feature for the v2 design, is to let music players to be able to register in the sound menu
Comment on the current version of the spec:
- we shouldn't special case the visibility of the input volume slider to just VOIP applications; that control should be visible each time we can detect that an application is using the input device
2. How to implement?
Registration process
- Ayatana API for registering music player at runtime
- extending MPRIS
- - mostly the playlist API
Artwork export (discussion between Conor & the RB author) - can someone record the discussion outcome?
- it's more or less possible, probably not very nice. willing to implement something better in RB.
MPRIS support
- RB: very limited resources to commit to that, but will try to do their best
- Banshee: positive feedback (can someone expand?)
3. Misc would there be any change of icon to the sound icon itself to signify that it has control over the player? It seems like that rhythmbox..etc would be added to the sound menu but the user wouldnt know it was put there. - not in scope for Maverick (but id expect a bug report about that)
Comment from the audience (gense): many people use YouTube as their main source of music * we're not targetting webapp integration with this API * however totem has a good YouTube plugin that supports that source, for the "YouTube generation"
Question: how to deal with HW keys (play, pause, etc.)? * just like it does at the moment * note: check if that's the case, in particular when there are multiple players running, or whether it's something that is not supported across the board
- (the idea being that it should be consistent: if an app. player is supported in the menu, then the HW keys should work with it)
Banshee collects a lot of data from users (500.000 users) about resolution and so on: could be used to adjust the interface.
Action Items
* mark: will update the spec to reflect the discussion on the volume management feature (ie, when switching between different apps) * distro-patch for fixing the sink switch bug (#??? conor: can you add a bug reference for this action?) * other scheduling aspects (service registration API, indicator widget) will be considered on Friday during the roundtable with Desktop
dx-m-multi-touch-overview
Re-phrasing the goal for Maverick: - HW/low-level enablement in Lucid: meant for people who wanted to start developing on MT - Toolkit enablement and dev. environment (libs, etc.) for application developers; with a few key MT applications used to "test" the stack - in order to get many more MT apps in M+1
HW support
* N-trig * Wacom * Stantum * Synaptic
https://edge.launchpad.net/~chasedouglas/+archive/multitouch
schematic of involved modules (layer-cake)
(top to bottom)
PyMT/browser/Unity/...
^
| (apps/libs)
----------------------------------------------
|
GTK (gesture?)
^
|
window-manager
/ \
/ \
X11 touchd mt-evdev (gesture?)
^ ^ /
| | /
| | / (userland)
-------------------------/--------------------
| | / (kernel)
| | /
/dev/input/events*
^
|
kernel
=== module status ===
- kernel-events | - devinfos | - management of device
| | - firmware
| |
Ok! | Ok! | Missing! === ===
Kernel level
driver locking issues
Features for Maverick
Selecting key apps that could take advantage of MT * unity * inkscape * evince * chrome
Language selection * rafy's python library * pymt
Toolkit integration, more complex (in particular the patchsets and dev. versions mentioned yesterday)
- Multitouch should be available at a lower level (like XInput2) so more than one application at a time could query MT-events
Touch daemon * should connect to evdev * export events
Action items Design & implement
- need to verify (find his document on mailing-list) with MPX-author Peter Hutterer about roadmap about how to get perfect support for MT into XInput2
- design API for dev. mgmt:
- uploading the firmware (reqs. from platform)
- calibration API: research patterns by considering (very) different devices and tools used to calibrate them
- select/design a touch "daemon", mt-evdev, touchd, multitouchd
- gesture decoding library (may be independant of the daemon above)
Integration
- drivers
- clutter + touch
- [desktop] GTK, QT (to be discussed depending on the apps reqs below)
- [community] contact evince
- [community] contact inkscape
- [desktop] integration pymt
- [desktop] integrate other libs
dx-m-indicator-keyboard
Missing gobby document: if you have a copy of that document, please mail me.
dx-m-app-menubar
Missing gobby document: if you have a copy of that document, please mail me.
dx-m-app-indicators
1. Review of the lucid effort
jorge: for Maverick, we really need to finish this effort, have all applications supported.
List of work items for fixing / extending app. indicator: - fix the gtk menu updates (signal) issue (fixes gnome-bt); has a gtk patch waiting for review - fix issue related to the virt-mgr patch (see https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/525462)
List of work items to port applications: - hplip support, there is a patch: the change is not working correctly and need to be reviewed again - rhythmbox: the current change has issues but is going to be deprecated by the new sound indicator - banshee: the indicator is in an optional binary, need to be installed and then activated in the preferences dialog, situation is buggy and in such cases it would be better to delay the change than to ship something buggy - vino: patch needs to be reviewed and updated - liferea: there is a patch (see http://www.omgubuntu.co.uk/2010/05/add-lifrea-feed-reader-to-messaging.html) - gnome-power-manager: update the patch to shorten the label - apport: need to be ported
Superseded - conman - ibus
Community aspects https://blueprints.edge.launchpad.net/ubuntu/+spec/dx-m-app-indicator - freedesktop discussions; stalled - gnome adoption
- bugs review
2. For Maverick - new features
- missing apps to target (see actions above)
dx-m-multi-touch-and-kernel
Re-phrasing the goal for Maverick: - HW/low-level enablement in Lucid: meant for people who wanted to start developing on MT - Toolkit enablement and dev. environment (libs, etc.) for application developers; with a few key MT applications used to "test" the stack - in order to get many more MT apps in M+1
HW support
* N-trig * Wacom * Stantum * Synaptic
https://edge.launchpad.net/~chasedouglas/+archive/multitouch
schematic of involved modules (layer-cake)
- (top to bottom)
- PyMT/browser/Unity/...
- ^ | (apps/libs)
- PyMT/browser/Unity/...
- |
- GTK (gesture?)
- ^ |
- window-manager / \
- / \
- X11 touchd mt-evdev (gesture?)
/ | | / | | / (userland)
/
- | | / (kernel) | | /
- /dev/input/events*
- ^ |
- kernel
- /dev/input/events*
module status
- - kernel-events | - devinfos | - management of device
- | | - firmware | |
- Ok! | Ok! | Missing!
=== ===
Kernel level
driver locking issues
Features for Maverick
Selecting key apps that could take advantage of MT * unity * inkscape * evince * chrome
Language selection * rafy's python library * pymt
Toolkit integration, more complex (in particular the patchsets and dev. versions mentioned yesterday)
- Multitouch should be available at a lower level (like XInput2) so more than one application at a time could query MT-events
Touch daemon * should connect to evdev * export events
Action items Design & implement
- need to verify (find his document on mailing-list) with MPX-author Peter Hutterer about roadmap about how to get perfect support for MT into XInput2
- design API for dev. mgmt:
- uploading the firmware (reqs. from platform)
- calibration API: research patterns by considering (very) different devices and tools used to calibrate them
- select/design a touch "daemon", mt-evdev, touchd, multitouchd
- gesture decoding library (may be independant of the daemon above)
Integration
- drivers
- clutter + touch
- [desktop] GTK, QT (to be discussed depending on the apps reqs below)
- [community] contact evince
- [community] contact inkscape
- [desktop] integration pymt
- [desktop] integrate other libs
dx-m-indicator-messages
Agenda
Work items for Maverick
- libindicate-gtk: need to use an array of bytes
- make sure the menu disappear (ie remove the icon) when there are no applications using it
- migration to just using the keyfile as opposed to the old method of have links to the desktop files
- preferred applications: re-use the "protocol:app" registry of preferred apps and add one for "chat:..." and "social:gwibber"
- (temporarily) light the running application indicator (triangle) for applications which have triggered the indicator (green envelope)
Integration tasks for Maverick
- [proposed] extension to the telepathy approver to trigger the indicator based on real-time XMPP push messages (gtalk supports that apparently)
- distro patch mozilla's notifications and use n-osd instead
Community outreach:
- liferea
- akregator
- mail notification (webmails support)
- thunderbird
dx-m-clock-indicator
Design
https://wiki.ubuntu.com/TimeAndDate
TODOs
- Encourage volunteers to create a weather menu and/or weather widgets/gadget [jcastro]
- Ensure that design is making a visual design for timezone picker [mpt]
- Work with evand and design to make an ido timezone picker [bratsche]
- Investigate how launch the add events dialog in Evolution [ted]
Look at using installer method for setting the time zone based on the current location (http://geoip.ubuntu.com/lookup, XML document)
- Update spec to cover lazy loading of events from evolution-data-server [mpt]
- Include upgrade plan: adding indicator-time removes gnome-clock-applet [mpt]
- Discuss with desktop team whether it should be default in desktop edition [didrocks]
- Specify exact ellipsis behavior for events vs. times [mpt]
How can we share the timezone map with the installer? - http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/annotate/head:/ubiquity/timezone_map.py - http://people.canonical.com/~evand/screenshots/ubiquity/10.04-RC/2-ubiquity-10.04-RC-timezone.png - maybe an IDO widget with bindings for Python (ubiquity) and C (indicator-time)
We won't schedule time for "Set Alarm..." for Maverick, but if anyone wants to implement it that would be fabulous
converting Evolution's notification-area advertisement of upcoming events will be covered in NotificationAreaTransition
What time is it where didrocks is? - maybe this belongs in Empathy instead
dx-m-qa-workflow
Agenda for the session
Goals:
- increase the quality of DX deliveries and integration into the desktop
Main differences with the other teams, like Desktop
- It impacts in a lot of packages
- Changes are very visible
- Delivered first on Ubuntu; Ubuntu gets "all the problems first", sort of
- Frequent releases during the development cycle
- Closer to upstream bugs mgmt
- Usability bugs usually filed against our packages, even if not technical bugs
* Short retrospective
* Rhythms * Processes * Tools * Misc.
* For SRUs (like 10.04.1)
- fixing bugs on Friday
- means need help triaging issues before Friday, in particular reviewing priority bugs to fix
Test Plans
* use of the "use-case mapper" tool *
* a good test plan is not all, need to actually drive the test process
- communicate about the test plans
- organize bug /days/ (for triaging, every thursday)
- organize testing /weeks/
- organize app-specific, dedicated time, for finding new bugs (mentions the example of the desktop team using that, at the end of the cycle)
- other?
Connman
* need special help during Maverick - critical change
* IMPORTANT: need to preserve a working NM configuration, even if other packages are changed as part of the Connman move
- document the rollback plan for testers (as well as for users)
* re-use the process that worked well for bryce or pitti * 2nd phase: use the HW database or the certification database
* HW testing
* SW testing
Actions items: * [dbarth] define milestones for Lucid updates * [qa, desktop, dx qa] use the milestones for Friday's bugs * [dbarth] try to attend the weekly QA meeting https://wiki.ubuntu.com/QATeam/Meetings * [kalle] list set of configurations to test * [kalle] script to test a feature * [kalle] test plan: step by step, expected results, packages (ppa, as a form of "test data")
Work items:
dx-m-indicator-power
https://wiki.ubuntu.com/BatteryStatusMenu
Agenda
- Introduction: tentative item for Maverick
- Review the design
- Consider how to implement the indicator for
- minimizing changes
- investing in the right components, creating new ones
- ensure the implementation is ARM-friendly; works well on the ARM platform, where power management is a key feature
Review of the design
Design change suggestions:
- Consider whether it makes more sense to show internal battery all the time, instead of (for example) mouse battery when it's nearly flat
- (A) Internal battery priority is very high
- (B) Laptops often have touchpads as a backup for mouse if it runs out
- Maybe include items to turn off things that consume power
- - e.g. wi-fi -- partially overlaps with network menu - e.g. brightness
Question: is that a category indicator; Answer: no, this is not, ie there is just one sub-system contributing items in this menu (upower)
Future:
- integrate powertop into the power settings window
- some sort of warning if a process is chewing CPU
Brainstorm about the best options to implement the indicator
2 options considered
1. separate indicator service, based on upower
- moving some code into upower to ensure the indicator and gpm are on the same page
- advantage: clean architecture where policy mgmt is kept in gpm, status infos are direclty linked with upower's view of the system status
- can also benefit KDE
- simplifies maintenance
- issue: a lot of code changes, sounds a bit like "re-inventing the wheel"
2. "fix" gpm
- does not sound like the time vs percentage changes justify re-writing a dedicated indicator service
- everyone (gnome) benefits
- issue: upstream willigness to accept the changes?
Discussion with the gpm maintainer
- there is already a time based option, set by default upstream
=> we could use that to implement the battery menu
- on app. indicators, he'd prefer to see the technology accepted by gnome before carrying build options for it
=> we'll keep on distro patching for maverick
Plaform updates
* investigate how upower / gpm compute the time left * ensure upower is able to give correct prediction for time left
Action Items * [DX] talk to richard (hughsie) * suggest the cpu warning feature for gpm * [DX] consider * A2 [DX] Change the menuitem string * A3 [DX] implement gpm preferences changes * A3-A4 [DX] Add extra menuitems to the menu
DX / Desktop Roundtable
Agenda for the session
- review of the dx blueprints
- key actions items
- priorities
Review of the blueprints
- dx-m-app-indicator
- 2 new features
- bug fixes
- no special action from the ubuntu desktop team out of taking updates
- dx-m-indicator-menubar
- [A1] SDK (Lucid PPA) (gtk patchset + loadable module) + indicator
- [A2] removing the menubar in the window
- kubuntu is probably going to align on that plan
- dx-m-indicator-clock [A3]
- change in ido
if feature parity -> considering for desktop
- dx-indicator-sound
- [A2-3..] new versions of Rhythmbox, Amarok and Banshee including Ayatana registration
- and MPRIS support.
- [A2] new indicator-sound (hopefully land a version 1, current version 0.2.3)
- [A2-3..] new versions of Rhythmbox, Amarok and Banshee including Ayatana registration
- dx-m-indicator-keyboard
- no plumbing changes for this cycle
- [A3] implement only the fallback solution (because
- dx-m-indicator-me
- [A1, A2] bug fixes
- [A1] port to libgwibber
- [A3] multi-network selector implementation
- no about-me changes
- dx-m-indicator-messages
- [A2] (design driven) theme change (running app. indicator)
- [A3] minor changes (see blueprint/gobby session)
- dx-m-indicator-network
- [A1] PPA with prototype modules, available for lucid
- [A1] desktop to land wpa_supplicant 0.7 to maverick + other components changes
- [A2] desktop to get connman in main with its depends and do packaging changes to allow having n-m and connman installed
- [A3] dx-m-indicator-power
- string changes
- prefs improvements
- that's all
- dx-m-indicator-session
- will be tracked at the bugfix level (red icon, lock screen)
- dx-m-multi-touch
- cross team effort
- duncan is probably going to manage the whole project
- dx-m-unity-une-integration
- weekly releases of unity
- zeitgeist integration
- software-center integration?
- GTK changes
- [A1] csd
- [A1] rgba
- [A2] menu proxy
- [?] symbolic icons