Anaconda/Work List

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

• gtkmm examples are easier to map to Python than the C ones - http://developer.gnome.org/gtkmm-tutorial/3.0/

Work List

Title	Date Posted	Owner	Source Link	Screen	Target	Description
Disk utilization pie chart	29-Sep-2011	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.
Configure network spoke	10-Jan-2012	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	17-Jan-2012	clumens			F-18 Beta	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.
Update filter UI	24-Jan-2012				F-19	The existing filter UI in iw/filter_gui.py and iw/DeviceSelector.py needs to be updated for the new UI model. This includes adding a button to storage.ui/storage.py for adding a disk, moving the old filter UI into glade (a lot of it is hand-coded due to previous glade deficiences, especially when it comes to Views and Stores), and making minor changes as called for by the new mockups. Unanswered questions: How does this fit in with the existing storage UI? How do you go back to the previous destination screen?
Make isomd5sum interruptable	24-Jan-2012	bcl		#8		According to the install source mockups, there's a Verify... button that allows you to verify the installation source. This button would use isomd5sum to do this, which first requires Python bindings. I have a rudimentary patch at http://fpaste.org/Pckp/ that allowss this, complete with callback. However, making the Cancel... button work while isomd5sum is running requires further work. This needs to be done, and the results committed upstream and packaged appropriately (the Python binding would probably end up in its own subpackage).
RAID-0, RAID-1, and RAID-5 install support	25-Sep-2012	dlehman			F-18 Beta	From dlehman: I have done sporadic testing of 0, 1, and 10 with post F-18 alpha code. I haven't set up a 3-disk system to try out 5, but there's no reason to expect problems. One thing we'll probably need that we don't yet have is a way to specify the number of spares for an MD RAID set. There's also a bug that causes a crash if you try to enable RAID on a system that has only one disk. Past that, the stuff that prevents users from choosing a RAID level that isn't appropriate based on disk count works well.
LUKS discovery and creation	25-Sep-2012	dlehman			F-18 Beta	From dlehman: The plan is to only provide this functionality in the custom spoke. Users will be able to somehow tell us they want to unlock the volume. We'll prompt for the passphrase and then tell the devicetree to populate the tree starting with the newly unlocked LUKS volume. We don't need to worry about it for any other cases since we either want to remove the encrypted block device or not--it doesn't matter what's underneath it until/unless you get to custom.
btrfs support	25-Sep-2012	dlehman			F-18 Beta	From dlehman: BTRFS should be fully functional in the beta. We expose subvolumes, data raid, and metadata raid through kickstart. Through the UI we expose subvolumes and data raid. There isn't really anything else I'm concerned with unless we decide we need to support compress at install time (you can enable compression post-install, but it won't retroactively compress the data laid down by the installer, which could be a basis for complaints/RFEs).
Basic storage custom partitioning UI	25-Sep-2012	dlehman			F-18 Beta	From dlehman: The biggest missing piece right now is setting mountpoints for existing devices/filesystems. The current UI for specifying "reformat this device" is to change the fstype, which of course doesn't provide any way to say "reformat this device with a new filesystem the same type as the current/old one". I may just add a "Reformat" checkbutton for this if mizmo doesn't have any better ideas. Support for creating encrypted devices is still absent. Mostly it needs a way to get a passphrase for the new device. There's a lot that's much better post F-18 alpha--particularly the device type switching and raid/btrfs. The basic flow is that you add a mountpoint, we create a device of the type appropriate to the autopart default. If you then want to change the type of that device, you clock on it and change the type using the combobox there. It's quite simple. If you have multiple btrfs mountpoints they're automatically converted to multiple subvols within a single volume spanning the disks. Likewise with lvs. Container sizes (vg, btrfs vol) are automatically adjusted to accomodate the defined devices. Eventually we want users to be able to specify which VG a new LV will go in, or whichs disks to use for allocation (currently it's "all disks you selected"). We'll eventually need to support lvm-on-md (aka MD PVs). I don't know how much of this will end up getting pushed to F-19. Support for manual-configuration-advanced-storage-devices is planned for F-19.
Easy multilib package installation from kickstart	25-Sep-2012	dlehman			F-18 Beta	From dlehman: It's a new option: %packages --multilib.
BOOTIF handling in dracut	25-Sep-2012	wwoods			F-18 Final	From wwoods: An attempt to fix problems with "BOOTIF" + "ip" args. It's tricky because of the way dracut network stuff is designed. I have code in a dracut branch but I think there's some things missing; I need to send it upstream and get some testing on it. Branch is here: https://github.com/wgwoods/dracut/tree/bootif-stuff
dracut cleansup	25-Sep-2012	wwoods			F-19	From wwoods: Improve dracut logging by making sure debug_off/debug_on actually work as expected. Add an 'importlib' command to clean up importing libraries, etc. Various other minor cleanups. From dcantrell: It is likely that some cleanups will come as part of the regular bug fixing process through F-18, but most of these things can wait until F-19.
Upgrade support via preupgrade	25-Sep-2012	wwoods			F-18 Final	From wwoods: So the code is currently here: https://github.com/wgwoods/fedup. Plan for F-18 Beta is to have an F-17 based upgrade tool that fetches packages *or* sets up an upgrade using a local DVD/USB image. It might not have any real GUI for beta, but it will for final. It will involve a special upgrade image, but it's just a dracut-built initramfs. This could be built by lorax, or it could just get built by running 'dracut' inside a mock chroot. This might require rel-eng involvement. I might need some assistance with: i18n stuff, GUI polish, a special plymouht theme for the upgrade, and network monitoring (e.g. running sshd in dracut, like we do for s390 cmdline installs).
Text mode installer	25-Sep-2012	jkeating			F-18 Beta	From jkeating: Text mode mostly works, with the limited spokes. I want to bring the text mode password spoke up to feature parity with the GUI one I wrote, mostly this is just validation of the password. That involves moving some code up to shared libraries and making use of that code from both spokes.
Kickstart installs	25-Sep-2012	jkeating			F-18 Beta	From jkeating: Kickstart is the big thing I'm working on right now. Unfortunately getting kickstart to work means fixing a bunch of other stuff so the patch set is having to go back a few times. Along with kickstart is support for "cmdline" which is a trigger to error out on any missing data (needs to be fixed for graphical mode too). Serial mode I have not even tried, so that's on the list to look at. As of right now, we only have timezone, root password, and a simple storage spoke (pick destination drive(s) and autopart style). I don't plan to have anything more for F-18.
Text mode exception handling	25-Sep-2012	jkeating			F-18 Final	From jkeating: We need some form of exception handling in text mode too. Right now it's a mixed bag of either traceback and immediate reboot, or just being presented with a "pane is dead" type message in tmux.
Prompt for VNC fallback	25-Sep-2012	jkeating			F-18 Beta	If gui mode fails to start, we need to prompt the user asking if they want to use VNC or proceed to the text mode installer.
updates.img/product.img handling	25-Sep-2012	jkeating			F-19	From jkeating: We need a long term solution for updates.img and product.img handling, in how we get the bits grabbed in dracut exposed and used post-pivot. We have a bandaid in place for F-18, but for F-19 we need a better fix.
s390x text mode installs	25-Sep-2012	jkeating			F-19	From jkeating: tmux works like badness in x3270, either those two need to work together well (beyond my capabilities) or we need to /not/ run tmux when doing s390x installs (and not using ssh session to start it). That brings up the next item, starting installs via ssh instead of directly in x3270. I fear that since this is how we've done it for a while, that taking it away will get some people angry. If we do allow installs via ssh, then tmux usage is actually a boon here because you can get access to logs and a shell without sshing in multiple times. We just have to figure out a flag for it, or make this the default and create a flag to tell the installer to run the install directly from x3270 (such a flag kinda exists for kickstart installs, but now we can do some interaction in x3270). If doing text mode from x3270, we do need to fix up text mode a bit. The way x3270 handles screen printing beyond the buffer is to refresh the screen and start printing at the top, so anything on screen before you hit the end is lost. Not good if that's halfway through a dialog. So we could really use some way to trigger a full screen refresh before printing the next spoke, not sure if this is possible.
iSCSI, FcOS, and other advanced storage	25-Sep-2012				F-19	Manual configuration of advanced storage devices as well as the storage filtering UI in anaconda is slated for F-19.

Completed Items

Title	Date Posted	Date Pushed	Owner	Commit	Description
Lightbox	26-Oct-2011	30-Nov-2011	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.
Language selection widget	29-Sep-2011		mgracik		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	15-Nov-2011	29-Mar-2012	vpodzime	http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=a20570f4a86e6c7299fe00913df8302e86493b2c	Nothing exists for this spoke yet. The mockup we have is based off gnome-control-center.
Language spoke	15-Nov-2011		msivak		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	15-Nov-2011		vpodzime		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.