Re: shade, maximize, unmaximize prob.
On 28-May-2002 Ryan Harris wrote: > Oh...that's nasty. Remind me not to do that again. Blackbox didn't like > that at all. :) > > On Tue, 2002-05-28 at 02:10, Wilbert Berendsen wrote: >> Hi all, >> >> in CVS (may 27) is a little bug concerning maximize and shade. >> >> To reproduce: >> - open xterm >> - shade it >> - maximize it (it opens fully and maximizes, looks OK) >> - UNmaximize it (the window has zero height, but is NOT shaded anymore :-) >> >> To me it would be normal that after unmaximizing the shaded window would >> remain unshaded (i.e. Maximizing toggles shade off). >> >> OTOH, when shading a maximized window and then unmaximizing it, it remains >> shaded, which is IMHO the correct behaviour. >> Brad recently reworked the handling of window dimensions. This had the advantage of simplifying many sections of code. However there are some sections of code that used to work and no have subtle flaws. This appears to be one of them from your description, Scott Furt pointed out another one earlier today. This is the point of the alpha series. To try out new code and to get plenty of feedback from it. Brad and I do not use the same groups of software nor do we use the window manager in the same way. Only by having as many different people and different uses as possible can we be sure to have a stable, robust window manager. Things like this with clearly defined causes are absolutely great. Wilbert, I noticed you submitted this to sf.net. I really appreciate that. Thanks. I am still trying to get this list to allow mail from the sf.net bug Tracker. That way every submitted bug and response will appear on this list. That should help cut down on the duplicate posts to here and the tracker.
Re: shade, maximize, unmaximize prob.
Oh...that's nasty. Remind me not to do that again. Blackbox didn't like that at all. :) On Tue, 2002-05-28 at 02:10, Wilbert Berendsen wrote: > Hi all, > > in CVS (may 27) is a little bug concerning maximize and shade. > > To reproduce: > - open xterm > - shade it > - maximize it (it opens fully and maximizes, looks OK) > - UNmaximize it (the window has zero height, but is NOT shaded anymore :-) > > To me it would be normal that after unmaximizing the shaded window would > remain unshaded (i.e. Maximizing toggles shade off). > > OTOH, when shading a maximized window and then unmaximizing it, it remains > shaded, which is IMHO the correct behaviour. > > Bye, > > -- > Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/) > http://www.stoppoliceware.org/ http://digitalspeech.org/ > -- Ryan Patrick Harris (maxter) [EMAIL PROTECTED] University of Michigan EECS http://maxtersbox.net
shade, maximize, unmaximize prob.
Hi all, in CVS (may 27) is a little bug concerning maximize and shade. To reproduce: - open xterm - shade it - maximize it (it opens fully and maximizes, looks OK) - UNmaximize it (the window has zero height, but is NOT shaded anymore :-) To me it would be normal that after unmaximizing the shaded window would remain unshaded (i.e. Maximizing toggles shade off). OTOH, when shading a maximized window and then unmaximizing it, it remains shaded, which is IMHO the correct behaviour. Bye, -- Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/) http://www.stoppoliceware.org/ http://digitalspeech.org/
Re: Timing and transient windows
On 28-May-2002 Scott Furt wrote: > I remember there was discussion about transient windows > that were created/destroyed very quickly hanging around. > > I just experienced this with ROX. I was copying a very > small text file to a sub-dir, and the "Copying..." window > seems to have hung around as "Unnamed". All efforts at > killing the window fail. > > It is also similar to the problem i've been having with > GNOME apps' transient windows not going away. > > "Close" is disabled, "Kill Client" doesnt work, and > "xkill" will not remove the window. > > If it helps, i have been changing styles around pretty > frequently in the past 20 minutes... i'm trying to delete > some styles i don't like, so i've been going back/forth > between them. > Brad is working on this currently, it has to do with his recent patches.
Timing and transient windows
I remember there was discussion about transient windows that were created/destroyed very quickly hanging around. I just experienced this with ROX. I was copying a very small text file to a sub-dir, and the "Copying..." window seems to have hung around as "Unnamed". All efforts at killing the window fail. It is also similar to the problem i've been having with GNOME apps' transient windows not going away. "Close" is disabled, "Kill Client" doesnt work, and "xkill" will not remove the window. If it helps, i have been changing styles around pretty frequently in the past 20 minutes... i'm trying to delete some styles i don't like, so i've been going back/forth between them. Screenshot: http://furt.com/blackbox/mlist_shots/transient-not-closing.jpg
Re: New styles & screenshots
> > I *HATE* windows for that... g. > > I uploaded all the styles it from my linux machine, then > downloaded them with windows, edited the comments and > re-uploaded them. > > Let me go fix it myself too. let's all point at the Windows monkey (-: No worries Scott, many of us have had that bite us before. I used to work at an ISP and our web monkey would do that all the time and mess up my cgis. When reading the blackbox errors on the console i could not see the ^M. I wanted to see all of the errors and piped them into a file and restarted. That was when I noticed it. A parse error on #ff just seemed a little odd, you know.
Re: New styles & screenshots
Sean 'Shaleh' Perry wrote: The more I look at this the more I think it is a color map issue. What res do you run in? >>> >>>1152x864 >>>color depth: 16 >> >>1280x960 16 here. Most odd. Looking into this some more. >> >>When I load bbconf 1.6 up and try to load your style all of the colors show >>up >>as black. Same happens when I load the style in blackbox. > > > It gets WEIRDER. The problem is actually this: > > BColor::allocate: color parse error: "#ff^M" > > I ran your style through fromdos and it works just fine. As I was afraid, it > is way to bright for me though. > > Looks like blackbox should strip the strings and so should bbconf. I *HATE* windows for that... g. I uploaded all the styles it from my linux machine, then downloaded them with windows, edited the comments and re-uploaded them. Let me go fix it myself too.
Re: New styles & screenshots
xOr wrote: > On Mon, May 27, 2002 at 07:19:30PM -0700, Sean 'Shaleh' Perry wrote: > >>On 28-May-2002 Scott Furt wrote: >> >>>Sean 'Shaleh' Perry wrote: >>> >Very strange, i created with bbconf 1.4 and am running blackbox a7 >(from cvs 05/25). i also have bsetbg 1.12 > >Was it any specific styles that gave you prob's? I grabbed clouded mind (I have a thing for blue themes). The more I look at this the more I think it is a color map issue. What res do you run in? >>> >>>1152x864 >>>color depth: 16 >> >>1280x960 16 here. Most odd. Looking into this some more. >> >>When I load bbconf 1.6 up and try to load your style all of the colors show up >>as black. Same happens when I load the style in blackbox. > > > all? if they are parent-relative, then they are likely to be black in > the editor since they have no value. > > xOr i purposely set all parentRelative colors to white and text to blank, so that at a glance when flipping thru the bbconf tabs, i can tell that its parentrelative. does it work OK with blackbox itself?
Re: New styles & screenshots
>>> The more I look at this the more I think it is a color map issue. What res >>> do >>> you run in? >> >> 1152x864 >> color depth: 16 > > 1280x960 16 here. Most odd. Looking into this some more. > > When I load bbconf 1.6 up and try to load your style all of the colors show > up > as black. Same happens when I load the style in blackbox. It gets WEIRDER. The problem is actually this: BColor::allocate: color parse error: "#ff^M" I ran your style through fromdos and it works just fine. As I was afraid, it is way to bright for me though. Looks like blackbox should strip the strings and so should bbconf.
Re: New styles & screenshots
On Mon, May 27, 2002 at 07:19:30PM -0700, Sean 'Shaleh' Perry wrote: > On 28-May-2002 Scott Furt wrote: > > Sean 'Shaleh' Perry wrote: > >>>Very strange, i created with bbconf 1.4 and am running blackbox a7 > >>>(from cvs 05/25). i also have bsetbg 1.12 > >>> > >>>Was it any specific styles that gave you prob's? > >> > >> > >> I grabbed clouded mind (I have a thing for blue themes). > >> > >> The more I look at this the more I think it is a color map issue. What res > >> do > >> you run in? > > > > 1152x864 > > color depth: 16 > > 1280x960 16 here. Most odd. Looking into this some more. > > When I load bbconf 1.6 up and try to load your style all of the colors show up > as black. Same happens when I load the style in blackbox. all? if they are parent-relative, then they are likely to be black in the editor since they have no value. xOr -- I am damn unsatisfied to be killed in this way. msg07052/pgp0.pgp Description: PGP signature
Re: New styles & screenshots
On 28-May-2002 Scott Furt wrote: > Sean 'Shaleh' Perry wrote: >>>Very strange, i created with bbconf 1.4 and am running blackbox a7 >>>(from cvs 05/25). i also have bsetbg 1.12 >>> >>>Was it any specific styles that gave you prob's? >> >> >> I grabbed clouded mind (I have a thing for blue themes). >> >> The more I look at this the more I think it is a color map issue. What res >> do >> you run in? > > 1152x864 > color depth: 16 1280x960 16 here. Most odd. Looking into this some more. When I load bbconf 1.6 up and try to load your style all of the colors show up as black. Same happens when I load the style in blackbox.
Re: New styles & screenshots
Sean 'Shaleh' Perry wrote: >>Very strange, i created with bbconf 1.4 and am running blackbox a7 >>(from cvs 05/25). i also have bsetbg 1.12 >> >>Was it any specific styles that gave you prob's? > > > I grabbed clouded mind (I have a thing for blue themes). > > The more I look at this the more I think it is a color map issue. What res do > you run in? 1152x864 color depth: 16
Re: New styles & screenshots
> > Very strange, i created with bbconf 1.4 and am running blackbox a7 > (from cvs 05/25). i also have bsetbg 1.12 > > Was it any specific styles that gave you prob's? I grabbed clouded mind (I have a thing for blue themes). The more I look at this the more I think it is a color map issue. What res do you run in?
Re: New styles & screenshots
Sean 'Shaleh' Perry wrote: > On 28-May-2002 Scott Furt wrote: > >>If anyone's interested, i posted up a few new styles that >>i did this weekend. >> >>Shots (links to download are on the page next to the thumbnail) >>http://furt.com/screenshots/index.php?only=blackbox_styles >> >>Broken-down directory structure: >>http://furt.com/blackbox/styles/ > > I may be a little daft, but um how did you use those styles? Neither bbconf > nor blackbox will parse them. It seems to not like the '#ff' style the > usual way is rgb:ff/ff/ff. > > Also do not specify a path to bsetbg in your styles, blackbox should find it in > the path or the user should edit the style. Very strange, i created with bbconf 1.4 and am running blackbox a7 (from cvs 05/25). i also have bsetbg 1.12 Was it any specific styles that gave you prob's?
Re: New styles & screenshots
On 28-May-2002 Scott Furt wrote: > If anyone's interested, i posted up a few new styles that > i did this weekend. > > Shots (links to download are on the page next to the thumbnail) > http://furt.com/screenshots/index.php?only=blackbox_styles > > Broken-down directory structure: > http://furt.com/blackbox/styles/ I may be a little daft, but um how did you use those styles? Neither bbconf nor blackbox will parse them. It seems to not like the '#ff' style the usual way is rgb:ff/ff/ff. Also do not specify a path to bsetbg in your styles, blackbox should find it in the path or the user should edit the style.
Re: Moving shaded windows
On 27-May-2002 Scott Furt wrote: > Hello, i'm running blackbox a7, and i noticed a few oddities > when dragging shaded windows around with the mouse: > > With freshly-shaded windows, dragging by the titlebar is fine. > > However, with some windows that have been shaded for a while, > when i grab the titlebar to drag them, an outline box shows > up the size of the window's un-shaded dimensions. > > If i unshade/shade, then move the window, it's fine again, > the outline box is the size of the title-bar. > > I haven't noticed any pattern to the odd behaviour, other > than it seems to happen to shaded windows that i haven't > touched in a few minutes. > shade a window, change your style and the window border is drawn full size. It seems to happen if a reconfigure is called for by something. Please submit this on sf.net. Should be fairly easy to fix.
New styles & screenshots
If anyone's interested, i posted up a few new styles that i did this weekend. Shots (links to download are on the page next to the thumbnail) http://furt.com/screenshots/index.php?only=blackbox_styles Broken-down directory structure: http://furt.com/blackbox/styles/
Moving shaded windows
Hello, i'm running blackbox a7, and i noticed a few oddities when dragging shaded windows around with the mouse: With freshly-shaded windows, dragging by the titlebar is fine. However, with some windows that have been shaded for a while, when i grab the titlebar to drag them, an outline box shows up the size of the window's un-shaded dimensions. If i unshade/shade, then move the window, it's fine again, the outline box is the size of the title-bar. I haven't noticed any pattern to the odd behaviour, other than it seems to happen to shaded windows that i haven't touched in a few minutes. (I cannot grab a screenshot, becuase when i hold the mouse down, the term. won't time correctly "sleep x && import ..." doesnt work.) Has anyone else experienced this? It's no biggie, just a strange cosmetic effect. (It seems to happen most often to terms and ROX windows -- but that's probably becuase i've always got ROX/terms open)
Re: bbkeys and dual head
* Greg Gilbert ([EMAIL PROTECTED]) 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. This is now fixed in the bbkeys cvs. children weren't receiving the proper DSIPLAY to open on. Greg
Re: bbconf 1.6 hereby released into the wild...
On 27-May-2002 Sean 'Shaleh' Perry wrote: > On 27-May-2002 Jason 'vanRijn' Kasper wrote: >> Right. Due to the overwhelmingly non-existent response to my previous >> bbconf 1.6-pre e-mail, I'm hereby releasing bbconf version 1.6. It has >> many, many wonderful changes with many, many wonderful new features and >> abilities and many, many wonderful enhancements! I'll paste the >> relevant portion from the ChangeLog below >> >> Do be a good chap/chapette and go to http://bbconf.sourceforge.net and >> download the little guy! He's lonely and has VERY good manners!! >> >> > > here's a yummy one for ya. Your autotool shell scripts use /bin/ksh not > /bin/sh. So you fail to build on any system witout ksh. ok, false alarm. The configure scripts ripped from kde attempt to use ksh and then bash if ksh is not found. I removed ksh while the build was going and was left with source that could not even make clean because of the explicit SHELL=/bin/ksh. But if you do not have ksh installed there is no problem. It would be nice if kde was not letting feelings get in the way and only use /bin/sh like a good portable developer, but oh well.
Re: bbconf 1.6 hereby released into the wild...
On 27-May-2002 Jason 'vanRijn' Kasper wrote: > Right. Due to the overwhelmingly non-existent response to my previous > bbconf 1.6-pre e-mail, I'm hereby releasing bbconf version 1.6. It has > many, many wonderful changes with many, many wonderful new features and > abilities and many, many wonderful enhancements! I'll paste the > relevant portion from the ChangeLog below > > Do be a good chap/chapette and go to http://bbconf.sourceforge.net and > download the little guy! He's lonely and has VERY good manners!! > > here's a yummy one for ya. Your autotool shell scripts use /bin/ksh not /bin/sh. So you fail to build on any system witout ksh.
bbconf 1.6 hereby released into the wild...
Right. Due to the overwhelmingly non-existent response to my previous
bbconf 1.6-pre e-mail, I'm hereby releasing bbconf version 1.6. It has
many, many wonderful changes with many, many wonderful new features and
abilities and many, many wonderful enhancements! I'll paste the
relevant portion from the ChangeLog below
Do be a good chap/chapette and go to http://bbconf.sourceforge.net and
download the little guy! He's lonely and has VERY good manners!!
ChangeLog
- version 1.6::
- fixed layout issues so we now fit into 800x600 screen size, yay!
[vanRijn]
- using the proper QPaintDevice::x11AppDisplay() rather than
qt_xdisplay(),
and RootWindow(QPaintDevice::x11AppDisplay(),
QPaintDevice::x11AppScreen())
instead of qt_xrootwin() throughout the project now... (thanks for
the Qt-down-low, nyz! =:)
[vanRijn]
- now using blackbox's pid to ask him to reconfigure rather than doing
'killall -HUP blackbox', which at best is undesirable and at worst
is VERY un-neighborly (it's not nice to init 0 SCO boxen
unannounced). We now use the _BLACKBOX_PID atom on the root window
to get the pid and kill -HUP it. Yay!
[vanRijn]
- fixing installation directory for bbconf's plugins. Previously, we
stuck these in $(datadir). These now go in
$(prefix)/lib/bbconf/plugins.
[vanRijn]
- 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]
What are you waiting for??? GO GET IT!!!
--
,-//
| 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: more q. (also: Re: NLS questions AND updated nl_NL nls)
> > Yes, I was also amazed about the readability and compactness of the > implementation. Very nice work! > indeed I am very pleased. > regarding .blackborc style override support, is this discussed somewhere > on another list, or just irc :) maybe I can help. > btw blackbox is coming along very nicely (love the alt-tab feature). > it was not discussed in public, no. We hashed it out on irc and a little on a separate -devel list between Brad, xOr and myself. The work is tabled until after 0.65.0 is released and probably until after some of the work for 0.70.0 is begun. When time comes, we will welcome the help. > Question: ROX-Filer current CVS uses a pseudo root window when you enable > pinboard icons, which does not work well with Blackbox. Can you (or other > guys) verify if this is standard behaviour? (ROX adheres very well to > standards on different points, like SOAP, MIME-info etc.) Will blackbox as > well support pseudo root windows like ROX's? (I asked this as well on the > rox-devel list.) > run xprop on the psuedo root. If it sets a few NET_WM atoms then yes we will support it. This is the same style of window that KDE and GNOME use to give desktop icons. Right now blackbox can not tell it from another window but it will eventually be able to see the "I am a desktop window, leave me alone".
Re: BlackBox eats 99% CPU after runing a while under VNC
On Mon, May 27, 2002 at 10:11:04AM +0200, Ciprian Popovici wrote: > Quoting Sean 'Shaleh' Perry <[EMAIL PROTECTED]>: > > I have been running this code off and on since Saturday morning and it > > is still behaving. I need more help tracking this down. > > If you have any suggestions I would be glad to try them. Maybe a way to > cause a core dump? when its using 100% cpu, try using this: strace -p so then we can see where it is stuck, hopefully. xOr -- I am damn unsatisfied to be killed in this way. msg07038/pgp0.pgp Description: PGP signature
Re: Gnome (GTK?) frames will not close
On Mon, 27 May 2002 08:13:18 +0100 Martin Rowe <[EMAIL PROTECTED]> wrote: > On Monday 27 May 2002 7:40 am, Martin Egholm Nielsen wrote: > > Hi Sean, > > The weird is that the frame is still "active" afterwards - > > i.e. one can right-click it and pull up the menu, but it > > just will not close - not even with xkill. And the > > application is _not_ running anymore according to ps. > Just run into that with gtop. It only seems to happen if closing with the > titlebar X button - choosing File...Exit does the job properly. I am getting the same behavior with the packet sniffer Ethereal. Quitting from the menu works fine but the X button leaves the frame. -- Joseph Applegate (SB-X) [EMAIL PROTECTED] | [EMAIL PROTECTED] UIN: 9788597
more q. (also: Re: NLS questions AND updated nl_NL nls)
Hoi Sean, Op Mon, 27 May 2002 00:19:04 -0700 (PDT) schreef "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]>: > yeah someone from the openbox team implemented the algorithm we talked > about late last year. We now make a list of empty regions and choose > the right region based on a sort function. The code is very nice and > clean. This was by far one of the ugliest sections of blackbox. Yes, I was also amazed about the readability and compactness of the implementation. Very nice work! regarding .blackborc style override support, is this discussed somewhere on another list, or just irc :) maybe I can help. btw blackbox is coming along very nicely (love the alt-tab feature). Question: ROX-Filer current CVS uses a pseudo root window when you enable pinboard icons, which does not work well with Blackbox. Can you (or other guys) verify if this is standard behaviour? (ROX adheres very well to standards on different points, like SOAP, MIME-info etc.) Will blackbox as well support pseudo root windows like ROX's? (I asked this as well on the rox-devel list.) Kind regards, Wilbert -- Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/) http://www.stoppoliceware.org/ http://digitalspeech.org/
Re: Gnome (GTK?) frames will not close
On 27-May-2002 Martin Egholm Nielsen wrote: > Hi Sean, > > Neverness posted that he experienced a problem with closing > gtop - the frame remained, though with the content cleared. > The same problem arises with e.g. gcolorsel and ickle (GTK > app.). > The weird is that the frame is still "active" afterwards - > i.e. one can right-click it and pull up the menu, but it > just will not close - not even with xkill. And the > application is _not_ running anymore according to ps. > > I know you don't have Gnome installed, but then Ickle may be > a possible test-app. (http://ickle.sourceforge.net/) yep, ickle works and I can see the bug happen. This only occurs if you try to close ickle while still online, if you go off line then close it if quits just fine. Brad and I are looking into the recent problems his patch has caused and hopefully everything will be happy again soon.
Re: BlackBox eats 99% CPU after runing a while under VNC
Quoting Sean 'Shaleh' Perry <[EMAIL PROTECTED]>: > I have been running this code off and on since Saturday morning and it > is still behaving. I need more help tracking this down. If you have any suggestions I would be glad to try them. Maybe a way to cause a core dump? Ciprian Popovici
Re: New bbtool
On Mon, 27 May 2002 07:15:26 +0100 Martin Rowe <[EMAIL PROTECTED]> wrote: > 0.2 works better - I can now see the minutes changing, rather than > stuck at 24. Cheers. > > Regards, Martin Yeah, I can't believe I did that. It's okay, I have a long history of making retarded mistakes :)
Re: BlackBox eats 99% CPU after runing a while under VNC
Quoting "Jamin W. Collins" <[EMAIL PROTECTED]>: > I believe Shaleh asked this a while ago, but why are you killing and > restarting BB? No particular reason. I did it, so I thought it would be worth mentioning. Ciprian Popovici
Re: NLS questions AND updated nl_NL nls
On 27-May-2002 Wilbert Berendsen wrote: > Hoi Sean, > > Op Sun, 26 May 2002 15:16:04 -0700 (PDT) > schreef "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]>: > >> > maybe I can help contruct some things in the future (esp. a nice >> > smartplacement?) >> > >> >> actually, we just got one (-: look at workspace.cc. > > Ohhh!! Awesome!! Really, I didn't know, but I noticed the speed of the > window placement in the latest alpha series. > yeah someone from the openbox team implemented the algorithm we talked about late last year. We now make a list of empty regions and choose the right region based on a sort function. The code is very nice and clean. This was by far one of the ugliest sections of blackbox. > and BTW: this is a little patch to update the Dutch NLS. I made some menu > labels a bit shorter, for people running on lowres screens. Also added > ClickRaise translation. > will add this in a day or two.
