Java/Blackbox oversized window bug with IBM JRE
Hello I just experienced this bug using IBM's newest JRE v1.3.1. It does *not* happen so frequently with IBM's JRE as with Sun's, though, but still, it happens.(Again, dialogs are the problem) Just wanted to point this out, so we know it doesn't only happen with Sun's java stuff. -- Øyvind S.
Re: Java/Blackbox oversized window bug with IBM JRE
Chris Grossmann wrote: Note: Using the four-letter j word seems to be a good way to make Shaleh use the four-letter f word. ;) On July 25 (12:45 EDT), Øyvind Stegard wrote: Hello I just experienced this bug using IBM's newest JRE v1.3.1. It does *not* happen so frequently with IBM's JRE as with Sun's, though, but still, it happens.(Again, dialogs are the problem) Just wanted to point this out, so we know it doesn't only happen with Sun's java stuff. -- Øyvind S. Yup, I can certainly understand that. =). It seems like a very hard bug to squash, and doesn't even seem like Blackbox's fault AFAIK. Still, I find it important, simply because many people use Ja** applications, and secondly because it doesn't happen with other WMs (at least the 3, or 4 others I've tried). I hope I am not making anyone angry by giving some input to this Ja** issue. :). -- Øyvind S.
Re: Java/Blackbox oversized window bug with IBM JRE
Sean 'Shaleh' Perry wrote: Yup, I can certainly understand that. =). It seems like a very hard bug to squash, and doesn't even seem like Blackbox's fault AFAIK. Still, I find it important, simply because many people use Ja** applications, and secondly because it doesn't happen with other WMs (at least the 3, or 4 others I've tried). I hope I am not making anyone angry by giving some input to this Ja** issue. :). a bug is a bug. Have you tried fvwm2? Nope, I have not tried this wm. Just visited the web page where it belongs. I could give it a whirl later today, perhaps. Will tell my observations of how it behaves with java. (I'll try JRE's from Sun and from IBM) -- Øyvind S.
Re: Java/Blackbox oversized window bug with IBM JRE
Jamin W. Collins wrote: On Thu, 25 Jul 2002 13:52:16 -0700 (PDT) Mr. Brigham Young [EMAIL PROTECTED] wrote: Q: How do you make a Pentium III perform like a 386? A: Use Java Apps Boy have you been using the wrong Java Apps. Yup, a bit exaggerated. The speed of the newest JVMs is great, if you ask me. Most Java apps I use, run quite smoothly. Btw, I experienced the bug with the Blackdown JRE too, but the problem was more often too small dialogs than too big.(Like dialog sizes of 2x10 pixels and such) - *Covering my head from flying coffee cups/other easily accessible/throwable desktop objects* =). So I've tried three different JVMs now, none of them likes to cooperate with Blackbox. Also worth mentioning, all applications I've tried are quite heavy, and needs a bit of loading time. I think I remember hearing someone talk about this.
bbconf 1.8 configure error(libqt3 detection)
Perhaps someone here can help me with this: Tried to compile latest and greatest bbconf on my Mandrake 8.2 system(lotsof upgrades done). I have installed libqt3-3.0.4 and libqt3-devel-3.0.4, but the configure script complains that it cannot find qt (=3.0.3), and aborts. (Can't find libqt-mt). I have verified that this library IS available with ldconfig -v. Any tips on how I can get the configure script to properly detect the installed qt-libraries ? Regards, ØS.
Re: bbconf 1.8 configure error(libqt3 detection)
Ben Jansens wrote: On Thu, Jul 18, 2002 at 12:33:44PM +0200, ?yvind Stegard wrote: Perhaps someone here can help me with this: Tried to compile latest and greatest bbconf on my Mandrake 8.2 system(lotsof upgrades done). I have installed libqt3-3.0.4 and libqt3-devel-3.0.4, but the configure script complains that it cannot find qt (=3.0.3), and aborts. (Can't find libqt-mt). I have verified that this library IS available with ldconfig -v. Any tips on how I can get the configure script to properly detect the installed qt-libraries ? libqt-mt is different from libqt. libqt-mt is what KDE uses. Perhaps that will help you track it down. xOr Isn't just libqt-mt the [m]ulti[t]hreaded version of libqt ? I have the libqt-mt.so.3.0.4 file installed and recognized by the dynamic linker.(All development files are also installed) So I should have the correct library installed. I cannot see why bbconf configure script won't recognize it. I have also tried all the --with-qt-dir=..., --with-qt-libraries=, --with-qt-includes= switches and setting the QTDIR variable. Also, there are several different symlinks pointing to libqt-mt.so.3.0.4, in the lib-dir, with various simpler names including libqt-mt.so.
Re: bbconf 1.8 configure error(libqt3 detection)
Sean 'Shaleh' Perry wrote: I have verified that this library IS available with ldconfig -v. Any tips on how I can get the configure script to properly detect the installed qt-libraries ? libqt-mt is different from libqt. libqt-mt is what KDE uses. Perhaps that will help you track it down. xOr Isn't just libqt-mt the [m]ulti[t]hreaded version of libqt ? I have the libqt-mt.so.3.0.4 file installed and recognized by the dynamic linker.(All development files are also installed) So I should have the correct library installed. I cannot see why bbconf configure script won't recognize it. I have also tried all the --with-qt-dir=..., --with-qt-libraries=, --with-qt-includes= switches and setting the QTDIR variable. Also, there are several different symlinks pointing to libqt-mt.so.3.0.4, in the lib-dir, with various simpler names including libqt-mt.so. unless you have libqt-mt-devel or whatever your dist calls it the configure script won't find it. Yep, like I said, I have all the development files installed as well. (libqt3-devel-3.0.4 package). I also jsut noticed that someone has filed a bug on the same problem at bbconf.sf.net.
Re: bbconf 1.8 configure error(libqt3 detection)
Sean 'Shaleh' Perry wrote: unless you have libqt-mt-devel or whatever your dist calls it the configure script won't find it. Yep, like I said, I have all the development files installed as well. (libqt3-devel-3.0.4 package). I also jsut noticed that someone has filed a bug on the same problem at bbconf.sf.net. you are missing the point. libqt3-devel is NOT libqt3-mt-devel. Their configure script expects you to have installed the mt lib and devel. OK, I see..Hm.. So there should be a package named libqt3-mt-devel somewhere, or libqt3-mt ? That's strange, since all my searches result in the libqt3 package, which does contain a multithreaded library (I've checked), together with a libqt3-devel package(which also contains a QThread.h file in the includes-dir, which I assume has something to do with the multithreading features?). Searching for libqt-mt-devel gives no results on Google/linux, rpmfind.net nor Mandrake's website(s). Perhaps I must go to Trolltech and get their free version and compile the whole monster it to make it work ? =) I find no indication that there is a libqt3-mt-devel rpm package anywhere. I might, of course, be totally wrong, but it seems so. Any more tips would be greatly appreciated, since I'm a bit confused right now and would like to get bbconf up and running. Thanks..
Re: bbconf 1.8 configure error(libqt3 detection)
Hmm. Since it looks like there's some sort of problem with Mandrake and/or the RPMs, I've decided to erase the packages of the QT3 library, d/l offical tarball from Trolltech and compile the whole thing myself. (w/multithread support enabled =). Perhaps this will resolve the issue. Thanks for the help. -- Øyvind S.
Yet another *tiny tiny* feature suggestion
Hi there I know many people here oppose most new feature suggestions, and I understand, I think most Blackbox users will agree when I say that we don't won't a bloated and big wm. That being said, I would still like to point out a little issue that I have encountered: When working with maximised applications there is nowhere to right click to open the Blackbox menu. So I must either resize the current application(and possibly others underneath it) or change workspaces and open the blackbox menu there(where some desktop space is visible), and launch whatever I need. How about a possibility of making a keybinding (with bbkeys) that will *only* bring the menu up (in the middle of the screen or something), nothing more. No key navigation or anything, I can use the mouse after the menu has become visible =). It would make things a bit easier and shouldn't require much code (?) to implement. --- Øyvind S.
Re: Yet another *tiny tiny* feature suggestion
Gerrit Hoetzel wrote: Why are you using that integrated blackbox menu, at all? Many people on this list want keyboard navigation, popup on key, ... Well, if you ask 10 different people how they usually work with their desktop/X environment, you are likely to get 10 different answers. It's simply a feature that would suit my needs very well(and perhaps other people's needs as well). So it couldn't hurt to post a request. Personally, I only use the blackbox menu to shutdown blackbox (and even this could be accomplished with a 'killall blackbox'). Why don't you use other means of starting an app? For my personal use I wrote a small gtk-app, which pops up (using bbkeys) and offers a list of programs among which I can choose a program to start. I hit return, the menu shuts down and the program is started. I bet it is simpler to implement the blackbox keyboard menu popup than write a dedicated launch application. Why would I want to reinvent the wheel when the very nice blackbox menu already exists ? One could develope another bbx app, which does about that and reads the default blackbox menuFile. Hmm... Why ? That's what the blackbox menu is there for :). I would consider this overkill I like my blackbox menu =)
Java dialog problem encountered in other apps
Just wanted to point out that I just experienced the dialog problem with LimeWire running JRE1.4.1 from Sun (the newest, as far as I know). Problem does not seem to be specifically related to just JBuilder, but perhaps it's worse with JBuilder than other Java apps. --- ØS.
Re: JBuilder and Blackbox-- Dialogs Way Too Big?
Roy Wood wrote: Anyone else working with JBuilder and Blackbox? With other window managers, JBuilder's dialogs are okay, but with Blackbox, they open way too big (as in much larger than the actual screen size). Any thoughts on what's up? Is BB providing some hinting for window sizes that is screwing things up? Where in the BB code should I look to fix this? -Roy Yep, I am having the same problems with BlackBox and JBuilder 7 (Personal edition, I'm a poor student =). Dialogs blow up in massive proportions, way out of the screen area. Sometimes dialogs appear totally blank, and have to be closed with the close window button. (Not sure this is a blackbox issue though, but still, can't seem to remember this problem from when I was using Sawfish+Gnome) For the record, JBuilder itself runs on JRE 1.3.1 from Sun(as far as I know). I have had problems with other Java apps using JRE 1.3.1 on Linux. JRE 1.4.1 seems a lot better on graphics and speed, but I am not sure whether the JavaVM is causing this behaviour, or the JBuilder code.
xprop and xwininfo on JBuilder dialog, running blackbox (Oversized dialogs problem)
OK, maybe this would help a little. Launched JBuilder and did xprop and xwininfo on the Tip of the Day dialog that appears first (greatly and incorrectly oversized) Blackbox version is 0.65b2, X screen resolution is 1024x768 (24bit). I did not move, resize or touch anything before doing these commands. xprop on oversized Tip of the Day-dialog: _BLACKBOX_ATTRIBUTES(_BLACKBOX_ATTRIBUTES) = 0x50, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x0 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 WM_TRANSIENT_FOR(WINDOW): window id # 0x1800021 _MOTIF_WM_MESSAGES(ATOM) = _MOTIF_WM_OFFSET WM_PROTOCOLS(ATOM): protocols _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x6, 0x, 0x1, 0x3, 0x4ff82610 WM_CLIENT_LEADER(WINDOW): window id # 0x1800021 WM_LOCALE_NAME(STRING) = no WM_CLASS(STRING) = AWTdialog, VendorShell WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0x1800021 WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 278, 241 program specified size: 1054 by 743 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = gandalf.zeo-underground WM_NAME(STRING) = Tip of the Day xwininfo on oversized Tip of the Day dialog: xwininfo: Window id: 0x1800026 Tip of the Day Absolute upper-left X: 278 Absolute upper-left Y: 241 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1054 Height: 743 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: yes Map State: IsViewable Override Redirect State: no Corners: +278+241 --308+241 --308--216 +278--216 -geometry 1054x743+277+220 --- ØS.
Testing the JBuilder (java?) oversized dialog problem with other WMs
Hi again Just tested JBuilder with twm and then Sawfish, and the oversized dialog box problem never happened, so I'm pretty sure that the problem is Blackbox-JavaVM/JBuilder related. Here are the results of xprop and xwininfo under twm (exactly same situation/dialog as before) (I have not checked for any differences here, I'm a newbie when it comes to the inner workings of the X window system) xprop on JBuilder dialog (correctly sized) using twm: WM_STATE(WM_STATE): window state: Normal icon window: 0x0 WM_TRANSIENT_FOR(WINDOW): window id # 0xc00021 _MOTIF_WM_MESSAGES(ATOM) = _MOTIF_WM_OFFSET WM_PROTOCOLS(ATOM): protocols _MOTIF_WM_MESSAGES, WM_DELETE_WINDOW _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x6, 0x, 0x1, 0x3, 0x0 WM_CLIENT_LEADER(WINDOW): window id # 0xc00021 WM_LOCALE_NAME(STRING) = no WM_CLASS(STRING) = AWTdialog, VendorShell WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. window id # of group leader: 0xc00021 WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 321, 234 program specified size: 506 by 272 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = gandalf.zeo-underground WM_NAME(STRING) = Tip of the Day xwininfo on JBuilder dialog (correctly sized) using twm: xwininfo: Window id: 0xc00025 Tip of the Day Absolute upper-left X: 323 Absolute upper-left Y: 257 Relative upper-left X: 0 Relative upper-left Y: 21 Width: 506 Height: 272 Depth: 24 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: yes Map State: IsViewable Override Redirect State: no Corners: +323+257 -195+257 -195-239 +323-239 -geometry 506x272+321+234 --- ØS.
Re: Testing the JBuilder (java?) oversized dialog problem with other WMs
OK, here's what I've done: * Applied verbose patch and enabled debugging in blackbox (perhaps I shouldn't have done that ?) * Started X with nothing but blackbox (Directed output from blackbox to file (both STDERR and OUT)) * Opened an aterm * Launched JBuilder (with personal settings file deleted = default vendor setup) * Exit X windows (from blackbox menu) The dialog was oversized and also (strangely) refused to be manually resized back to normal/minimally wrapped size. I stress again that this was with default jbuilder setup. (JBuilder did not have any chance to save previous settings, since I renamed the config file) I confirm that the settings were reset. The resulting output from blackbox is attached to this email. --- ØS bboutput.gz Description: application/gzip
Re: additional verbosity
Sean 'Shaleh' Perry wrote: Ok, to further track this down, I added a new print much earlier in the process. This is the absolute earliest that blackbox is aware of the window and 100% could have done nothing to affect it. No X calls have been made on the client's behalf at this point. Apply it on top of the previous patch or without it, they are independent. Tried to apply patch, it asked for what file to patch. Sorry, but I have very little experience in using the patch command. Perhaps it's Blackbox.cc ? Some patch output seemed to indicate this.
BlackBox 0.65alpha8 death after 30-35 hours of continuous usage
Hi, Just posting a little issue I have with BlackBox, just to see if anyone else is having similar problems. It concerns version 0.65alpha8: After about 30-35 hours of operation (samme X session), BlackBox suddenly dies for no obvious reason, and thus X exits = I lose unsaved work etc etc etc. Is this some kind of memleak problem ? I am not experienced with C++ so I wouldn't know, but something is going from good - bad in the course of those 30 hours, and in the end, Blackbox chooses to end its life. I would like BlackBox to live happily ever after (install). =). This has now happened to me 3 or 4 times. If someone has any debug tips or anything, I will certainly try those, if it helps. (probably does) I know of a tool called gdb, but I have no idea how to use it ;). Also, i don't see any core files anywhere, but I believe that coredumps are disabled in default Mandrake config for normal users ?? Is this right ?? How do I enable coredumps ? My system is basically an original Mandrake 8.2 installation, with certain upgrades. Regards, Øyvind Stegard
Re: BlackBox 0.65alpha8 death after 30-35 hours of continuous usage
Derek Cunningham wrote: On Mon, Jun10,02 20:58, Øyvind Stegard wrote: Hi, snip If someone has any debug tips or anything, I will certainly try those, if it helps. snip Recommendation: Don't let your blackbox session kill your work. I have this in my .xinitrc: blackbox xterm This way, if blackbox exits... my work is fine... it's not until 'xterm' exists that my X session is over. Also, I've run alpha8 for more than 30 hours without a problem, what apps are you running? DC The apps I usually run are: lots of aterms, JBuilder6, Mozilla 1.0, LimeWire (java apps with j2sdk1.4), GAIM, bbsmount, bbkeys, bbpager, some dockapps (wmitime, wmsmixer and another one for controlling xmms), XMMS and The Gimp. Oh, and Emacs .. and probably some more I have forgotten... These apps are running most of the time.
Re: BlackBox 0.65alpha8 death after 30-35 hours of continuous us
Sean 'Shaleh' Perry wrote: On 10-Jun-2002 Øyvind Stegard wrote: Hi, Just posting a little issue I have with BlackBox, just to see if anyone else is having similar problems. It concerns version 0.65alpha8: After about 30-35 hours of operation (samme X session), BlackBox suddenly dies for no obvious reason, and thus X exits = I lose unsaved work etc etc etc. Is this some kind of memleak problem ? I am not experienced with C++ so I wouldn't know, but something is going from good - bad in the course of those 30 hours, and in the end, Blackbox chooses to end its life. I would like BlackBox to live happily ever after (install). =). I suspect something else is happening. You list Java, Mozilla and GAIM in your application list -- all three of these seem to aggravate bugs in blackbox. What you want to do is this: first, build blackbox with debugging information for gdb. When you run configure use this command line as a base -- CXXFLAGS=-g -O2 ./configure. Add any --prefix or other flags you need. to enable cores run this before you login -- 'ulimit -c unlimited'. It is VERY important that this happens before blackbox is started. try to save blackbox's output to a file, I try to add messages around known crash points. When you have a crash and a core is generated the useful information is obtained with this command -- gdb /path/to/blackbox /path/to/core. Once gdb is running the command to give it is 'bt' which stands for back trace. This will tell us where you were in the code when a crash occured. Also try to be observant of the window manager when it crashes. What were you doing right before the crash? What was the last action you did? Currently a major source of headaches is switching workspaces while any one of the 3 applications you listed is active. Unfortunately I do not run Java apps or GAIM so I find debugging this a little difficult. Brad and xOr are currently working on pieces of this puzzle. We hope to have it solved soon. I can be fairly confident in saying that time is not the problem here it is more likely known bugs that are getting triggered. OK, it is confirmed that TIME is NOT an issue here, like you said. It was just the impression I had, caused by coincidences. Just experienced another crash when writing this reply =), as a matter of fact. Like you said, it occured just after I switched desktops. To eliminate some more factors: Mozilla and Gaim were the only two apps running now. One of them is triggering something, when switching desktops. I'll try and build blackbox with debugging, but the bug(s) is really quite hard to reproduce. Like I've said, I have worked for like 30 hours and switching desktops without it ever occuring. I'll also redirect blackbox output to file..
Re: BlackBox 0.65alpha8 death after 30-35 hours of continuous us
Jamin W. Collins wrote: On Mon, 10 Jun 2002 23:34:45 +0200 Øyvind Stegard [EMAIL PROTECTED] wrote: OK, it is confirmed that TIME is NOT an issue here, like you said. It (snip) some more factors: Mozilla and Gaim were the only two apps running now. One of them is triggering something, when switching desktops. Just a gut reaction, but I would guess that it's probably Gaim. I use Mozilla (Debian testing's 0.9.9) on a fairly regular basis (as I suspect a few other here do also). Gaim seems to be the wild card. Again, just a gut reaction. Yeah, makes sense, gaim opens windows on many different workspaces (if someone sends you a message, the window pops up in the workspace you are currently in), and generally use many windows, on many different workspaces. Also, GAIM seems to me quite buggy in itself.
Workspace change crash ( ....death after 30-35 hours of contin.....)
I have managed to crash blackbox on workspace change and gotten a core. Gaim seems to be in the clear, since I was not running GAIM this time.. I managed to crash blackbox by randomly and fast changing between all workspaces. (by keyboard shortcuts) Java and mozilla was running. This is what I did afterwards: $ gdb /usr/local/bin/blackbox ~/core gdb reports that program was terminated by signal 6, aborted. (gdb) bt #0 0x401b6621 in kill () from /lib/libc.so.6 #1 0x401b6425 in raise () from /lib/libc.so.6 #2 0x401b7a53 in abort () from /lib/libc.so.6 #3 0x401afe12 in __assert_fail () from /lib/libc.so.6 #4 0x0806e7e4 in BScreen::changeWorkspaceID (this=0x80c2ee8, id=0) at Workspace.hh:79 #5 0x08090106 in Blackbox::process_event (this=0xb730, e=0xb690) at blackbox.cc:660 #6 0x0804d50f in BaseDisplay::eventLoop (this=0xb730) at BaseDisplay.cc:299 #7 0x080944af in main (argc=1, argv=0xb944) at main.cc:160 #8 0x401a4280 in __libc_start_main () from /lib/libc.so.6 Anything else I can do to help, please let me know, and I'll try it.
Re: Workspace change crash ( ....death after 30-35 hours of cont
Sean 'Shaleh' Perry wrote: On 10-Jun-2002 Øyvind Stegard wrote: I have managed to crash blackbox on workspace change and gotten a core. Gaim seems to be in the clear, since I was not running GAIM this time.. I managed to crash blackbox by randomly and fast changing between all workspaces. (by keyboard shortcuts) Java and mozilla was running. yep, sounds like the other reports. What seems to be at the core of it is the window's settings are not getting synced with its state. It seems like a general bug, I've done some testing (i can reproduce the bug almost instantly now): Run with NO windows open except bbsmount and bbpager + some dockapps: * Randomly and quickly change workspace: No crash, rock solid. Run with an aterm(or xterm) open on one of the workspaces: * Hammer the workspace change keyboard shortcut: Boom, crash after a few seconds of wild workspace-change west. Run with only mozilla: * Same as with the terminal ... and so on... leading me to the conclusion that the bug is probably not directly affiliated with any special app, just all apps that have a blackbox window. How to easily reproduce bug: * Assign keyboard shortcut to workspace change, like mod+1,2,3,4,5 or 6 to change between all workspaces. * Open up one or more regular windows (any app) * Change workspace quickly, it's very effective to press several of the 1,2,3... keys at the same time, this really makes blackbox crash fast in my system.
Feature request: Position locking of maximised windows
Hi, Just a simple feature request: How about an option that will keep maximised windows locked in position so that they cannot be accidentally moved ? Regards, Øyvind Stegard
Re: Feature request: Position locking of maximised windows
Sean 'Shaleh' Perry wrote: On 30-May-2002 yvind Stegard wrote: Hi, Just a simple feature request: How about an option that will keep maximised windows locked in position so that they cannot be "accidentally" moved ? Regards, yvind Stegard why not just stop accidentally moving them (-: Well, you could put it like that =). But I would look at this as logical behaviour. When a window is maximised, you seldom want it out of place/moved in this state, you want the whole thing visible and as big as possible. When, for instance, you shade maximised windows and such, it sometimes happens that you move it a little by accident. Placing a lock on the position would be nice, at least as optional behaviour. Maybe it will happen, who knows ;). Regards, . Stegard.
Re: Feature request: Position locking of maximised windows
Es Bee Ex wrote: On Thu, 30 May 2002 02:51:24 +0200 yvind Stegard [EMAIL PROTECTED] wrote: Just a simple feature request: How about an option that will keep maximised windows locked in position so that they cannot be "accidentally" moved ? This is an idea I had too, but two other, more user-friendly things could take its place from my point of view: disable the Maximize bit when you move a window(then you can just quickly re-maximize it), OR allow maximized windows to be snapped to the strut/screen edges(allows you to quickly pop the window back in place after you accidentally move it). This also seems like to good solutions to the problem, I agree.
