bbconf 1.6-pre
Okay then. I don't know if anyone on the list uses bbconf, but if you
do... I'd really appreciate it if you could check out bbconf 1.6-pre
when you get a chance. There's some serious bug-squashing and feature
enhancements in this pre-release. I'll paste the relevant section of
the ChangeLog below I've updated a bunch of the build logic, so
please let me know if you have ANY issues with building bbconf (*cough*
nyz *cough*). =:) I'd like to get it right before I release 1.6 into
the wild.
If you're interested, check out the CVS version of bbconf (see
http://bbconf.sourceforge.net for CVS access directions). Thanks! =:)
- version 1.6::
- fixing bbconf to understand "~" better. Ported blackbox's
expandTilde() to QString. Still don't do "~user", but we're better
than we were. =:) Thanks to Nate Smith for bug reporting!
[vanRijn]
- okay, big change... Qt 3.0.3 or > is required for bbconf now. =:)
There's more reasons that I care to list for this, but they're all
really good. =:)
[vanRijn]
- pulling in newer and improved-er =:) acinclude.m4, ltconfig, and
ltmain.sh from kde3 directories.
Hopefully this will allow Brad to compile now. =:)
[vanRijn]
- fix for style-setting changes. Also, we now dynamically load the
list of available styles and populate our look and feel dropdown
based on what's really available on the system, rather than
hard-coding it.
[vanRijn]
- okay, more build fixes for FreeBSD. FreeBSD calls qt2's moc "moc2".
I'm curious to see what havoc we'll wreak with qt3. libqt3.so?
moc3? Thanks to Kyle Donaldson for the bug reports. =:)
[vanRijn]
- build fix for redhat boxes (?)--gzipping the man page
[vanRijn]
- taking out "(experimental)" from the --enable-mt directive
[vanRijn]
- hopefully fixing the layout issues where we were taking up rather
large amounts of screen real estate (which was not very nice of us)
[vanRijn]
- fixing kckey.cpp (lower/upper-case issues) (was stopping people from
being able to use comma, period, space, etc. for keybindings)
[vanRijn]
- fixing Makefile.in's for NetBSD builds (probably others too)--we had
LDFLAGS overridden in all the plugin Makefiles (why, I don't know).
Thanks to Thomas Klausner for the bug report.
[vanRijn]
--
,-//
| Jason 'vanRijn' Kasper :: Numbers 6:24-26
`
| All brontosauruses are thin at one end, much MUCH thicker
| in the middle, and then thin again at the far end. That is
| the theory that I have and which is mine, and what it is too.
,
| bash$ :(){ :|:&};:
`--//
Re: blackbox 0.65.a7 hangs
On 26-May-2002 Adriano Varoli Piazza wrote: > Blackbox 0.65.a7 hangs and returns to the console when I use kppp: when the > program connects and auto minimizes, blackbox exits (kppp still running). > Otherwise a great window manager. Can anyone point out a solution or a > substitution for kppp? I need something that accepts dynamic DNS names. Gnome > ppp wasn't very good at it, and I coouldn't compile bbppp. > Adriano when bbppp complains about 'friend foo' replace it with 'friend class foo'. Easy. As for the kppp crash, yuck. Please post a bug on sf.net.
blackbox 0.65.a7 hangs
Blackbox 0.65.a7 hangs and returns to the console when I use kppp: when the program connects and auto minimizes, blackbox exits (kppp still running). Otherwise a great window manager. Can anyone point out a solution or a substitution for kppp? I need something that accepts dynamic DNS names. Gnome ppp wasn't very good at it, and I coouldn't compile bbppp. Adriano
Re: doing "ALT-tab", compiling
El Sáb 25 May 2002 19:50, Tim Riley escribió: > On Sat, May 25, 2002 at 12:02:25PM -0300, Adriano Varoli Piazza wrote: > > Does anyone know how to use the tab key in bbkeys with a spanish-layout > > keyboard? (or any of the Fn keys (F1,F2...)) > > KeyToGrab(Tab), WithModifier(Mod1), WithAction(NextWindow) > > I have a spanish keyboard, and the above line the my .bbkeysrc works like > a charm. > > The F1, F2, etc. keys can be referenced in .bbkeysrc just as F1, F2, etc. > It can't get any easier than that! > > - Tim Thank you all, this worked just fine. I was using ctrl-alt-t anyway, but this is much nicer. Adriano
Re: bbkeys and dual head
> > I've got that tshirt also. from my ~/.xsession file > > exec bbkeys -display :0.0 -t -w & > exec bbkeys -display :0.1 -t -w & > > They are using the same config file, and window management > keybindings are working as expected. Only thing that seems to > behaving oddly is launching programs. > > Greg Are you sure focus is on that screen when you are trying to launch something? Just because your mouse is there does not necessarily mean that focus is there.
Re: Icon item vs. Workspace item
On 26-May-2002 Dave Serls wrote: > I may have whined about this before -- > In all versions of BB that I've used, the item text in the Workspace submenu > has the X-window title in it. Why does the same item in the Icons submenu > have only the program name? > > Dave the icon title shows the text from 'WM_ICON_NAME(STRING) = "rxvt"' just the like the actual icon would in another window manager. The workspace text shows the titlebar text. icon text is usually shorter so it would fit on an icon.
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking ord
On 26-May-2002 Marc Wilson wrote: > On Sat, May 25, 2002 at 08:35:43AM -0700, Sean 'Shaleh' Perry wrote: >> > >> > That may still give problems, when a partially visible window has focus >> > (which is often the case). >> > >> > Better maybe: Make clicking the maximize button call maximize and raise, >> > and remove raise from the maximize routine. >> > >> >> done. > > Doesn't that special-case titlebar behavior? Clicking a titlebar is > supposed to raise a window. > no no, you misunderstand. If you click the maximize button the window gets raised.
CPU usage?
something seems to be running away with my cpu usage after a while - maxing it out. Top blames X, but killing blackbox and restarting it seems to fix it (not restarting it mind you, I have it running out of a term, and I kill it and start it again manually). bb or X bug? My box has been up for four hours today, and I restarted X around the two hour mark, and just restarted bb now... so it seems to have roughly a two hour cycle.
Re: bbkeys and dual head
* Marc Wilson ([EMAIL PROTECTED]) wrote: > On Sat, May 25, 2002 at 07:13:45PM -0700, Greg Gilbert wrote: > > I just added a second head ( not running xinerama ) to my box, and > > have run into a problem with bbkeys. I have keyy bindings set up to > > launch apps, but when I use them from the second head the apps start > > on the first. Keybindings for changing workspaces are being executed > > properly on both heads. I'm using bbkeys 0.8.4 and black box 0.62.1 > > on XFree 86 4.1. > > Been there, done that, got the t-shirt. :) > > You need to run a copy of bbkeys on each head. They can share the same > configuration file. I've got that tshirt also. from my ~/.xsession file exec bbkeys -display :0.0 -t -w & exec bbkeys -display :0.1 -t -w & They are using the same config file, and window management keybindings are working as expected. Only thing that seems to behaving oddly is launching programs. Greg
Re: bbkeys and dual head
On Sat, May 25, 2002 at 07:13:45PM -0700, Greg Gilbert wrote: > I just added a second head ( not running xinerama ) to my box, and > have run into a problem with bbkeys. I have keyy bindings set up to > launch apps, but when I use them from the second head the apps start > on the first. Keybindings for changing workspaces are being executed > properly on both heads. I'm using bbkeys 0.8.4 and black box 0.62.1 > on XFree 86 4.1. Been there, done that, got the t-shirt. :) You need to run a copy of bbkeys on each head. They can share the same configuration file. -- Marc Wilson [EMAIL PROTECTED]
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking ord
On Sat, May 25, 2002 at 08:35:43AM -0700, Sean 'Shaleh' Perry wrote: > > > > That may still give problems, when a partially visible window has focus > > (which is often the case). > > > > Better maybe: Make clicking the maximize button call maximize and raise, > > and remove raise from the maximize routine. > > > > done. Doesn't that special-case titlebar behavior? Clicking a titlebar is supposed to raise a window. -- Marc Wilson [EMAIL PROTECTED]
Icon item vs. Workspace item
I may have whined about this before -- In all versions of BB that I've used, the item text in the Workspace submenu has the X-window title in it. Why does the same item in the Icons submenu have only the program name? Dave
bbkeys and dual head
I just added a second head ( not running xinerama ) to my box, and have run into a problem with bbkeys. I have keyy bindings set up to launch apps, but when I use them from the second head the apps start on the first. Keybindings for changing workspaces are being executed properly on both heads. I'm using bbkeys 0.8.4 and black box 0.62.1 on XFree 86 4.1. Greg
Re: doing "ALT-tab", compiling
On Sat, May 25, 2002 at 12:02:25PM -0300, Adriano Varoli Piazza wrote: > Does anyone know how to use the tab key in bbkeys with a spanish-layout > keyboard? (or any of the Fn keys (F1,F2...)) KeyToGrab(Tab), WithModifier(Mod1), WithAction(NextWindow) I have a spanish keyboard, and the above line the my .bbkeysrc works like a charm. The F1, F2, etc. keys can be referenced in .bbkeysrc just as F1, F2, etc. It can't get any easier than that! - Tim
Re: A couple of (OT?) questions
Hoi Es, Op Sat, 25 May 2002 16:03:31 -0500 schreef Es Bee Ex <[EMAIL PROTECTED]>: > On Sat, 25 May 2002 20:30:20 +0100 Martin Rowe <[EMAIL PROTECTED]> > wrote: > > 1. Is there a graphical app launcher that people recommend. > > ROX is a nice set of applications that together provide a FAST graphical > desktop. I just use the ROX-Filer, but there is also an icon window, and > taskbar, and other tools. > > http://rox.sourceforge.net Yes, ROX is really very nice, powerful and friendly. Groetjes, Wilbert -- Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/) http://www.stoppoliceware.org/ http://digitalspeech.org/
Re: A couple of (OT?) questions
On Sat, 2002-05-25 at 17:22, Scott Furt wrote: > Es Bee Ex wrote: > > On Sat, 25 May 2002 20:30:20 +0100 Martin Rowe <[EMAIL PROTECTED]> > > wrote: > > > >>1. Is there a graphical app launcher that people recommend. > > > > ROX is a nice set of applications that together provide a FAST graphical > > desktop. I just use the ROX-Filer, but there is also an icon window, and > > taskbar, and other tools. > > > > http://rox.sourceforge.net > > > I second this suggestion :) > Rox is an amazing program. And I'll "third" it... Using the pinboard option, you can set up a desktop -- I've got this going now for some of my oft-used apps and also on my wife's desktop. There's a panel option that gives something similar to the XFCE panel -- a place to put icons for applications and a limited amount of menuing. I haven't used it, but it looks pretty slick. It _is_very_fast_. I'll never go back to GNOME or KDE! --Matthew
Re: Resizing of windows and the slit
On 25-May-2002 Scott Furt wrote: > I've noticed behaviour that i dont think i like with > regards to resizing windows and the slit. > > When "Full max" is off, i cannot either resize the window > over the slit (or to the edge of the screen) by either > ALT+Rclick or using the handle. > > When "Full Max" is ON, i can resize the window over the > slit just fine. > perfect timing Scott (-: This is a side effect of a bug I just fixed from sf.net. We were setting client.max_width and height equal to the strut adjusted area. This is mostly my fault as I did a search and replace in the code when I implemented the struts. It did not occur to me the little ways in which this would affect things. Anyways, I am committing the fix in a moment, let me know.
Re: A couple of (OT?) questions
Es Bee Ex wrote: > On Sat, 25 May 2002 20:30:20 +0100 Martin Rowe <[EMAIL PROTECTED]> > wrote: > >>1. Is there a graphical app launcher that people recommend. > > ROX is a nice set of applications that together provide a FAST graphical > desktop. I just use the ROX-Filer, but there is also an icon window, and > taskbar, and other tools. > > http://rox.sourceforge.net I second this suggestion :) Rox is an amazing program.
Re: Resize / Move dialog box thingy
> > Wow. Yep... there we go... CVS works. > > it probably takes me longer to update my CVS repo. > and recompile than it does for you to post to the list > that it's been fixed ;) depends on the bug's complexity. Some wait for Brad and I to talk about them.
Resizing of windows and the slit
I've noticed behaviour that i dont think i like with regards to resizing windows and the slit. When "Full max" is off, i cannot either resize the window over the slit (or to the edge of the screen) by either ALT+Rclick or using the handle. When "Full Max" is ON, i can resize the window over the slit just fine. This issue is similar to my question about windows snapping to the "imaginary" slit border, becuase that same border is now being taken into account when i resize windows with "Full max" OFF. This behaviour bothers me, becuase i keep "full max" off, but sometimes want to make a window as wide as the whole screen, but am barred by doing this becuase the window can never take up the entire screen width by resizing. (I have to drag the window over to the right edge and then resize from the left handle -- which is not fun) When i click "Maximize", i want the window to steer clear of the slit, but when i ALT+Rclick, i'd like the WM to let me resize over the slit if i want to, regardless of the state of "Full max". Sorry for being so longwinded...
Re: Resize / Move dialog box thingy
Sean 'Shaleh' Perry wrote: > On 24-May-2002 Scott Furt wrote: > >>When i resize/move windows now, the little box that >>shows X: ... Y: ... looks like it inheirits the background >>image from my desktop, which is unfortunate, becuase >>black text on a dark background is near impossible to read. > > > cvs now uses window.label.focus and if that is set to parentrelative is uses > window.title.focus (which is what the parent of window.label is). This seems > to solve the problem. Wow. Yep... there we go... CVS works. it probably takes me longer to update my CVS repo. and recompile than it does for you to post to the list that it's been fixed ;)
Re: The XMMS snapping prob?
> > Sorry... i wasn't sure if it was supposed to do that or not. > i submitted it as a bug report the other day. :( > yep and I sent the same info to the bug and closed it. I would rather close a few incorrect bugs and get useful ones than not get bugs at all. > I'm really liking this whole snapping thing... it's one feature > that i really loved about KDE, and always wished that MS Windows > and other WM's would implement. Great work! and for the stable release after 0.65.0 I think window snapping will show up as well.
Re: The XMMS snapping prob?
Sean 'Shaleh' Perry wrote: > On 24-May-2002 Scott Furt wrote: > >>I was playing around with snapping today (I'm running CVS >>from 05/23), and noticed that windows will snap to the "edge" >>of the slit, even if the window is nowhere near the slit. >> >>This might be somewhat related to the XMMS-snapping problem >>that was reported a while back. >> >>Screenshot: >>http://furt.com/blackbox/bb-snap-to-imaginary-slit-border.jpg > > > That is expected behaviour. A window will snap to the strut defined area > first, then the screen edge if required. > > This is the behaviour of kwin and other wm's that support netwm and struts. Sorry... i wasn't sure if it was supposed to do that or not. i submitted it as a bug report the other day. :( I'm really liking this whole snapping thing... it's one feature that i really loved about KDE, and always wished that MS Windows and other WM's would implement. Great work!
Re: A couple of (OT?) questions
On Sat, 25 May 2002 20:30:20 +0100 Martin Rowe <[EMAIL PROTECTED]> wrote: > 1. Is there a graphical app launcher that people recommend. ROX is a nice set of applications that together provide a FAST graphical desktop. I just use the ROX-Filer, but there is also an icon window, and taskbar, and other tools. http://rox.sourceforge.net -- Joseph Applegate (SB-X) [EMAIL PROTECTED] | [EMAIL PROTECTED] UIN: 9788597
Re: A couple of (OT?) questions
On Sat, May 25, 2002 at 08:30:20PM +0100, Martin Rowe wrote: > Hi folks > > Apologies if these are a bit off topic, but they are at least Blackbox > related. > 1. Is there a graphical app launcher that people recommend. I like > Blackbox menus but as my kids can't read very well (3 & 4) icons are > easier for the time being. Basically something I can stick icons onto and > associate programs with. I think that you can use one of that WMDockApps... like for example: wmappl (http://www.upl.cs.wisc.edu/~charkins/wmappl.php). It should go nicely into the slit. > 2. I use normally .xinitrc to launch apps at start up, but I've set up > the kids box with a graphical login. Is there an equivalent for this. In > particular it needs to launch the graphical app launcher & bbkeys. I think that .xsession is that what you are looking for. > > Regards, Martin > -- > [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.dbg400.net/"\ > DBG/400 - DataBase Generation utilities - AS/400 / iSeries Open\ / > Source free test environment tools and others (file/spool/misc) X > Debian GNU/Linux | ASCII Ribbon Campaign against HTML mail & news / \ > Wojciech Krygier -- Home is where the computer is plugged in. msg06979/pgp0.pgp Description: PGP signature
A couple of (OT?) questions
Hi folks Apologies if these are a bit off topic, but they are at least Blackbox related. 1. Is there a graphical app launcher that people recommend. I like Blackbox menus but as my kids can't read very well (3 & 4) icons are easier for the time being. Basically something I can stick icons onto and associate programs with. 2. I use normally .xinitrc to launch apps at start up, but I've set up the kids box with a graphical login. Is there an equivalent for this. In particular it needs to launch the graphical app launcher & bbkeys. Regards, Martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.dbg400.net/"\ DBG/400 - DataBase Generation utilities - AS/400 / iSeries Open\ / Source free test environment tools and others (file/spool/misc) X Debian GNU/Linux | ASCII Ribbon Campaign against HTML mail & news / \
Shaded windows
I have posted posted this on sf.net as well. >I have a problem with shaded windows: After turning off the decorations for >such window, I am getting small, titlebar size client area. > >It is also possible to change size for such 'window', with ALT+RMB, however >the results are only visible after turning decorations on again. > >I am running alpha7. I think that it shouldn't be possible to switch decor state for shaded window, I can't imagine proper behavior for such event. Wojciech Krygier -- Home is where the computer is plugged in. msg06977/pgp0.pgp Description: PGP signature
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking ord
> > That may still give problems, when a partially visible window has focus > (which is often the case). > > Better maybe: Make clicking the maximize button call maximize and raise, > and remove raise from the maximize routine. > done.
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking ord
Hoi Sean, Op Sat, 25 May 2002 08:22:14 -0700 (PDT) schreef "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]>: > > On 25-May-2002 Sean 'Shaleh' Perry wrote: > >> > >> Hi Sean, SF timeouts; so here's an update: One of the Xterms has to > >be> vertically maximized. The toolbar changing place is probably > >affecting the> window placement. > >> > > > > now *THAT* is an important piece of the pie. > > > > When you have a window open in maximized state (vertical, horizontal > > or both) and you move the toolbar or the slit the strut is recomputed > > and all maximized > > windows are shifted to fit into the new strut. > > > > The maximize code in blackbox makes a call to raiseWindow() because it > > does not > > good if you click the maximize button and the window stays below > > anything else > > on screen. I can probably modify this to only raise the window if the > > window has focus which will alleviate the problem. > > I have committed a patch to do this. Let me know how it works out. It does not work, the vertically maximized rxvt's are still always raised when moving the toolbar. Good Luck!! Groetjes, Wilbert -- Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/) http://www.stoppoliceware.org/ http://digitalspeech.org/
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking ord
Hoi Sean, Op Sat, 25 May 2002 08:15:53 -0700 (PDT) schreef "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]>: > > > > Hi Sean, SF timeouts; so here's an update: One of the Xterms has to be > > vertically maximized. The toolbar changing place is probably affecting > > the window placement. > > > > now *THAT* is an important piece of the pie. > > When you have a window open in maximized state (vertical, horizontal or > both) and you move the toolbar or the slit the strut is recomputed and > all maximized windows are shifted to fit into the new strut. > > The maximize code in blackbox makes a call to raiseWindow() because it > does not good if you click the maximize button and the window stays > below anything else on screen. I can probably modify this to only raise > the window if the window has focus which will alleviate the problem. That may still give problems, when a partially visible window has focus (which is often the case). Better maybe: Make clicking the maximize button call maximize and raise, and remove raise from the maximize routine. Groetjes, Wilbert -- Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/) http://www.stoppoliceware.org/ http://digitalspeech.org/
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking ord
On 25-May-2002 Sean 'Shaleh' Perry wrote: >> >> Hi Sean, SF timeouts; so here's an update: One of the Xterms has to be >> vertically maximized. The toolbar changing place is probably affecting the >> window placement. >> > > now *THAT* is an important piece of the pie. > > When you have a window open in maximized state (vertical, horizontal or both) > and you move the toolbar or the slit the strut is recomputed and all > maximized > windows are shifted to fit into the new strut. > > The maximize code in blackbox makes a call to raiseWindow() because it does > not > good if you click the maximize button and the window stays below anything > else > on screen. I can probably modify this to only raise the window if the window > has focus which will alleviate the problem. I have committed a patch to do this. Let me know how it works out.
Re: doing "ALT-tab", compiling
>
> [ Just grabbing the LinkedList.{hh,cc} from the latest blackbox release
>that had that one might do it too, but I've not checked. ]
>
yep, grabbing from 0.62.1 is safe.
This is one of the reasons we are working towards a shared blackbox lib. Each
bbtool carries around the same bugs which have to be fixed again and again.
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking ord
> > Hi Sean, SF timeouts; so here's an update: One of the Xterms has to be > vertically maximized. The toolbar changing place is probably affecting the > window placement. > now *THAT* is an important piece of the pie. When you have a window open in maximized state (vertical, horizontal or both) and you move the toolbar or the slit the strut is recomputed and all maximized windows are shifted to fit into the new strut. The maximize code in blackbox makes a call to raiseWindow() because it does not good if you click the maximize button and the window stays below anything else on screen. I can probably modify this to only raise the window if the window has focus which will alleviate the problem.
Re: doing "ALT-tab", compiling
* Mads Martin Joergensen <[EMAIL PROTECTED]> [May 25. 2002 17:09]:
> Seems bbsmount needs to be 'ported' to gcc 3.x. Give me a minute or two.
Well, porting is not really what one can call it, rather
your-usual-gcc3x-one-liner. Apply the patch below.
diff -ur bbsmount-0.2.3/LinkedList.hh bbsmount-0.2.3.gcc3x/LinkedList.hh
--- bbsmount-0.2.3/LinkedList.hh2001-05-17 19:29:36.0 +0200
+++ bbsmount-0.2.3.gcc3x/LinkedList.hh 2002-05-25 17:11:06.0 +0200
@@ -63,7 +63,7 @@
int elements;
__llist_node *_first, *_last;
- friend __llist_iterator;
+ friend class __llist_iterator;
protected:
[ Just grabbing the LinkedList.{hh,cc} from the latest blackbox release
that had that one might do it too, but I've not checked. ]
--
Mads Martin Jørgensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic
and totally illogic, with just a little bit more effort?"
-- A. P. J.
Re: doing "ALT-tab", compiling
On 25-May-2002 Adriano Varoli Piazza wrote: > Does anyone know how to use the tab key in bbkeys with a spanish-layout > keyboard? (or any of the Fn keys (F1,F2...)) dunno about this > I also have troubles compiling bbsmount: when using make for > bbsmount-0.2.3, it stops with a message of "LinkedList.hh:66: friend > declaration requires class-key, i.e. 'friend class __llist_iterator". > If anyone has had a similar trouble, please help me. > Adriano this is a problem found in most of the non maintained bbtools. They are slightly incorrect with regards to the ISO C++ standard and you are likely using g++ 3.x which now enforces this standard. bascially everywhere we used to be able to say "friend foo" we have to say "friend class foo".
Re: [ blackboxwm-Bugs-560479 ] Toolbar pref changes stacking order
Hoi [EMAIL PROTECTED],
Op Sat, 25 May 2002 08:00:28 -0700
schreef [EMAIL PROTECTED]:
> Bugs item #560479, was opened at 2002-05-25 07:03
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=428680&aid=560479&group_id=40696
>
> Category: Behaviour
> Group: CVS
> >Status: Pending
> Resolution: None
> Priority: 5
> Submitted By: Nobody/Anonymous (nobody)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Toolbar pref changes stacking order
>
> Initial Comment:
> Using this mornings CVS the window stacking order is
> changed when moving the toolbar.
> to reproduce:
> - open 2 overlapping windows on a workspace (eg Xterms)
> - right click toolbar and choose another placement
> - toolbar moves and the lower window is raised!
> - if not, raise the other window and try again.
>
> The window stacking order is somehow not changed when
> moving the toolbar from Bottom Left to Bottom Middle.
>
> The window stacking order also changes sometime when
> swithing the toolbar's AutoHide option from disabled to
> enabled.
>
>
> --
>
> >Comment By: Sean 'Shaleh' Perry (shaleh)
> Date: 2002-05-25 08:00
>
> Message:
> Logged In: YES
> user_id=37132
>
> I want to believe this, but perhaps this is simply auto
> raise happening? The code should not be able to cause this:
>
> void Toolbarmenu::Placementmenu::itemSelected(int button,
> unsigned int index) {
> if (button != 1)
> return;
>
> BasemenuItem *item = find(index);
> if (! item) return;
>
> getScreen()->saveToolbarPlacement(item->function());
> hide();
> getScreen()->getToolbar()->reconfigure();
>
> // reposition the slit as well to make sure it doesn't
> intersect the
> // toolbar
> getScreen()->getSlit()->reposition();
> }
>
> neither reposition() nor reconfigure() talk to any other
> object in blackbox but the toolbar or the slit.
>
> the auto hide code is similar.
>
> --
>
> You can respond by visiting:
> http://sourceforge.net/tracker/?func=detail&atid=428680&aid=560479&group_id=40696
>
Hi Sean, SF timeouts; so here's an update: One of the Xterms has to be
vertically maximized. The toolbar changing place is probably affecting the
window placement.
Groetjes,
Wilbert
--
Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/)
http://www.stoppoliceware.org/ http://digitalspeech.org/
Re: doing "ALT-tab", compiling
* Adriano Varoli Piazza <[EMAIL PROTECTED]> [May 25. 2002 17:02]: > Does anyone know how to use the tab key in bbkeys with a spanish-layout > keyboard? (or any of the Fn keys (F1,F2...)) Use the program 'xev' to figure the symbols for the keys in question. > I also have troubles compiling bbsmount: when using make for > bbsmount-0.2.3, it stops with a message of "LinkedList.hh:66: friend > declaration requires class-key, i.e. 'friend class __llist_iterator". Seems bbsmount needs to be 'ported' to gcc 3.x. Give me a minute or two. -- Mads Martin Jørgensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort?" -- A. P. J.
doing "ALT-tab", compiling
Does anyone know how to use the tab key in bbkeys with a spanish-layout keyboard? (or any of the Fn keys (F1,F2...)) I also have troubles compiling bbsmount: when using make for bbsmount-0.2.3, it stops with a message of "LinkedList.hh:66: friend declaration requires class-key, i.e. 'friend class __llist_iterator". If anyone has had a similar trouble, please help me. Adriano
little toolbar bug
Hi, sorry if this got mentioned earlier, but I dont know: Using this mornings CVS the window stacking order is changed when moving the toolbar. to reproduce: - open 2 overlapping windows on a workspace (eg Xterms) - right click toolbar and choose another placement - toolbar moves and the lower window is raised! - if not, raise the other window and try again. The window stacking order is somehow not changed when moving the toolbar from Bottom Left to Bottom Middle. The window stacking order also changes sometime when swithing the toolbar's AutoHide option from disabled to enabled. (reported as bug as well) -- Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/) http://www.stoppoliceware.org/ http://digitalspeech.org/
Re: Menu bug
On Sat, 2002-05-25 at 20:01, Sean 'Shaleh' Perry wrote: > > On 25-May-2002 Matt Wilson wrote: > > I couldn't help myself - I found a bug... ;-) > > > > I'm seeing a rather erratic bug in the menu, where sub-menus are failing > > to close for a few seconds when a sibling sub-menu is opened (ie one > > with the same parent). > > > > how are you getting two children open at once? > > I don't know, that's the bug... I'm opening one, mousing over the popped-out menu, then mousing over another entry in the root menu, and that's when this seems to be happening... but like I said, I can't reproduce it with any regularity... it did happen twice in about 3 minutes, but I haven't been able to do it again.
Re: Menu bug
On 25-May-2002 Matt Wilson wrote: > I couldn't help myself - I found a bug... ;-) > > I'm seeing a rather erratic bug in the menu, where sub-menus are failing > to close for a few seconds when a sibling sub-menu is opened (ie one > with the same parent). > how are you getting two children open at once?
Re: Menu bug
On Sat, 2002-05-25 at 19:55, Matt Wilson wrote: > I couldn't help myself - I found a bug... ;-) > > I'm seeing a rather erratic bug in the menu, where sub-menus are failing > to close for a few seconds when a sibling sub-menu is opened (ie one > with the same parent). > > This results in having two overlayed menus, only one of which should be > open. The old one seems to close within about five seconds. > > I put a ss up, altho I had to fake it by tearing menus off, cos it was > impossible to ss it. (so that's why they don't actually make sense if > you look at the names, compared to the root menu - just imagine they're > the other way around, menus seem to have no stacking control) > > http://pages.quicksilver.net.nz/mwilson/menu.png > > See what you think... sorry I couldn't get you more info on it, but it's > a slimy one... > > Matt. > sorry, just thought I should clarify a few points: I see there is menu stacking, with the order of definition defining z-index. The bug I'm seeing seems to override this, with the later menu overlaying the earlier - in the case of the ss, the "internet" menu/"development" menu stacking would be reversed if the bug had caused it. (what happened for me was - referring to the ss again - the "dev" menu was over the top of the "apps" menu). Matt.
Menu bug
I couldn't help myself - I found a bug... ;-) I'm seeing a rather erratic bug in the menu, where sub-menus are failing to close for a few seconds when a sibling sub-menu is opened (ie one with the same parent). This results in having two overlayed menus, only one of which should be open. The old one seems to close within about five seconds. I put a ss up, altho I had to fake it by tearing menus off, cos it was impossible to ss it. (so that's why they don't actually make sense if you look at the names, compared to the root menu - just imagine they're the other way around, menus seem to have no stacking control) http://pages.quicksilver.net.nz/mwilson/menu.png See what you think... sorry I couldn't get you more info on it, but it's a slimy one... Matt.
Re: alpha7 released
> > so is that gonna stay that way, or are transients going to get placed > normally too? you do not want transients to get placed. Think about it, where on your screen right now would the next "open location" window land? Or "file open" or save dialog? Letting the application place them generally means they open where you expect them to. In the case of the mozilla preference window it is a transient owned by the root window so perhaps it should be handled differently. Will mention this to Brad and see what he thinks as he is currently doing the transient cleanup work.
Re: alpha7 released
On Sat, 2002-05-25 at 19:29, Sean 'Shaleh' Perry wrote: > so here it is. > > The preference dialog is viewed as a transient now (it was not before). The > new window code does this: > > place_window = True > if (blackbox is just starting or the user specified coords or this is a > transient) > if (window is on the screen) > place_window = False; > > if place_window is true the usual algorithm is applied. If it is not the > window is opened where the application/user requested. > so is that gonna stay that way, or are transients going to get placed normally too?
Re: alpha7 released
> > nope, preferences dialog for bluefish also... mozilla preferences too > (but not moz "open" dialog)... > so here it is. The preference dialog is viewed as a transient now (it was not before). The new window code does this: place_window = True if (blackbox is just starting or the user specified coords or this is a transient) if (window is on the screen) place_window = False; if place_window is true the usual algorithm is applied. If it is not the window is opened where the application/user requested.
