Alastair Porter | 1 Mar 03:30 2003

Re: black bar where panel used to be

try deleting $CHOICES/ROX-Filer/pan_PANEL

On Sat, 2003-03-01 at 09:08, Albert Wagner wrote:
> I was exploring how panels worked and used the command roc -t=PANEL to
> place a panel at the top.  Then I used --top= to remove the panel. 
> However, when removed, a black bar remained at the top where the panel
> was and I cannot get rid of it. It behaves as part of the background
> (button-3 brings up fluxbox menu rather than panel menu).  I have
> reinstalled wallpaper, logged off/on, and rebooted, but nothing gets rid
> of black bar.  Also, there was no pan_* file created in any of the
> Choices dirs while the panel was created.  I have 1.3.7 installed.  How
> might I fix this?
> 
> Albert
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> rox-users mailing list
> rox-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rox-users
--

-- 
(o< - A l a s t a i r   P o r t e r
//\          -- NEW EMAIL --
V_/_   alastair <at> linuxexperience.com

(Continue reading)

Peter Geer | 1 Mar 03:37 2003

Backdrop corruption - ROX 1.3.7 bug?

Hello all!

I downloaded ROX 1.3.7 last night, and I am pleased.  But...my backrop is
now messed up.  It's like the backdrop is being moved around in addition
to being randomly corrupted.  It's hard to put into words, so I put up a
web page with some screenshots.  You can find it here:
http://www.cs.sunyit.edu/~geerp/bad_backdrop.html

I'm using the latest developer version of Wallpaper to set the backdrop,
but resetting it by hand didn't seem to help.  I haven't noticed anything
in particular that's causing it other than just lots of window movement,
i.e. screen repainting.

For context, I'm running Slackware Linux 8.1 with a Sawfish 1.2 for GTK+
1.2 and ROX 1.3.7 compiled from source using GTK+ 2.0.5.

So, has anyone else experienced a similar problem?  Is this a bug, or is
my configuration just really, really messed up?

-------------------
Peter Geer
geerp <at> sunyit.edu

"If you can't beat them, arrange to have them beaten." --George Carlin

BluPhoenyx | 1 Mar 04:24 2003

Re: black bar where panel used to be

> I was exploring how panels worked and used the command roc -t=PANEL to
> place a panel at the top.  Then I used --top= to remove the panel. 
> However, when removed, a black bar remained at the top where the panel
> was and I cannot get rid of it. It behaves as part of the background
> (button-3 brings up fluxbox menu rather than panel menu).  I have
> reinstalled wallpaper, logged off/on, and rebooted, but nothing gets rid
> of black bar.  Also, there was no pan_* file created in any of the
> Choices dirs while the panel was created.  I have 1.3.7 installed.  How
> might I fix this?

I'm not a big 'box fan so I'm a bit rusty here but I think the issue is not actually ROX but the wm itself. It
sounds like the ROX program is running hidden. You could try running something like gtop or a term then the
command killall rox before exiting the window manager.

Peter Geer | 1 Mar 04:38 2003

Re: Backdrop corruption - ROX 1.3.7 bug?

Following up on my previous message...

I played with this a little bit, and the problem seems to happen
consistently when I select "Backdrop..." from the pinboard right-click
menu.  I didn't actually change anything - just opened the backdrop
window.  After that, whenever a section of the screen is forced to
repaint, it seems to move the backdrop down farther.  The only way I can
get the backdrop back to the normal position is to log out.

I hope that proves informative.

-------------------
Peter Geer
geerp <at> sunyit.edu

"If you can't beat them, arrange to have them beaten." --George Carlin

BluPhoenyx | 1 Mar 05:17 2003

Re: Re: Backdrop corruption - ROX 1.3.7 bug?

> I played with this a little bit, and the problem seems to happen
> consistently when I select "Backdrop..." from the pinboard right-click
> menu.  I didn't actually change anything - just opened the backdrop
> window.  After that, whenever a section of the screen is forced to
> repaint, it seems to move the backdrop down farther.  The only way I can
> get the backdrop back to the normal position is to log out.

Did you try only using the Rox pinboard (and the backdrop setting) without running the wallpaper program?
Wallpaper isn't actually necessary with on all setups. For example, my system simply uses the XFWM4 and
ROX pinboard which load the backdrop quite nicely.

Mike T

Alastair Porter | 1 Mar 06:00 2003

Re: black bar where panel used to be

On Sat, 2003-03-01 at 11:38, Albert Wagner wrote:
> .(Like I know what the difference
> is between stretch and scale :-)
> 
stretch fills the whole screen
scale is proportional
--

-- 
(o< - A l a s t a i r   P o r t e r
//\          -- NEW EMAIL --
V_/_   alastair <at> linuxexperience.com

Stephen Watson | 1 Mar 11:01 2003
Picon
Picon

Re: Re: Backdrop corruption - ROX 1.3.7 bug?

Peter Geer <geerp <at> cs.sunyit.edu> wrote:

> Following up on my previous message...
> 
> I played with this a little bit, and the problem seems to happen
> consistently when I select "Backdrop..." from the pinboard right-click
> menu.  I didn't actually change anything - just opened the backdrop
> window.  After that, whenever a section of the screen is forced to
> repaint, it seems to move the backdrop down farther.  The only way I can
> get the backdrop back to the normal position is to log out.

Same happens here.  I had also seen this before (but I didn't know what
triggered it), so added a debug line to pinboard.c:

diff -c pinboard.c~ pinboard.c
*** pinboard.c~	Fri Feb 28 18:17:14 2003
--- pinboard.c	Fri Feb 28 18:24:17 2003
***************
*** 1492,1497 ****
--- 1492,1500 ----
  		{
  			gdk_gc_set_fill(gc, GDK_TILED);
  			gdk_gc_set_tile(gc, style->bg_pixmap[GTK_STATE_NORMAL]);
+ 			printf("gc clip %d,%d ts %d,%d\n", gc->clip_x_origin,
+ 			       gc->clip_y_origin, gc->ts_x_origin,
+ 			       gc->ts_y_origin);
  		}

  		gdk_draw_rectangle(current_pinboard->window->window, gc, TRUE, 

(Continue reading)

Guido Schimmels | 1 Mar 10:54 2003
Picon

Re: System and TreePS

On Fri, 28 Feb 2003 16:25:17 -0600
Albert Wagner <alwagner <at> tcac.net> wrote:

> I have both System and TreePS installed.  System shows ROX-Filer as a
> child of init, yet TreePS shows it as a child of ROX-Session.  Is one
> right and the other wrong?

Both are right. init is the first process started upon boot. Every other
process is a child of init. System by default only shows you the processes
started with the user's account. Only those you can modify/kill directly.
"Show All Processes" will show you the remaining processes owned by root 
or special daemon users, with init at the top.You cannot kill them
with your user account.

--

-- 
Guido Schimmels <guido.schimmels <at> freenet.de>

Thomas Leonard | 1 Mar 13:56 2003
Picon

Re: System and TreePS

On Fri, Feb 28, 2003 at 04:25:17PM -0600, Albert Wagner wrote:
> I have both System and TreePS installed.  System shows ROX-Filer as a
> child of init, yet TreePS shows it as a child of ROX-Session.  Is one
> right and the other wrong?

ROX-Filer should be a direct child of ROX-Session. ROX-Session should be
a descendant of init, but not a direct child normally.

I have this:

init
 |
 +- gdm
     |
     +- gdm
         |
	 +- ROX-Session
	     |
	     +- ROX-Filer

Perhaps you are running more than one copy of the filer? If the process
that started the filer quits, the filer will become a direct child of
init. However, the one started by ROX-Session shouldn't be a direct child,
because ROX-Session hasn't quit.

--

-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r <at> ecs.soton.ac.uk		tal197 <at> users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

(Continue reading)

Thomas Leonard | 1 Mar 14:05 2003
Picon

Re: Re: Backdrop corruption - ROX 1.3.7 bug?

On Sat, Mar 01, 2003 at 10:01:12AM +0000, Stephen Watson wrote:
[ backdrop image problem ]
> Putting gdk_gc_set_ts_origin(gc, 0, 0); in seems to fix it.

Applied. Hope that fixes it...

--

-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r <at> ecs.soton.ac.uk		tal197 <at> users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1


Gmane