- Mar 24, 2010
-
-
Charles Brej authored
Typo in previous commit. Should have unreffed the hash and not the function object.
-
Charles Brej authored
This means string operations now can be applied on raw strings rather than having to cast them using the String() class template wrapper. String("something").CharAt(3) now becomes simply: "something".CharAt(3)
-
Charles Brej authored
The name_exp was already set to the thing we wanted, so use that. Less confusing since other sections use it.
-
Ray Strode authored
When we access to the kernel console's fb, we don't own it and shouldn't remove it. This is like commit 808e129f, but for radeon and nouveau instead of intel.
-
Ray Strode authored
-
Ray Strode authored
-
Charles Brej authored
Testing for the presence and falling though to return a NULL makes more sense.
-
Charles Brej authored
Fixes a compile error about a static declaration following an implicit declaration.
-
Ray Strode authored
-
Ray Strode authored
-
Ray Strode authored
Before we were calling the handler directly when it wasn't in response to an escape key press event, which was a little groaty.
-
Ray Strode authored
This will just help down the line if there are problems.
-
Ray Strode authored
I wasn't handling NULL return value correctly before.
-
Ray Strode authored
-
Ray Strode authored
commit cf766763 was messed up in more than one way. The biggest problem was that It didn't include the Makefile changes needed to ship the files added to the repository. This commit fixes that.
-
Ray Strode authored
-
- Mar 23, 2010
-
-
Ray Strode authored
This series of commits adds a few configuration files to replace the kludgey symlink we use now for theme specification. In the future, these config files could potentially be used for other things as well.
-
Ray Strode authored
This commit adds plymouthd.defaults and plymouthd.conf. The former is for distributions to override, and the latter is for administrators to change.
-
Ray Strode authored
Now that the daemon looks for the default theme in configuration files, we should make plymouth-set-default-theme write the configuration files instead of doing symlinks. That's what this commit does.
-
Ray Strode authored
Right now we figure out the default theme via a symlink. This apprach is very simple, but is also a little cumbersome. It means as the default theme is changed around we have to move the symlink around. The symlink is in /usr. We really shouldn't be mucking with /usr when changing defaults. This commit checks the filesystem for two config files: /usr/share/plymouth/plymouthd.defaults and /etc/plymouth/plymouthd.conf The first one is for distributions to use. This is how they can manage which splash to show from release to release. The second one is for system administrators. This is how they can override distribution policy. We don't actually ship these files yet. In the mean time, (and even after for the forseeable future) the old symlink method will still work.
-
Ray Strode authored
It's an old interface that I don't think anyone is using.
-
Ray Strode authored
It was my email address, but should probably be bugzilla (or the mailing list)
-
Ray Strode authored
This just modernizes the file a bit.
-
- Mar 22, 2010
-
-
Charles Brej authored
Previously the code was assuming the windows were placed at 0,0. This might not be the case and the window X and Y values should be used when trying to position items relative to a window. This change needs to be applied to all other scripts otherwise mutiple screen setups may have unaligned elements. Updates scripts should be tested using multi-head test systems or the x11 test renderer.
-
Charles Brej authored
Values were preset to zero which was the smallest width/height.
-
Charles Brej authored
Calls to Window.GetWidth/Height/X/Y without a window index now return the values of the area covered by all windows. This is only the case if all the windows are aligned (either by their centers, or to a corner). This allows the theme designer to place an object knowing it will be seen on all screens.
-
Minor bug, previously would return the index used rather than a NULL. Would only cause problems when using a width request as a test of the presence of a window.
-
When multiple screens are found, the system will now arrange them so they are all centered, and the top left corner of the largest screen is at 0,0. No changes to any scripts are needed.
-
Ray Strode authored
If we're done with the VT plymouth was running on, and plymouth wasn't running on the initial VT, we should jump back to the initial VT and try to clean up plymouth's VT.
-
Ray Strode authored
This will jump off the VT associated with the terminal and deallocate it.
-
Scott James Remnant authored
Resetting the mode to text on every write means that if you're using a text plugin and X starts, X's VT keeps getting reset back to KD_TEXT since those plugins don't stop writing on deactivate (they have no renderer). There's no reason to set this mode here anyway; all paths to using those plugins already do this.
-
Scott James Remnant authored
Instead of setting the terminal to unbuffered (raw) mode on every write, keep track of whether it's unbuffered or not at the points we open and close the terminal. Deactivate already takes care to set back into buffered mode; otherwise we can end up resetting the terminal mode under X causing Enter to send X SIGQUIT.
-
Scott James Remnant authored
If we don't deactivate the renderer before hiding the splash, the drm renderer may scan out the buffer contents to the fbcon buffer; since we only hide the splash when dumping details or when --retain-splash is *not* given to quit, this is exactly the opposite of what we want. The effect of not doing this is partial splash contents behind the details in cases of error, or when using quit. This doesn't affect plymouth quit --retain-splash.
-
Scott James Remnant authored
One problem with the current deactivate/quit transition into X is that the display manager will, if Plymouth was running, re-use the currently active VT. That only works if Plymouth was actually displaying a splash screen on that VT. If --show-splash hasn't been called yet because we booted too fast, we'll be on the wrong VT. Add a request to ask whether the Plymouth VT is active; I've done it this way so the answer defaults to "yes" for Fedora who use VT1. The pseudo-code for transition is thus: if plymouth is running (ping): plymouth deactivate if plymouth has active vt: start X on current VT with -nr if X starts ok: plymouth quit --retain-splash else if X fails: plymouth quit else if plymouth doesn't have active vt: plymouth quit start X as normal else if plymouth isn't running: start X as normal
-
Scott James Remnant authored
This asks the daemon whether it has an active VT, used for a smooth transition into X. I've implemented this to look like ping.
-
Scott James Remnant authored
Change the display_normal() function so that rather than being a no-op if we already saved the state as normal, it restarts any animations and redraws the views. The only thing we now do if the state is not previously the same is hide any prompt. This allows this to be used to reanimate the plugin on reactivate.
-
Scott James Remnant authored
Change the display_normal() function so that rather than being a no-op if we already saved the state as normal, it restarts any animations and redraws the views. The only thing we now do if the state is not previously the same is hide any prompt. This allows this to be used to reanimate the plugin on reactivate.
-
Scott James Remnant authored
Change the display_normal() function so that rather than being a no-op if we already saved the state as normal, it restarts any animations and redraws the views. The only thing we now do if the state is not previously the same is hide any prompt. This allows this to be used to reanimate the plugin on reactivate.
-
Scott James Remnant authored
Change the display_normal() function so that rather than being a no-op if we already saved the state as normal, it restarts any animations and redraws the views. The only thing we now do if the state is not previously the same is hide any prompt. This allows this to be used to reanimate the plugin on reactivate.
-
Scott James Remnant authored
Since deactivate uses on_boot_splash_idle, there's a good chance that plugins will have stopped animating. Prod them to animate again by calling update_display()
-