FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-29-2012, 01:10 PM
Martin Sivak
 
Default GUI TODO

Hi Chris,

some of the outstanding entries in the TODO list in newui branch lack enough context. We mostly understand the summaries, but would like to know more about your ideas and directions you want to pursue. Can you please elaborate on some of the following items? (in the TODO itself or on the list). We can think about solutions ourselves, but as it is your design, you probably have ideas about how to make it properly and consistently. We would like to hear those.


- Custom partitioning needs to be revisited, then written.
- Disk tug-o-war needs to be written.
- Test handling of inconsistent LVM/RAID, and uninitialized disks.

If I followed correctly, this is what you are doing ATM, right?

- Install hub needs to be skipped if all spokes are completed on a kickstart install.
How to handle the fact that spokes may only be ready once they're finished downloading?

This would be handled in Hub's refresh method I assume. Can we detect that a spoke is still downloading? I mean, do we have a "spoke ready" message? We might just show the Hub screen with information about the ongoing operation and then continue once everything is ready && completed. I am not sure about whether we should allow the user to make any changes while in ks mode, we used to ask for stuff we didn't get, so we probably should..

- Update exception handling. This requires updating python-meh to use gtk3,
which also requires updating firstboot and s-c-ks to gtk3. I want to turn
s-c-ks into an anaconda wrapper first, though.

Anything we can help with (the gtk port is obvious)? How do you envision the wrapper to work and interact with newui anaconda? Do we still want s-c-ks? I thought we are about to kill it and use the newui in standalone mode.

And what about firstboot and anaconda widgets? Do we still plan to implement interoperability there? (I am asking because there is another project seeking to replace firstboot - https://fedoraproject.org/wiki/Features/InitialExperience )

- Wall of anaconda needs to be taken into account.

I have no idea what this is supposed to mean...


--
Martin Sivák
msivak@redhat.com
Red Hat Czech
Anaconda team / Brno, CZ


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 05-29-2012, 02:35 PM
 
Default GUI TODO

> - Custom partitioning needs to be revisited, then written.
> - Disk tug-o-war needs to be written.
> - Test handling of inconsistent LVM/RAID, and uninitialized disks.
>
> If I followed correctly, this is what you are doing ATM, right?

I am currently looking at the first one, and I'll look at the second one
at some point soon too. The third one, I've got no ideas on.

> - Install hub needs to be skipped if all spokes are completed on a kickstart install.
> How to handle the fact that spokes may only be ready once they're finished downloading?
>
> This would be handled in Hub's refresh method I assume. Can we detect
> that a spoke is still downloading? I mean, do we have a "spoke ready"
> message?

Much of this might actually already be done. See the bottom of
_update_spokes in hubs/__init__.py.

If everything's done before the hub is even displayed (is this even
possible? perhaps just for media installs) then we need something
clever in GraphicalUserInterface.setup.

> We might just show the Hub screen with information about the
> ongoing operation and then continue once everything is ready &&
> completed. I am not sure about whether we should allow the user to
> make any changes while in ks mode, we used to ask for stuff we didn't
> get, so we probably should..

We should definitely allow making changes. With the new hub and spoke
model, we're even letting the user do more than we did in the previous
installer, since they can go and change anything not just stuff they
didn't fill in.

> - Update exception handling. This requires updating python-meh to use gtk3,
> which also requires updating firstboot and s-c-ks to gtk3. I want to turn
> s-c-ks into an anaconda wrapper first, though.
>
> Anything we can help with (the gtk port is obvious)? How do you
> envision the wrapper to work and interact with newui anaconda? Do we
> still want s-c-ks? I thought we are about to kill it and use the newui
> in standalone mode.

I am still planning on killing s-c-ks, but I don't think that's going to
happen for F18 either. So, we're going to need to come up with another
plan if we want graphical bug reporting in anaconda. I guess the
easiest thing to do would be to just remove python-meh code from s-c-ks
so that dependency doesn't exist anymore.

We do not have a design for how exn handling should look in the newui.
We'll talk about that. If anyone wants to get started looking at the
code changes required, go right ahead.

> And what about firstboot and anaconda widgets? Do we still plan to
> implement interoperability there? (I am asking because there is
> another project seeking to replace firstboot -
> https://fedoraproject.org/wiki/Features/InitialExperience )

I don't know about this one yet. It's my expectation that we won't get
around to doing the firstboot things in the UI until F19, so there's
some time to figure it out.

> - Wall of anaconda needs to be taken into account.
>
> I have no idea what this is supposed to mean...

http://blog.linuxgrrl.com/2011/12/21/the-wall-of-anaconda/

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 10:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org