You are not logged in.
Pages: 1
When I start up into the Xfce desktop, my panels (one at the top and one at the bottom of the screen) show as a very short line at the screen edge. If I select the panel within that small area, that panel will appear and become full-sized. The same happens for the other. Once that is done, they never revert back during that session.
Why don't they start out full-sized to begin with so that the user doesn't have to search the screen edge for that small sweet spot to make the panel appear?
Thanks.
Offline
Right-click your panel(s) > "Customize Panel". Make sure "Fixed position" and "Full Width" are selected.
Offline
Thanks for the reply.
I have it set to "Normal Width". Are you impling that doesn't work correctly? Is it a bug I've found? :?
Offline
That sounds almost like the way the Autohide setting works, but:
a) Autohide doesn't require you to actually click on the panel to make the panel appear.
b) The panel should disappear back into the screen edge once the cursor moves off of the panel.
I'm probably not going to be able to help you, but the people who will be able to help you are probably going to want to know which version of Xfce you are running. It may also be helpful for them to know which Linux distro you are running, what additional desktop environments (if any) you have installed, and which graphics subsystem and drivers you are using.
Offline
Well, let's see. I have the latest, as supplied by ArchLinux updates, in everything. Xfce is 4.6.1, video card is Radeon-based, xorg-server is 1.6.3.901.1, gnome-desktop 2.26.3-1, xfdesktop & xfwm4 4.6.1-1, and kdebase-runtime 4.3.1-1. I'm not sure what else would be of interest.
However, I am sure that all is working well, as far as the video hardward connections go. The display is crystal-sharp and has no anomalies. The hidden, shortened panels reveal the same amount of edge as when they are full-sized. Their response is the same with mouse-over. It is just that they expand on the first mouse-over after computer startup, and don't go back to a fore-shortened version until the next start of Xfce.
It is true that the Autohide feature works exactly right. No problem there. It is more likely that the shutdown process stores the panel size at some smallest setting rather than leaving it as it is at shutdown time. It has got to be something in the underlying code.
I'm stumped. :-|
Offline
I'm stumped, too, though it does sound as though you might be right about this being an issue with session settings being saved inappropriately. I presume you've checked to see if there might be more than one place where that could be determined.
The reason I asked about video card / driver was that I've seen certain combinations of desktop environments and video cards / drivers do quirky little things. For instance, my nvidia quadro workstation card with any of the binary blob drivers not getting along with GNOME of any vintage. No big failures, just lots of weird little glitches in the DE. Same card with the Open Source driver -- no problems in any DE.
I hope someone's going to come up with a suggestion.
Offline
Me too, buddy, me too......
I also don't know where to look for settings. It seems as though there is no rhyme or reason to the way things are organized. Linux is certainly no better than windoze in that regard. At least we can tweak to our hearts' content, although it would help to know what one is doing. ;D
I do believe that I am becoming more and more "a jack of all trades". Sadly, I'm afraid I'm also becoming more of "a master of none". :-| Dirty Harry said that a man's gotta know his limitations, but I think that I have actually reached my "level of incompentence", according to the "Peter Principle"; at least when it comes to these details. Sometimes you just want it to be simple, for pity sake. Am I really the first one to experience this? :?
Oh well, I'll just keep my fingers crossed in the hope that someone will come along with an idea. At least everything works pretty good otherwise. (Maybe it would be nice if it were faster, but its okay.)
Thanks for your good thoughts.
Offline
I'm using an earlier version of Xfce. In my version Settings > Sessions and Startup Settings (xfce-setting-show setting) brings up the basic dialog that lets me determine whether or not session settings will be saved automatically when logging out or whether or not I will be prompted to save the settings. If it's the same on your version, have you tried toggling the settings?
Just shooting in the dark here.
Offline
Nice idea, but with Xfce it appears to be all or none. I can save the whole session, with the programs and settings and everything, or I can save nothing. There is no granularity.
But that may all be besides the point. This is happening clearly at another level.
Offline
Nice idea, but with Xfce it appears to be all or none. I can save the whole session, with the programs and settings and everything, or I can save nothing. There is no granularity.
Yes. This little feature bit me a couple of times before I realized how it was best for me to use it. For instance, I once had the xfce4-panel fail on me. I had the DE set to save my session settings upon logging out. It makes sense that choosing to log out and then log back on wouldn't help me solve that problem. (When I logged out the session was saved without xfce4-panel running, so my ensuing session had the panel missing. The way to fix the problem was to crank up xfce4-panel, and then log out with session saving enabled.
For that reason I think that having the sessions just autosave isn't such a good idea. I've set my systemsto prompt me, and then leave the save session checkbox for saving the session settings on the logout dialog unchecked. That way, if I've changed some session setting that I actually do want to perpetuate, I can check that box on my way out of the session. But most of the time I make sure that it is unchecked -- just in case something has gone awry.
For me this works pretty well. I just take care to set up my session exactly the way I want it, log out with save session checkmarked, and then make sure to UNcheck the save session settings checkbox the next time I log out. From then on, any inadvertent changes I make to my desktop session -- like a failure of an essential component which leaves something important turned off -- will not be saved when I log out.
But that may all be besides the point. This is happening is clearly at another level.
Unfortunately, I suspect you are correct. Since there's really no setting (at least none that we can think of) to cause deliberately the behavior you're seeing, it's probably being caused by a glitch in a configuration file or some other error on the system. And I guess it's not likely to be fixed by a simple change in the GUI for the desktop environment.
Maybe someone who actually knows what s/he is doing will see us flailing about here and offer a tidbit of helpful information. I'm going to do a little reading on the panel later today, when time permits, to see if I can see any promising avenue to explore.
Sorry that the only "help" I've provided so far has been commiseration. :oops:
Offline
Certainly better than none, and appreciated! Thanks. You get the "cool" sticker.
It appears clear to me that the real issue is in the GUI settings. To explain that, let me make a general comparison to start. If I create a proper program, that program must be the one to control itself. It must keep its own settings and maintain its own pathways. Further, it should always be self-contained and stand-alone. It should not rely upon the rest of the system, except to interface (in standard ways) with the hardware, and it should be created with the idea that the GUI side of things would automatically fit into whatever DE the user was using. Removing its directory should remove all of it as if it never existed.
One nice feature would be to utilize the user-specified paths to keep one's unique settings and data in the places one desires for ease of backup and reference. Further, we should have a very finely-grained control over every aspect of the GUI, including colors and/or skins, positioning of components, etcetera, and yet we are not given those choices in the way the program interacts with the OS or with the X server or DE or much of anything else. Huge flaw, and an obvious fundamental one as well!
So we are left with no way to have the precise control over the GUI settings simply because of bad program design. Sure, everyone does it. But that doesn't make it right. And I am not going to demand a different way, because the programmers aren't charging me to use what I do. Interesting conundrum, that!
So I believe the control over the GUI elements of the DE are not available to us, and that is the problem here. Also, if we did have all the controls we desire, there would be far less need of technical support since there would be far fewer things beyond our immediate control. Right now I haven't a clue where the settings are kept, and if I did, I wouldn't know what they mean. That means that users are caught between a rock and a hard place, and that is the sad state of affairs with software now.
I'm still hoping a Xfce desktop specialist comes along and can follow the code track of this error and fix it. If this behavior is possible, then other odd things can happen as well. The programming must stop all attempts to change it that are not user forced.
Offline
Well, I can sympathize with your frustration. However, I have found Xfce to be far more to my personal liking than any of the bigger desktop environments in common use in Linux. Those larger DEs do provide more fine-grained control of at least some aspects of the environment through GUI tools. However, I haven't seen any indication in my personal and business use of those environments that they are more reliable. In fact, I found GNOME and KDE to be far less reliable (on the particular systems I work with) than Xfce (and fluxbox and lxde and IceWM).
The neat thing about GNU / Linux / Open Source to me is that there are a lot of very different, very bright developers trying to solve the same issues through a wide variety of approaches. That makes it possible, over time, for me to find a way to really tailor a system to my preferences.
Take the menu system, for instance. In GNOME, there are reasonably advanced GUI applets available for editing / tweaking / maintaining the menu system. Every version of this editing capability that I've seen has had glitches in it. They get fixed over time, but there's an overlay of menu system glitches with menu control applet glitches, and it can be darned hard sometimes for a newcomer to figure out which is which. In Xfce (I use 4.4.2 in Debian stable.) there's a rudimentary menu editor. I use it only for making the simplest top level changes in the menu system. (As a matter of fact, I think I've used it twice.) It's easy enough to add applications or alter the way applications are launched by editing files in /usr/share/applications. I understand that 4.8 (could be wrong about the version) will have a more advanced menu editor that may be intended to give the end user a GUI approach to doing all that I do currently by adding / subtracting / editing .desktop files. That's cool, but it's not a big deal to me.
I'm pretty sure that the panel behavior you're seeing is not a feature, but a bug. Furthermore, it may not be a bug in Xfce. I can't tell you how many idiosynratic desktop environment behaviors (especially in GNOME and KDE) I have seen fixed (or caused) by changes in drivers and in optional components. The two biggest troublemakers I've seen in trying to achieve a reliable desktop environment have been nVidia's proprietary video drivers (when used with some of their higher-priced hardware) and additional desktop environments.
The thing is that Linux gives us choices that just aren't available in a closed source system. Some of those choices may come with attendant issues caused by conflicts that we have created ourselves -- conflicts unforeseen by developers because the devs didn't think to try several different DEs together, with patched themes in each one, etc. If I'm using a couple of different environments that happen to make use of common components, and if some of the configuration requirements for those two DEs conflict with each other, I'm going to wind up with some kind of glitch in one environment or the other or both. Linux puts many user-specific configuration settings within the user's home directory. What if environment A and environment B both want to affect the same setting in in a .gnome2 or .gconf setting? Last writer wins. And the next time you start up the other environment, something odd happens in the affected portion of the environment or the affected application.
Also, because what you're seeing is probably a bug instead of a feature, I'm not sure what help a more detailed GUI applet for controlling panel behavior would be in this case. And, unless it's a known bug, I'm not sure what help an Xfce specialist can be.
If I had the problem you're seeing I would try removing alternate DEs or additional features like patched themes from the system. If that didn't fix it, I'd also remove and then reinstall Xfce. I'd also experiment with changes (if possible) in the video driver. I'd make the changes one-at-a-time to see what effect, if any, each change made to the system behavior.
It has been my experience, but by no means a universal experience, that the Open Source drivers that come standard with a given distro will work the most reliably -- at the expense sometimes of advanced functionality. My most expensive graphics card in my main system is nVidia. It cost almost twice what my entire 2nd and 3rd systems cost. It doesn't work reliably with the standard proprietary drivers available in Ubuntu, Mint, Mepis, Slackware, Arch, or Debian. It doesn't work any better with compiled proprietary drivers. So I use it with the standard OpenSource drivers. That means that desktop compositing in Xfce is unbelievably slow and glitchy on my expensive workstation, so I don't bother with it. Desktop compositing would work with the proprietary drivers, but then I'd be seeing glitches like the one you're seeing with xfce4-panel. I'd rather have simple and glitch-free than fancy with the occasional glitch, but that's a personal choice.
The cheap integrated ATI and Intel graphics subsystems on my other two systems absolutely fly with desktop compositing enabled. No glitches in anything. Go figure.
There are so many different hardware combinations and so many different installed software combinations available to us in Linux that we're pretty much required to do some trial-and-error -- especially if we're running multiple DEs or unusual hardware.
I hope you'll find a way through this. I'm keeping an eye out for information on the specific issue and will come back to post if I find anything. I haven't even actually gone looking for it as a bug report. Might be something there, but they can be hard to run down due to differences in the way we all express ourselves.
I've only been using Linux for a year. I find it a lot easier to troubleshoot most issues because of the wealth of openly published information. My biggest problems in Linux have always centered around the use of binary blobs (proprietary drivers) and use of cutting edge environments, hence my drop back to Debian stable after experimentation with the testing or experimental based stuff.
I'll be watching to see what happens.
Offline
Additional note. I just checked, and the bugzilla tracker for Xfce does list several items that might be related to this problem. (I should have checked there first.) It could be helpful to you to go there to read the listings related to the category xfce4-panel. I searched on the term "autohide" and got a number of hits that seem at least peripherally related to your problem. The bug tracker for your distro might have pertinent information, too.
Offline
Woo-hoo!!! ;D If you could see me I'd be dancing right now.
I just found an error message. It might not be the right thing, but it looks close. It was found at the command prompt in the background. It is:
(xfce4-panel :2905): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -9 and height 1
Wow, that sounds like something! I'm excited! I've got something to look for now. I'm back in the game!
As usual, I find your thoughts very insightful and you are very articulate in stating them. I couldn't agree more. By the way, I also believe that Xfce is far better than the alternative DE's. (Frankly, I wouldn't waste my time if it wasn't.) It has less overhead and that alone makes it better. In fact, my experience is that the extras that the others give really comes from third parties or patches, to be functional in any meaningful way.
As I implied before, you are right about the time element. That probably is the most frustrating, but that is what it takes. We just have to wait. I've always known that there's a huge amount of talent (and I mean "HUGE"), but it sometimes lacks direction. But that's a rant for another time.
Anyway, back to the hunt. I'm so excited.... ;D
Offline
It certainly does sound as though you are on the track of the problem. I'll be watching.
Offline
Thanks, Alain, for the support.
I think I've found something, but I'm not sure what is wrong. It appears that X is not working correctly. I say this because I've found some odd lines of messages at the command line and they don't appear correct.
Why does it state:
enable primary dac
disable primary dac
finished PLL1
disable primary dac
disable primary dac
Another time I read:
waiting for X server to shut down xfce4-clipman: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
..disable primary dac
finished PLL1
.error setting MTRR (base = )xe0000000, size = 0x04000000, type = 1) Invalid argument (22)
And another:
env: artsshell: No such file or directory
I've been able to glean those off the screen. They are a little too cryptic for my taste, or even to be useful for the average Joe. Does anyone know what they mean?
Thanks again.
Offline
I found a solution.
Best deal here was to either delete the whole thing and re-install, or to remove all related dot-directories in the user's own area. I used the former because of some other issues, but a couple odd things happened anyway until I removed a couple directories that were left behind in the area I wanted to save.
One has to be very careful with some upgrades that can ruin everything, especially when using a rolling-release distro. I believe this was the original problem. Somehow an incompatibility slipped in and allowed the normal configuration-saving routines to get chewed up and create bad info. But all is good now.
Yes, it would have been nice to have a self-healing system, or one not able to screw up any setting without confirmation. Barring that, it would have at least been nice to have a GUI method of configuring settings where the user could configure things back the way they should be. None of those was a possibility.
One could try to guess which directories to eliminate and allow to be re-created automatically, but the interrelationship of so many parts makes it likely that one will have far-reaching consequences with their trial-and-error attempts. Might as well re-install the whole thing, and be more careful next time.
By the way, it is probably a good idea to ignore some error messages since they can exist even when everything is working fine. Just don't look for them.
Thanks to all who helped.
Offline
I'm glad to see that you got it sorted. I'm sure you were hoping to find out exactly why this happened, but sometimes the law of diminishing returns on your investment of time kicks in and you're just better off removing and re-installing.
The number of combinations / permutations (because order of installation and configuration sometimes matters) of components and settings in these operating systems and their desktop environments is huge. I'm surprised we don't get more guff from them than we do -- especially in the rolling release versions. That has to be a testament to the skill of the developers and the community. I occasionally see wacky behaviors like this in Windows XP SP3, and Microsoft has had a lot of time to eliminate bugs in that product!
Offline
Pages: 1
[ Generated in 0.012 seconds, 7 queries executed - Memory usage: 640.02 KiB (Peak: 672.94 KiB) ]