It would appear that on Sep 16, Nicky726 did say:
Dne Čt 16. září 2010 06:27:23 Joe(theWordy)Philbrook napsal(a): ---<<snip>>---
I'll followup to this thread if one of AUR's themes works for me. -or- if e17 respects "xrandr" resolution settings...
I did followup with the info that some of the AUR themes worked for me and that E17 was respecting the xrandr command...
This reminds me I did change screen resolution via an autorun script on E17 some time ago (when E17's resolution control showed only the default screen resolution).
I can't find the script now, but simply running "xrandr -s 1024x768" from terminal inside od E17 changes the resolution correctly. Running just "xrandr" should give you the list of supported resolution, if the desired one is not listed you have to add a modeline. When you have the correct xrandr call(s) tested, you can automate it by creating say change-resolution.sh (should go in your PATH I think): #!/bin/sh xrandr -s ...
which you then set up to autorun in control center -- aplications -- aplication on start (hope I translated it correctly from my localization).
Thanks! And your right "xrandr -s 1024x768" is the correct command to set a "1024x768" screen resolution. But when I ran "xrandr" with no argument I found that it was the forth listed resolution thus since the alternative form "xrandr -s <index>" starts with zero, I saved myself 7 keystrokes when I originally added the command: xrandr -s 3 to my xinitrc-e16 files that get copied to ~/.xinitrc when I choose e16 on one of my installed linux distros... I went with the .xinitrc method because when I used xrandr from inside an already running e16 it worked except that the borders of any window I opened cheerfully started or ended (or both) outside the new desktop area. By running xrandr inside the .xinitrc it took effect just before e16 started, and so new windows were by default sized and positioned inside the desktop area. Now it's fairly likely that by setting a script up in what in my e17's localization is "menu->settings->settings panel->apps->startup applications" would accomplish the same thing. But since I use startx rather then some display manager to initialize X I'm used to the ~/.xinitrc method. But I thank you for the clue. It could happen that the linux developers might do something to make the use of display managers mandatory, then I'd have to try the autorun script method. Heck, Ubuntu kinda sorta have done so already. In order to get a runlevel 3 startup with my *xubuntu (*without having to wade through some gui, pop-up error menus) I had to install a simplistic display manager (slim) which unlike gdm & kdm still respected the debian method of: => update-rc.d -f foobar remove => update-rc.d foobar stop 20 2 3 4 5 . If the rest of the linux distros (and available display managers) follow ubuntu's (and gdm's) example I might have to give up on startx. Till then, for me, it's the only wayto go... -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>