| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
| |
We're going to need to do this for the advanced partitioning stuff anyway,
and now it looks like we'll need a Storage to do a reset on the base repo
when it's changed in the source spoke. Might as well make the change now.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out, I need this callback to handle updating the hub's completeness
tracking. When spokes are first created, the hub checks to see if they
are complete and what their status is for making the grid. Then for spokes
that take a long time setting up, they fire off a thread and immediately
return. When that thread finishes, the completeness and status may have
changed but there's no way to update the hub.
Thus, this argument has to return.
|
| | |
|
| | |
|
| |
|
|
|
| |
When I added "Closest mirror", I bumped down everything in the drop down by
one position. That needs to be reflected here.
|
| |
|
|
|
|
|
|
|
|
| |
sqlite doesn't get along very well with multithreaded programs. Oh sure
it's got threading support, but you can't use a database handle created in
one thread from within another thread. Thus, we need to close all the
databases down before doing any accesses from elsewhere.
It's conceivable other payload backends will have similar problems, so I've
just added a generic method.
|
| |
|
|
|
|
|
|
|
|
|
| |
Once again, we're doing something in a pattern:
Gdk.threads_enter()
do something
Gdk.threads_leave()
This is another perfect example of the sort of thing the context manager can
really help clean up.
|
| |
|
|
|
|
| |
This doesn't actually do anything to change the total amount of time everything
takes, but it does move the later delay to happen at the same time as you are
already waiting for the spoke to become ready.
|
| |
|
|
|
|
| |
If I'm in too big of a hurry to skip through the networking screen with an
alt-c, I can sometimes end up with a traceback where we've tried to refresh
the UI with no selected device. So just bail out of the function.
|
| |
|
|
|
|
| |
Since yumpayload is going to set up the mount for the detected media already,
we can't just try to mount it again. That'll never work. Instead just check
what we've already detected and display the selector if appropriate.
|
| |
|
|
|
| |
It doesn't currently do anything (method isn't set, and the hub does not show
anything useful) but all the UI elements are there.
|
| |
|
|
|
|
|
|
| |
We don't want to allow visiting the software selection spoke until there's a
repo set up to pull group names from. A repo could be set up in a variety
of ways - cmdline or kickstart, autodetected CD/DVD, Fedora mirror if network
is available, or filling out the source spoke. Just wait until the repo
fetching thread is done.
|
| |
|
|
|
|
|
|
|
|
|
| |
This isn't the final data we want displayed. Right now I'm just dumping
desktop groups in the left list and everything else in the right list. Later
we will want spin-like things in the left list and groups related to those
spin-like things in the right list.
However, this is good enough for now to show that the packaging code works.
Also, the selections made on this spoke will now be propagated into the ksdata
and show back up next time the spoke is visited.
|
| |
|
|
|
|
| |
* Add more spacing between the two lists.
* Add a margin between the borders of the lists and their contents.
* Fix word wrapping.
|
| |
|
|
|
|
| |
We claim to return a list, but since we never unmount after
finding valid media, we can never return a list of more than
a single device.
|
| | |
|
| |
|
|
| |
I had too many layers of Gtk.main_quit in there.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This requires some weird glib IO channel code to handle updating the progress
bar while a process runs, but it's really not all that bad. Notifying the user
whether their media is good or not is still rough, but at least there's
something there while we figure out what really should be going on.
I have temporarily removed the Cancel button as that makes things a lot more
difficult and we can always work on it later if we really need it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
All our lightbox code so far follows a similar pattern:
make a lightbox
do some stuff
destroy a lightbox
That pattern is exactly what context managers are for. So, I've added an
enlightbox manager so you can use it in a with statement.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Basically, only call set_sensitive after doing all the _initialize stuff instead
of right after the thread we were watching is gone. Doing the latter allows the
user to enter the spoke before it's really set up.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It consists of a very basic ProgressReporter class and singleton that serves
as a wrapper around the UI implementation so anaconda doesn't need to know
what kind of interface is running, and then a couple methods in the existing
GUI progress bar class to set things up.
|
| |
|
|
|
|
|
|
| |
For now, all that's supported is copying screenshots. However this could
be extended to other portions that really don't benefit from being in
python (restorecon, etc.). Of course none of these scripts get run yet
given that we don't have any way to run the kickstart file, but once we
do we'll get this for free.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Passing in the readyCB means multiple callbacks end up referencing the same
selector. I could probably do something very clever here, but just adding
the reference is pretty clean. I'm not sure why I was so opposed to doing
this in the first place.
Note that this also changes the skipTo handling to match.
|
| |
|
|
|
| |
We treat it like an attribute later by trying to set it, which of course
doesn't work on a regular property.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This is just like it was in the old UI, except there's no dialogs telling
you if it worked or not. Also, you can take a screenshot of anything that
derives from UIObject. This includes most (but not all) dialogs.
Note that the part that copies screenshots over to the finished system is
still missing, but that fits in with a whole set of post-installation tasks
that we don't have figured out yet.
|
| | |
|
| |
|
|
|
| |
I think that's a better description of what the method actually does. Hopefully
I'll be able to keep everything straight.
|
| |
|
|
|
| |
I've hopefully put enough comments around this process that we'll be able
to find it when it causes problems in the future.
|
| |
|
|
|
|
| |
I can't keep "populate" and "setup" straight in my head since they sound
like they should do the exact same things. This is the first step in
straightening out the mess.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain spokes (storage somewhat and software selection especially) require that
some basic sanity checks be performed before continuing. In the case of
software selection, this process could take a very long time. Also, it needs
to be done before going to the second hub since the user may have to make
changes and we don't allow going back.
The solution, then, is a check method that's run out of yet another thread.
It's started as soon as the Back button is clicked on a spoke. If the user
goes back into the spoke, we request the thread exit. If the user clicks
Continue on the hub before checking is done, the hub will need to wait.
A couple things need to be done before this all works: First, Hubs need a
way of noticing that check threads are still running and wait for them (with
a notification dialog). Second, check threads need to be derived from a
class that enforces them having a main loop and kill switch.
|
| | |
|
| |
|
|
|
| |
Conflicted with Continue. I chose letter close to the first one,
but perhaps consonant or g is better?
|
| |
|
|
| |
Don't report unplugged for plugged unmanaged (NM) devices.
|
| | |
|
| | |
|
