| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Marks all methods containing mostly gtk calls as gtk_thread_wait
or gtk_thread_nowait
- Uses gtk_call_once instead of GLib.idle_add to make sure the
method is called only once (returns False)
- Removes some code from the threading locks, because it wasn´t
touching Gtk at all
This change was discussed in the mailinglist here:
https://www.redhat.com/archives/anaconda-devel-list/2012-October/msg00030.html
The main point was:
According to the Gtk team, the gdk_threads_enter/leave pair should
not be used at all (and they have apparently discouraged usage of
it since early releases of Gtk2). Moreover in the current Gdk docs
(http://developer.gnome.org/gdk3/stable/gdk3-Threads.html)
those functions are now marked as deprecated.
The preferred way (and now the only way) is to use g_idle_add
(GLib.idle_add) with a callback method to schedule GUI changes.
The callback method will then get called by the Gtk main loop so
no locking is needed (and GLib.idle_add performs none). But that
is also the reason why everything Gtk related must be done from
the mainloop thread either directly or via idle_add.
|
|
|
|
|
| |
We need this to quit when handling errors, since doing a sys.exit() from a
thread only kills the thread and not the main program.
|
|
|
|
|
| |
This is handled by glade, and the fact that the spinner doesn't spin right now
is due to a GTK bug.
|
|
|
|
|
| |
This provides room to display the personalization on the same screen as the
progress bar, which is what the mockups call for.
|
|
|
|
|
| |
- Splits doInstall to doInstall and doConfiguration
- Updates text and gui mode to use doConfiguration
|
| |
|
|
|
|
|
|
| |
Instead of constantly creating new Images and shoving them into a spot in
the notebook, I'm now just putting each rnote on its own page. Whether
it's better or not is up for debate, but at least this way works.
|
|
|
|
|
| |
Using GLib.idle_add for action that repeats means 100% CPU usage. So
let's use GLib.timeout_add with 250ms interval instead.
|
|
|
|
|
| |
This means you can't alt-tab away from the spoke and do stuff on the hub
and really confuse anaconda.
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Modify the continueButton to exit (allowing the anaconda exitHandler to
take control) if it is the last action. The button is expected to be
setup so that it is clear to the user what will happen (eg. REBOOT).
This also fixes the display of the quitDialog when rebooting.
Add a click of the final button when kickstarting with reboot or
shutdown.
halt also works, but requires a new version of pykickstart. Previously
the halt command was not working, it would set action to KS_SHUTDOWN and
there was no way for KS_WAIT to be set.
|
| |
| |
| |
| |
| |
| | |
xgettext is dumb and only looks at file extensions. It has no way to let
you tell it what extension maps to what language on the command line. Thus,
out glade files must be .glade if they are to get translated.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This first fixes a bug where a spoke's apply and execute methods were being run
even when skipTo was set. In this case, we don't usually want apply to be run
because the user needs to do something else first. In particular, skipping from
the dep solving error dialog (still in progress) to the software selection
screen was resulting in problems.
Having fixed that, some spokes do actually need to have apply run even when
skipping. Storage is a prime example of that.
|
|/ |
|
|
|
|
| |
It looks a little silly to have it sitting there and stopped.
|
|
|
|
|
|
|
|
|
| |
If you're on a spoke when all other spokes become ready and complete, the
install will continue automatically when you hit back. If you're on the hub,
the install will continue automatically when all spokes are ready and
complete.
It's a little jarring, but that's just how it's gotta be.
|
|
|
|
|
|
|
| |
It can only be sensitive both if there's no incomplete spokes and no not
ready spokes. By not tracking not ready spokes, it's possible to hit
continue while things are still downloading. This can lead to very bad
situations, and it's only by accident that we've not hit this yet.
|
|
|
|
|
|
|
|
|
| |
This first requires splitting out the chunk that calls execute methods into its
own function, then adding an execute method to spokes, then making sure it gets
called from everywhere. I have also added a way to make sure the execute
methods do not get run when spokes are ready, since at least the storage check
function will set the spoke not ready and then ready again which will lead to
an infinite loop.
|
|
|
|
|
| |
This is a hint that we're still doing something, even if an individual step
takes a long time.
|
| |
|
|
|
|
|
|
| |
This way, it looks highlighted when you come back to the hub just like if
it was selected with the keyboard, and keyboard navigation will start on
the spoke that was just visited.
|
|
|
|
|
|
|
|
|
|
| |
The Queue poll inside the GLib idle state was causing 100% CPU usage, it
was being called multiple times per second. It would be more efficient
to be able to use a select() or poll() with the Queue, but that isn't
possible. So, run the Queue processing in a 1 second timeout. CPU usage
drops to almost nothing.
Also add a call to q.task_done() for unrecognized messages.
|
|
|
|
|
|
| |
Starting off with the "Preparing to install" message makes the pause up front
seem a little less weird, and moving the package installation message around
means there's less pause after the last filesystem is made.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The basic idea is that we skip any standalone spokes that are already filled out
by the input kickstart file, and that we only display the summary hub so that
something's being displayed while background processes work.
Any important spokes not filled out by the input kickstart file will get the
caution icon and the user will have to complete them before continuing. The
message at the bottom of the summary hub explains that.
This behavior leaves open the possibility that the user will be able to visit a
spoke while background processes work. In that case, we want to wait until the
user leaves that spoke before automatically continuing. The alternative is to
move as soon as anaconda is ready, which is really quite jarring.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Using a queue worked so well elsewhere that I should use it for spoke-to-hub
communications as well. This has several advantages:
* No passing around a callback.
* Allows for marking a spoke as not ready later after it's become ready.
* Allows for changing the status of a not ready spoke to let the user know why.
* Uses the same abstraction as is in use elsewhere.
|
|
|
|
|
|
| |
It will automatically cycle the image every 60 seconds. Similarly to how
it all used to work, we will check for images in directories both containing
a language-specific component and not.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the previous code, I could never get the UI to be redrawn to reflect the
changes, even though the changes appeared to have taken effect.
This new code instead uses a message queue for communication between the thread
doing all the hard work and the main thread that handles GTK stuff. The storage
code will shove messages into that queue when it does something like create a
filesystem, and the main thread watches in the idle loop for messages.
I've also provided yet another context manager to make all this code simpler.
|
|
|
|
|
| |
Otherwise, there's a brief moment where "Installing %s" is visible before
the real work starts.
|
|
|
|
|
|
|
| |
First, it means we can move the special run behavior into the run method
directly instead of the roundabout way it was being done. Second, it
provides a place to make sure the thread gets removed from the threadMgr's
list when it terminates.
|
|
|
|
|
| |
Otherwise, small int/bigger int = 0, which means the progress bar will always
be stuck.
|
|
|
|
|
|
|
| |
There's nothing particularly clever about this. It just calls the ksdata
execute methods linearly, makes partitions, and installs packages. Error
handling is not yet in good shape and neither is progress reporting.
However, an autopart setup will actually make partitions.
|
|
|
|
|
|
|
| |
We need to be able to update the progress bar and the message independently.
The message should be updated when an action begins so you know what's
taking so long, and the progress bar should be updated when an action ends
so you know how far you are through now.
|
|
|
|
|
| |
This is going to be handy for the custom partitioning spoke which we do not
want to dispaly on the hub.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
I think that's a better description of what the method actually does. Hopefully
I'll be able to keep everything straight.
|
|
|
|
|
|
| |
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.
|
| |
|