From Fedora Project Wiki
Line 83: Line 83:
|-
|-
|Installation options dialog || Sep 29 || mgracik || || [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Previews/9-1_install-destination/9-1-5_screen-destination-free.png #9-1-5] || A simple light box dialog that pops up after Continue is clicked on the Install Destination spoke.  Your solution should be a class that returns information about which button was clicked, along with whether to do custom partitioning.
|Installation options dialog || Sep 29 || mgracik || || [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Previews/9-1_install-destination/9-1-5_screen-destination-free.png #9-1-5] || A simple light box dialog that pops up after Continue is clicked on the Install Destination spoke.  Your solution should be a class that returns information about which button was clicked, along with whether to do custom partitioning.
|-
|Create new partition dialog || Sep 29 || dlehman || || [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Previews/9-3_partitioning/9-3-1-3_disks-phys-add.png #9-3-1-3] || A light box dialog that allows the user to specify a new partition.  Your solution should be a class that returns what the user specified.  I have not thought too much about this one, but perhaps it is best to return a set of Requests.  I don't much like the idea of the class itself modifying the Storage object.  The class should take in a maximum and minimum size for the new partitions in order to come up with boundaries for capacity, and should be able to filter out existing mount points from the drop down.
|-
|-
|Configure network spoke || Jan 10 || rvykydal || || [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network.png #1-3] [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network-wireless.png #1-3-1] [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network-wep.png #1-3-2] [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network-ipv6.png #1-3-3]|| I think we need to divert from mockups so that we can (re)use nm-c-e for network ''configuration'' (nm-c-e for selected device is invoked by Configure button) while our own spoke UI code will be used just for network ''control'' - list of devices/access points, turning on/off, access point selection, status information - which is what gnome-control-center does in desktop.  The initial UI is taken from g-c-c glade file, just some functionality and UI we don't need/support in installer is hidden and e.g. device description details are added.  We need also nm-applet as Secrets Agent for wireless authentication. Network configuration is applied (as in desktop) only after configured device is restarted (using on/off switch). Video: http://rvykydal.fedorapeople.org/network_spoke.webm (note that it is taken using test harness in desktop, so in presence of nm-applet service).
|Configure network spoke || Jan 10 || rvykydal || || [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network.png #1-3] [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network-wireless.png #1-3-1] [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network-wep.png #1-3-2] [http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01-network-ipv6.png #1-3-3]|| I think we need to divert from mockups so that we can (re)use nm-c-e for network ''configuration'' (nm-c-e for selected device is invoked by Configure button) while our own spoke UI code will be used just for network ''control'' - list of devices/access points, turning on/off, access point selection, status information - which is what gnome-control-center does in desktop.  The initial UI is taken from g-c-c glade file, just some functionality and UI we don't need/support in installer is hidden and e.g. device description details are added.  We need also nm-applet as Secrets Agent for wireless authentication. Network configuration is applied (as in desktop) only after configured device is restarted (using on/off switch). Video: http://rvykydal.fedorapeople.org/network_spoke.webm (note that it is taken using test harness in desktop, so in presence of nm-applet service).

Revision as of 20:57, 17 January 2012

Anaconda UI Work List

Bored? Tired of bugs? Looking for something new to do? Why not check out something from this list of work items for the new user interface! The list below is what can currently be worked on, given the state of the base classes and custom widgets. If you want to claim one of these items, simply put your name in the right column. Discuss your code on anaconda-devel-list and when you are happy with it, link to it here (eventually, you will instead commit to anaconda but we're not there yet). If you have any questions, ask clumens.

More items will be posted periodically, so be sure to check back.

Guidelines

First, here are a couple guidelines for all items.

  • Everything here should be done in Python. The one exception might be if you are doing something very low level graphically and there are not satisfactory Python bindings. Then, C might be appropriate.
  • You will need a lot of very current software installed to work on this. At the least, you'll want gtk3, gobject-introspection, glade3 and glade3-libgladeui, pygobject3, and all their devel subpackages. You'll also want to make sure you have the latest glib. It might be best to be running rawhide or at least F16 with this stuff updated. RHEL6 probably isn't going to cut it.
  • Use glade for as much as possible. glade allows doing all the TreeView and ListStore stuff now. Use glade for dialogs. Use signals where appropriate.
  • Consider keyboard use - put mnemonics on things.
  • Don't hard code stylistic elements (absolute font sizes or names, rounded corners, and the like). We want to use the shipping GTK style to decide all that for us. Of course, you can specify things to be bold or red as needed.
  • Include test cases.
  • Do not look at existing anaconda UI code for how to do things. I'm planning on getting rid of it all anyway, and I don't want people dragging bad ideas from the past along.
  • Don't worry too much about integrating your code with anaconda as it stands today. Make your solution something that can be tested standalone and pulled into non-anaconda applications. We'll worry about the integration later.

Conventions

Use the following standard values when designing in Glade:

  • spacing: 6
  • border width: 6

Use the following keyboard mnemonics and add the dialog number in parenthesis so we can reuse. One rule is that in any of the lightbox dialogs that pop up you can reuse _q, _c and _b because you aren't be able to interact with anything else there.

  • _Quit
  • _Continue
  • _Back
  • _Close (#9-1-4)
  • _Remove (#9-1-4)

Brief pygobject Introduction

pygtk is dead. Nothing in the new anaconda UI will be using it. In its place, we have pygobject3+gobject-introspection. This is an automatic binding generation system that examines source code and generates libraries that can be used in other languages. It's not specific to Python, but that doesn't really matter for our purposes. It's also not specific to GTK. gobject-introspection can be used with just about anything.

If you need to use the new GTK bindings from within python, it's really pretty easy:

>>> from gi.repository import Gtk

One interesting note here is that anything gobject-introspection has a binding for is in /usr/lib64/girepository-1.0. Then once you've got Gtk imported, everything else looks rather familiar:

>>> w = Gtk.Window()
>>> box = Gtk.HBox()
>>> lbl = Gtk.Label("This is a label")
>>> box.add(lbl)
>>> w.add(box)
>>> w.show_all()
>>> Gtk.main()

Constants are hiding a little bit. If you want to specify whether something's oriented vertically or horizontally, you have to use Gtk.Orientation.HORIZONTAL. With a little bit of practice (and a lot of use of tab completion in ipython) you'll eventually get comfortable with how things are laid out. Since it's all automatically generated, it's at least consistently weird.

Using your glade-generated interface file is not really all that different than it used to be, either:

from gi.repository import Gtk
builder = Gtk.Builder()
builder.add_from_file("test.ui")
w = builder.get_object("window1")
w.show_all()
Gtk.main()

The key difference is that it's now get_object.

References


Work List

Title Date Posted Owner Source Link Screen Description
Language selection widget Sep 29 mgracik #1 The ListView in the center of the screen containing supported language names in their native language and in English, along with type-ahead support. Your solution should be the type-ahead filter box and scrolled list of languages. This will end up getting packed into something else in glade later, but figuring out how to get the list of languages is a good first step. The ideal solution will not involve any of the lang-names and lang-table crud we have now.
Date/Time spoke Nov 15 vpodzime #4 Nothing exists for this spoke yet. The mockup we have is based off gnome-control-center.
Language spoke Nov 15 #5 We've already got one language-related thing on the welcome spoke right up front, but this is a different one - it'll be used to select the languages that will be installed on the system. Basically you are picking the language support packages. Whatever was selected on the welcome screen should obviously be included. Likely, much of that code can be reused.
Keyboard spoke Nov 15 #6 There's already a stub keyboard selection spoke in pyanaconda/gui/ui/spokes, but it doesn't do much besides display. The finished product needs to get a list of keyboards from somewhere (preferably, nowhere that anaconda maintains), the buttons should do something, and so forth. When applied, this spoke should both set the current keyboard and update ksdata.
Disk utilization pie chart Sep 29 bcl http://fedorapeople.org/gitweb?p=bcl/public_git/anaconda-ui.git;a=summary #9-1-1 A little pie chart that appears next to a DiskOverview showing how much of the disk is free. The black part indicates used space, and the white part indicates free space. Your solution should be a class or method that takes in a total size and an in-use size and returns the pie chart. The size of the chart itself should not be fixed - that is, it should be able to scale larger and smaller as necessary.
Installation options dialog Sep 29 mgracik #9-1-5 A simple light box dialog that pops up after Continue is clicked on the Install Destination spoke. Your solution should be a class that returns information about which button was clicked, along with whether to do custom partitioning.
Configure network spoke Jan 10 rvykydal #1-3 #1-3-1 #1-3-2 #1-3-3 I think we need to divert from mockups so that we can (re)use nm-c-e for network configuration (nm-c-e for selected device is invoked by Configure button) while our own spoke UI code will be used just for network control - list of devices/access points, turning on/off, access point selection, status information - which is what gnome-control-center does in desktop. The initial UI is taken from g-c-c glade file, just some functionality and UI we don't need/support in installer is hidden and e.g. device description details are added. We need also nm-applet as Secrets Agent for wireless authentication. Network configuration is applied (as in desktop) only after configured device is restarted (using on/off switch). Video: http://rvykydal.fedorapeople.org/network_spoke.webm (note that it is taken using test harness in desktop, so in presence of nm-applet service).
Exception reporting Jan 17 While most everything has been moved into report, there's still a little bit of UI code under our control left for exception handling. This is either in python-meh or in pyanaconda/exception.py and pyanaconda/gui.py. The first thing to think about here is an API that will be common among both the TUI and GUI. Then, the existing exception handling code needs to be adapted to that API. Right now it just fails so we have no effective error reporting. Any anaconda work can be done right on the newui branch, but python-meh currently has no branch.

Completed Items

Title Date Posted Date Pushed Owner Commit Description
Lightbox Oct 26 Nov 30 akozumpl http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=5c2cd12319b90dae79c36fb27f9fd8d40d13665b Lightboxes are used to bring user's attention to a modal dialog by visually darkening everything but the dialog and blocking most of the input into areas outside of it. This is quite straightforward to achieve on a website or with a composing window manager which allows transparent windows. For Anaconda (metacity) we have to workaround on the gtk/gdk level to achieve a similarly looking result.