Re: BlackBox?
On Thu, 2001-12-13 at 00:21, Sean Alphonse wrote: > Hello. > > Are you continuing to work on blackbox? > > Thank-you for your time. > > Sean. > > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. > Who, me? Gino -- [EMAIL PROTECTED] http://www.ghazalpage.net
BlackBox?
Hello. Are you continuing to work on blackbox? Thank-you for your time. Sean. _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
Re: Blackbox allows several instances of Opera.
Actually, this happens with netscape as well. If you pass netscape the
-remote parameter so that it doesn't think it has to start a session
from scratch, and netscape is on a different workspace, you'll hit the
same problem. I do not believe it has anything to do with opera not
doing things right. I believe the error is how blackbox handles windows
(XChangeProperty to withdrawn state via setState() ) when it switches
workspaces. I think that sets the window into a state that causes it to
not received calls that it otherwise would.
On Wed, 2001-12-12 at 17:37, Christian Dysthe wrote:
> On 12 Dec 2001 14:32:15 -0500
> "Jason 'vanRijn' Kasper" <[EMAIL PROTECTED]> wrote:
>
> > I believe that I've fixed this, actually. WOOT.
>
> Does this mean that this is not really an Opera issue, or something
> that Opera should fix?
>
> --
> Christian Dysthe
> http://www.dysthe.net
> ICQ: 3945810
> Registered Linux User #228949
>
> "Everybody ought to have a Lower East Side
>in their life"
>
> -Irving Berlin-
>
--
%<--%<
Jason Kasper (vanRijn)
bash$ :(){ :|:&};:
Numbers 6:24-26
Re: Blackbox allows several instances of Opera.
On 12-Dec-2001 Christian Dysthe wrote: > On 12 Dec 2001 14:32:15 -0500 > "Jason 'vanRijn' Kasper" <[EMAIL PROTECTED]> wrote: > >> I believe that I've fixed this, actually. WOOT. > > Does this mean that this is not really an Opera issue, or something > that Opera should fix? > Sounds like shoddy coding on Opera's part to me. That said, vanR's fix will likely go in.
Re: Blackbox allows several instances of Opera.
On 12 Dec 2001 14:32:15 -0500 "Jason 'vanRijn' Kasper" <[EMAIL PROTECTED]> wrote: > I believe that I've fixed this, actually. WOOT. Does this mean that this is not really an Opera issue, or something that Opera should fix? -- Christian Dysthe http://www.dysthe.net ICQ: 3945810 Registered Linux User #228949 "Everybody ought to have a Lower East Side in their life" -Irving Berlin-
Re: acroread hangs black box
On Tue, 13 Nov 2001 22:27:35 -0500
Marco Fonseca <[EMAIL PROTECTED]> wrote:
> I thought I saw someone mention something about a patch to fix adobe
> acrobat hanging blackbox. Anyone know where I could get this?
First I've heard of this issue & I've been using their pdf reader pretty much forever
without the slightest hint of problems. The setups:
slackware 8.0 {
XFree86 4.1.0
blackbox 0.61.1
acroread 4.05 (custom slackpack brewed from "linux-ar-405.tar.gz")
}
redhat 6.2 {
XFree86 3.3.6
blackbox 0.61.1
acroread 4.05 (rpm from rpmfind.net)
}
Assuming you've experienced troubles yourself, care to share a bit of background? (ie:
define "hang", distro, X version, etc etc)
PS: Pardon the late reply, I'm wading through a huge backlog of mail. :)
--
Registered Linux User Number 195825
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=140066
Re: Blackbox allows several instances of Opera.
> > Slightly different. I've not had a chance to look at what exactly the > difference in results is =:) > wmaker unmaps the frame after the client which should not really matter. The piece of suspect code in my mind is the event mask bb uses. Notice how wmaker is careful to preserve the existing mask and blackbox just overwrites it.
Re: Blackbox allows several instances of Opera.
Actually, wmaker's code looks like this
/* prevent window withdrawal when getting UnmapNotify */
XSelectInput(dpy, wwin->client_win,
wwin->event_mask & ~StructureNotifyMask);
XUnmapWindow(dpy, wwin->client_win);
XSelectInput(dpy, wwin->client_win, wwin->event_mask);
XUnmapWindow(dpy, wwin->frame->core->window);
..
, whereas blackbox's code is this
..
XUnmapWindow(display, frame.window);
XSelectInput(display, client.window, NoEventMask);
XUnmapWindow(display, client.window);
XSelectInput(display, client.window,
PropertyChangeMask | StructureNotifyMask |
FocusChangeMask);
Slightly different. I've not had a chance to look at what exactly the
difference in results is =:)
On Wed, 2001-12-12 at 14:41, Sean 'Shaleh' Perry wrote:
> >
> > Shaleh, please take a gander at this and see if you have any objections
> > to putting it in 61.2. The affect that this has (at least with this
> > opera situation) is that opera's state hasn't changed to Withdrawn and
> > he's now able to receive the "open a new link" message. Now, granted,
> > opera doesn't magically switch the desktop to where it is, but it does
> > get the message to open a new link and doesn't open a brand new window
> > on the current desktop
> >
> > So, again, the fix that I've come up with is as follows Window.cc
> > should have this
> >
>
> Window maker's code look just like yours vanR. I would like to know if Brad
> had a reason for the state call.
--
%<--%<
Jason Kasper (vanRijn)
bash$ :(){ :|:&};:
Numbers 6:24-26
Re: Blackbox allows several instances of Opera.
> > Shaleh, please take a gander at this and see if you have any objections > to putting it in 61.2. The affect that this has (at least with this > opera situation) is that opera's state hasn't changed to Withdrawn and > he's now able to receive the "open a new link" message. Now, granted, > opera doesn't magically switch the desktop to where it is, but it does > get the message to open a new link and doesn't open a brand new window > on the current desktop > > So, again, the fix that I've come up with is as follows Window.cc > should have this > Window maker's code look just like yours vanR. I would like to know if Brad had a reason for the state call.
Re: Blackbox allows several instances of Opera.
I believe that I've fixed this, actually. WOOT. This has annoyed me to
no end. The problem as I see it is that blackbox sets the window state
for any window not currently on the current workspace to "withdrawn". I
believe this causes opera to behave differently and not know that it
already has a window open. If you comment out line 1428 (in my blackbox
source anyway) of Window.cc, in BlackboxWindow::withdraw(void) where he
does setState(WithdrawnState);, it should fix this.
Brad, if you're reading is there any reason that this was put in?
Simply XUnmapWindow'ing windows that aren't on the current workspace
seems to work fine.
Shaleh, please take a gander at this and see if you have any objections
to putting it in 61.2. The affect that this has (at least with this
opera situation) is that opera's state hasn't changed to Withdrawn and
he's now able to receive the "open a new link" message. Now, granted,
opera doesn't magically switch the desktop to where it is, but it does
get the message to open a new link and doesn't open a brand new window
on the current desktop
So, again, the fix that I've come up with is as follows Window.cc
should have this
void BlackboxWindow::withdraw(void) {
visible = False;
iconic = False;
// setState(WithdrawnState);
XUnmapWindow(display, frame.window);
XSelectInput(display, client.window, NoEventMask);
XUnmapWindow(display, client.window);
XSelectInput(display, client.window,
PropertyChangeMask | StructureNotifyMask |
FocusChangeMask);
if (windowmenu) windowmenu->hide();
}
On Wed, 2001-12-12 at 11:33, Sean 'Shaleh' Perry wrote:
> On 12-Dec-2001 Christian Dysthe wrote:
> > Hi,
> >
> > I asked about this a while back, but got no answer. Maybe someone
> > now knows why Blackbox allows several instanses of Opera (the web
> > browser) as long as each instance is opened on different desktops?
> >
> > For instance, if I click on a link in my mailer an Opera instance is
> > opened even though another instance of Opera is running on another
> > desktop. In other WM's a click on an e-mail link switches to the
> > desktop where Opera is already running opening a window with the
> > link content, while in Blackbox one is opened on the current
> > desktop.
> >
> > I know for a fact that Opera is not designed to allow several
> > instances of itself. So why is Blackbox allowing it for this
> > application while other WM's I have tried this on (KDE, Gnome, IceWM
> > and XFce) don't?
> >
>
> That is not the wm's job. If the app wants to only allow one instance it can
> handle that. Switching workspaces (desktops) is even worse behaviour.
--
%<--%<
Jason Kasper (vanRijn)
bash$ :(){ :|:&};:
Numbers 6:24-26
Re: very minor bugs (sorry, no patches)
On 12-Dec-2001 Bill Beal wrote: > Imad <[EMAIL PROTECTED]> wrote: >> On Wed, 12 Dec 2001, Jan Schaumann wrote: >> >> > [could you trim your lines to something <80 chars/line >> > please? thanks] >> > >> > David Lawrence Ramsey <[EMAIL PROTECTED]> wrote: >> > >> > > Bug 1: Right-click on any window's titlebar to get >> > > the titlebar menu, and maximize or unmaximize the >> > > window. The titlebar menu will not be removed (but it >> > > should be). This is easier to see when unmaximizing >> > > the window; when maximizing it, the only hint that the >> > > menu still exists is that the next time you click the >> > > mouse on anything, nothing will appear to happen >> > > (since blackbox removes the menu then, but the menu is >> > > unseen since it is covered by the maximized window), >> > > but after that, it will work as expected. >> > >> > Can't reproduce the problem. >> >> I don't get this bug either. > > Here's the trick: right-click to get the titlebar menu, but > then use the maximize *button*, not the menu item, to > maximize the window. The titlebar menu will still be there, > but it'll be buried under the window. Even if you minimize > again using the button, the menu will still be there. > > It's easier to see if you try it with a very small window so > that the menu sticks out from under it, or if you have > bbkeys shortcuts to move the window around the screen w/o > using the mouse. (As soon as you change workspaces or press > a mouse button associated with a blackbox action, the menu > disappears.) > indeed. Thanks again Bill! Bill, would you please enter these two bugs into the sf.net/projects/blackboxwm bug tracker? If you have any questions or problems with the bug system please mail me directly.
Re: very minor bugs (sorry, no patches)
Imad <[EMAIL PROTECTED]> wrote: > On Wed, 12 Dec 2001, Jan Schaumann wrote: > > > [could you trim your lines to something <80 chars/line > > please? thanks] > > > > David Lawrence Ramsey <[EMAIL PROTECTED]> wrote: > > > > > Bug 1: Right-click on any window's titlebar to get > > > the titlebar menu, and maximize or unmaximize the > > > window. The titlebar menu will not be removed (but it > > > should be). This is easier to see when unmaximizing > > > the window; when maximizing it, the only hint that the > > > menu still exists is that the next time you click the > > > mouse on anything, nothing will appear to happen > > > (since blackbox removes the menu then, but the menu is > > > unseen since it is covered by the maximized window), > > > but after that, it will work as expected. > > > > Can't reproduce the problem. > > I don't get this bug either. Here's the trick: right-click to get the titlebar menu, but then use the maximize *button*, not the menu item, to maximize the window. The titlebar menu will still be there, but it'll be buried under the window. Even if you minimize again using the button, the menu will still be there. It's easier to see if you try it with a very small window so that the menu sticks out from under it, or if you have bbkeys shortcuts to move the window around the screen w/o using the mouse. (As soon as you change workspaces or press a mouse button associated with a blackbox action, the menu disappears.) -- Bill Beal [EMAIL PROTECTED] http://www.bildo.net/
Re: very minor bugs (sorry, no patches)
> > Big window, titlebar menu, "shade" -> big window shades > Now, right click titlebar menu, "maximize" (ie unmaximize) -> window > gets small, but stays shaded, as it should. However, right-clicking on > the titlebar shows that the "Shade" part in the menu is _de_selected. > That is, even though the window is shaded, BB thinks it's unshaded. > Select "Shade": window stays shaded (as BB thought it was unshaded), > "Shaded" is turned on. Once more "Shade" and it's back to normal (small > window, unshaded, menu has all the proper selections (ie none). > any which way this gets looked at the basic issue is blackbox has shaded and maximized as conflicting options. Will get fixed in the near future, but may not make it into 0.61.2.
Re: very minor bugs (sorry, no patches)
On Wed, 12 Dec 2001, Jan Schaumann wrote: > [could you trim your lines to something <80 chars/line please? thanks] > > David Lawrence Ramsey <[EMAIL PROTECTED]> wrote: > > > Bug 1: Right-click on any window's titlebar to get the titlebar menu, > > and maximize or unmaximize the window. The titlebar menu will not be > > removed (but it should be). This is easier to see when unmaximizing > > the window; when maximizing it, the only hint that the menu still > > exists is that the next time you click the mouse on anything, nothing > > will appear to happen (since blackbox removes the menu then, but the > > menu is unseen since it is covered by the maximized window), but after > > that, it will work as expected. > > Can't reproduce the problem. I don't get this bug either. > > Bug 2: Maximize a window, shade it, and unmaximize it. The window > > will unmaximize, unshade for a split second (which it shouldn't do), > > and then reshade. > > can't reproduce this either - but I see a different problem: This one is there, on both of the machines I tried it on (OpenBSD/SPARC, Linux-Mandrake/PII). I'm typing this in a maximized aterm (running PINE). Double-click on the titlebar to shade, then click the maximize icon to resize, and the window unshades for a second, then goes back to shaded. However, BlackBox sees the window as unshaded, so when I right click, shade is *not* selected. Furthermore, double-clicking to unshade does not work. (Double clicking twice fixes everything.) > Small window, right click titlebar, shade -> window is shaded > > Now, right-click titlebar, select "maximize" -> window _un_shades AND > maximizes (note that the "shade" in the titlebar-menu is now deselected, > as it is no longer shaded). Yup. Happens here, too, though I kinda thought of that as a "feature". > Big window, titlebar menu, "shade" -> big window shades > Now, right click titlebar menu, "maximize" (ie unmaximize) -> window > gets small, but stays shaded, as it should. However, right-clicking on > the titlebar shows that the "Shade" part in the menu is _de_selected. > That is, even though the window is shaded, BB thinks it's unshaded. > Select "Shade": window stays shaded (as BB thought it was unshaded), > "Shaded" is turned on. Once more "Shade" and it's back to normal (small > window, unshaded, menu has all the proper selections (ie none). That *is* "Bug #2" ;) Best, --Imad "(e)magius" Hussain _ "They gave you coffee They gave you tea They gave you everything but equality" -John Lennon & Yoko Ono, _Angela_ __
Re: window resizing bug?
definately a bug, I'm currently staring at a blackbox desktop allowing no input. BBkeys isn't taking any input, bbpager isn't listening, neither is my eterm. Interesting bug. >From: Chris Gilbreth <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: window resizing bug? >Date: Tue, 11 Dec 2001 13:52:11 -0800 > >When I am resizing a windows with alt+rightmousebutton, if I click the >left mouse button as I am doing it and drag some more I encounter some >wierd behaviour. Try it and see; it should be very obvious. The border >drawn for resizing doesn't dissappear, the window decides it wants to >be a different size, etc. Clicking the titlebar afterward seems to put >things back to normal for the window itself, but elsewhere on the >screen there still may be artifacts. _ Chat with friends online, try MSN Messenger: http://messenger.msn.com
Re: window resizing bug?
>From: Chris Gilbreth <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: window resizing bug? >Date: Tue, 11 Dec 2001 13:52:11 -0800 > >When I am resizing a windows with alt+rightmousebutton, if I click the >left mouse button as I am doing it and drag some more I encounter some >wierd behaviour. Try it and see; it should be very obvious. The border >drawn for resizing doesn't dissappear, the window decides it wants to >be a different size, etc. Clicking the titlebar afterward seems to put >things back to normal for the window itself, but elsewhere on the >screen there still may be artifacts. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
Re: very minor bugs (sorry, no patches)
--- "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: >> Bug 1: Right-click on any window's titlebar to get the titlebar menu, and >> maximize or unmaximize the window. The titlebar menu will not be removed >> (but it should be). This is easier to see when unmaximizing the window; when >> maximizing it, the only hint that the menu still exists is that the next time >> you click the mouse on anything, nothing will appear to happen (since >> blackbox removes the menu then, but the menu is unseen since it is covered by >> the maximized window), but after that, it will work as expect >> ed. >I can not recreate either of these. Hmmm. I'm reporting these as I remember them; I'm probably missing something here. Maybe try shading the window before following the directions in Bug 1, and see if the problem occurs then. _ Sluggy.Net: The Sluggy Freelance Community!
Re: very minor bugs (sorry, no patches)
[could you trim your lines to something <80 chars/line please? thanks] David Lawrence Ramsey <[EMAIL PROTECTED]> wrote: > Bug 1: Right-click on any window's titlebar to get the titlebar menu, > and maximize or unmaximize the window. The titlebar menu will not be > removed (but it should be). This is easier to see when unmaximizing > the window; when maximizing it, the only hint that the menu still > exists is that the next time you click the mouse on anything, nothing > will appear to happen (since blackbox removes the menu then, but the > menu is unseen since it is covered by the maximized window), but after > that, it will work as expected. Can't reproduce the problem. > Bug 2: Maximize a window, shade it, and unmaximize it. The window > will unmaximize, unshade for a split second (which it shouldn't do), > and then reshade. can't reproduce this either - but I see a different problem: Small window, right click titlebar, shade -> window is shaded Now, right-click titlebar, select "maximize" -> window _un_shades AND maximizes (note that the "shade" in the titlebar-menu is now deselected, as it is no longer shaded). Big window, titlebar menu, "shade" -> big window shades Now, right click titlebar menu, "maximize" (ie unmaximize) -> window gets small, but stays shaded, as it should. However, right-clicking on the titlebar shows that the "Shade" part in the menu is _de_selected. That is, even though the window is shaded, BB thinks it's unshaded. Select "Shade": window stays shaded (as BB thought it was unshaded), "Shaded" is turned on. Once more "Shade" and it's back to normal (small window, unshaded, menu has all the proper selections (ie none). -Jan -- http://www.netmeister.org http://guinness.cs.stevens-tech.edu/~jschauma/
Re: Upcoming 0.61.2 realease
Personally I like the focus as it stands. If say I'm working in a text editor (not mentioning any to avoid a favorites war) I don't always leave the pointer over the window when I'm typing. Also would this maybe disrupt bbkeys? Course I guess this could just be a new focus model too. just my $0.02 >From: Peter Szekszardi <[EMAIL PROTECTED]> >To: "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> >CC: [EMAIL PROTECTED] >Subject: Re: Upcoming 0.61.2 realease >Date: Tue, 11 Dec 2001 22:29:37 +0100 > >Hi, > >There are also some focus bugs I mentioned on the list a few weeks ago. >Is this new version only about bugfixes? Would you consider minor >functional enhancements? I would really love to see a new focusing >model, where the focus would really follow the mouse, so when there is >no window under the mouse pointer, no window should be focused. >One more important thing: Sean thanks for the development! > >Best regards, > >Peter _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: very minor bugs (sorry, no patches)
On 12-Dec-2001 Bill Beal wrote: > David Lawrence Ramsey <[EMAIL PROTECTED]> wrote: >> >> Bug 2: Maximize a window, shade it, and unmaximize it. >> The window will unmaximize, unshade for a split second >> (which it shouldn't do), and then reshade. > > Addendum: > > Just tried this out and noticed that following the > unmax-unshade-reshade, BB thinks the window is unshaded. > You have to double-click *twice* to unshade the window > again. > I did this one in reverse order, doh. I think I see this bug in my head, just have to find the culrpit code. Thanks Bill.
Re: Blackbox allows several instances of Opera.
On 12-Dec-2001 Christian Dysthe wrote: > Hi, > > I asked about this a while back, but got no answer. Maybe someone > now knows why Blackbox allows several instanses of Opera (the web > browser) as long as each instance is opened on different desktops? > > For instance, if I click on a link in my mailer an Opera instance is > opened even though another instance of Opera is running on another > desktop. In other WM's a click on an e-mail link switches to the > desktop where Opera is already running opening a window with the > link content, while in Blackbox one is opened on the current > desktop. > > I know for a fact that Opera is not designed to allow several > instances of itself. So why is Blackbox allowing it for this > application while other WM's I have tried this on (KDE, Gnome, IceWM > and XFce) don't? > That is not the wm's job. If the app wants to only allow one instance it can handle that. Switching workspaces (desktops) is even worse behaviour.
Re: call for patches
On Wed, 12 Dec 2001 07:49:09 -0800 (PST) "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: Knuth started with TeX 78, then TeX 80, with many versions. TeX 3 is basically the final version with only bugfixes extending the precision. Jeffrey > On 12-Dec-2001 Mads Martin J_rgensen wrote: > > * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [Dec 11. 2001 17:37]: > >> So, 0.61.2 is almost ready to be released screaming into the world. If > >> anyone > >> has a patch floating around that fixes some problem I would love to hear > >> about > >> it. The recent open file descriptor bug shows how much the community has > >> depended on the memory of this list to find bugs. > > > > Okay, now I'm gonna touch a subject which will probably start a huge > > flamewar. But nevertheless, I want to mention it. > > > > How about calling the upcoming release Blackbox 1.0? > > > > I intend to make a few more 0.61.x releases. After that a 1.0 will most likely > occur. Personally I think it is silly, not every piece of software needs a 1.0 > release. Knuth started at 3.1 and moved towards pi. > > I seriously doubt calling it 1.0 will make people use it any more or less than > now. Knowing that someone is still involved and releasing versions is more > likely to help this. -- I don't do Windows and I don't come to work before nine. -- Johnny Paycheck
Re: very minor bugs (sorry, no patches)
> Bug 1: Right-click on any window's titlebar to get the titlebar menu, and > maximize or unmaximize the window. The titlebar menu will not be removed > (but it should be). This is easier to see when unmaximizing the window; when > maximizing it, the only hint that the menu still exists is that the next time > you click the mouse on anything, nothing will appear to happen (since > blackbox removes the menu then, but the menu is unseen since it is covered by > the maximized window), but after that, it will work as expect > ed. > > Bug 2: Maximize a window, shade it, and unmaximize it. The window will > unmaximize, unshade for a split second (which it shouldn't do), and then > reshade. > I can not recreate either of these. > Bug 3: There's a typo in one of the displayed strings in bsetroot. Not being > in front of my Linux box, I can't tell you exactly where it is, but reading > the output of "strings" on the bsetroot binary should show it, after which > you can grep the source for it. > must specify on of <-- oops should be 'one'.
Re: very minor bugs (sorry, no patches)
David Lawrence Ramsey <[EMAIL PROTECTED]> wrote: > > Bug 2: Maximize a window, shade it, and unmaximize it. > The window will unmaximize, unshade for a split second > (which it shouldn't do), and then reshade. Addendum: Just tried this out and noticed that following the unmax-unshade-reshade, BB thinks the window is unshaded. You have to double-click *twice* to unshade the window again. -- Bill Beal [EMAIL PROTECTED] http://www.bildo.net/
Re: BB 1.0 (was: call for patches)
* Jan Schaumann <[EMAIL PROTECTED]> [Dec 12. 2001 16:58]: > It sure has, but the upcoming version should be numbered according to > what it is. And it's not a 1.0. I'd suggest calling this version > whatever you like, release it, get feedback, update the code, fix bugs, > NOT add feeatures or any new code *whatsoever* (except for closing > bugs), test it and _then_ /maybe/ call it 1.0 and go from there. Exactly! -- Mads Martin Joergensen, 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.
Blackbox allows several instances of Opera.
Hi, I asked about this a while back, but got no answer. Maybe someone now knows why Blackbox allows several instanses of Opera (the web browser) as long as each instance is opened on different desktops? For instance, if I click on a link in my mailer an Opera instance is opened even though another instance of Opera is running on another desktop. In other WM's a click on an e-mail link switches to the desktop where Opera is already running opening a window with the link content, while in Blackbox one is opened on the current desktop. I know for a fact that Opera is not designed to allow several instances of itself. So why is Blackbox allowing it for this application while other WM's I have tried this on (KDE, Gnome, IceWM and XFce) don't? TIA -- Christian Dysthe http://www.dysthe.net ICQ: 3945810 Registered Linux User #228949 "Everybody ought to have a Lower East Side in their life" -Irving Berlin-
Re: very minor bugs (sorry, no patches)
On 12-Dec-2001 David Lawrence Ramsey wrote: > I stumbled across a few very minor bugs in blackbox 0.61.1 a while ago. (In > hindsight, I should have sent the emails about them to this list instead of > to Raven directly, since they're fixed in his unreleased CVS version.) > Unfortunately, I do not have patches for these, because (a) my Xlib > programming skills are not very good, and (b) I haven't had access to my > Linux box for about a month. They should probably be easy fixes, however. > growl, more lost code. > Bug 1: Right-click on any window's titlebar to get the titlebar menu, and > maximize or unmaximize the window. The titlebar menu will not be removed > (but it should be). This is easier to see when unmaximizing the window; when > maximizing it, the only hint that the menu still exists is that the next time > you click the mouse on anything, nothing will appear to happen (since > blackbox removes the menu then, but the menu is unseen since it is covered by > the maximized window), but after that, it will work as expect > ed. > > Bug 2: Maximize a window, shade it, and unmaximize it. The window will > unmaximize, unshade for a split second (which it shouldn't do), and then > reshade. > > Bug 3: There's a typo in one of the displayed strings in bsetroot. Not being > in front of my Linux box, I can't tell you exactly where it is, but reading > the output of "strings" on the bsetroot binary should show it, after which > you can grep the source for it. > Spiffy bugs. Thanks.
very minor bugs (sorry, no patches)
I stumbled across a few very minor bugs in blackbox 0.61.1 a while ago. (In hindsight, I should have sent the emails about them to this list instead of to Raven directly, since they're fixed in his unreleased CVS version.) Unfortunately, I do not have patches for these, because (a) my Xlib programming skills are not very good, and (b) I haven't had access to my Linux box for about a month. They should probably be easy fixes, however. Bug 1: Right-click on any window's titlebar to get the titlebar menu, and maximize or unmaximize the window. The titlebar menu will not be removed (but it should be). This is easier to see when unmaximizing the window; when maximizing it, the only hint that the menu still exists is that the next time you click the mouse on anything, nothing will appear to happen (since blackbox removes the menu then, but the menu is unseen since it is covered by the maximized window), but after that, it will work as expected. Bug 2: Maximize a window, shade it, and unmaximize it. The window will unmaximize, unshade for a split second (which it shouldn't do), and then reshade. Bug 3: There's a typo in one of the displayed strings in bsetroot. Not being in front of my Linux box, I can't tell you exactly where it is, but reading the output of "strings" on the bsetroot binary should show it, after which you can grep the source for it. _ Sluggy.Net: The Sluggy Freelance Community!
BB 1.0 (was: call for patches)
Mads Martin Jørgensen <[EMAIL PROTECTED]> wrote: > How about calling the upcoming release Blackbox 1.0? > > There are some aspects of that: > > o The masses think a 1.0 release is better, and more people would >probably use BB now it's out in a 1.0 release, therefore bugs will be >discovered. I'm not sure BB is targeted at "the masses". Not a good enough reason, IMHO. > o Developer phsycology--even though people claim they don't care, >there is some fundamental phsycology about actually having a 1.0 >release. One really feels like something have been closed Which is why it should be used only if that is the case. Picking up the development and releasing a new bug-patch-release does, IMHO, not sound like something has been closed, but rather something has been openend. >, a project >have been done, so now new energy can be put into the next move. >After 1.0 we could have 1.0.x releases with bugfixes and 1.1.x for >devel. > > o We would also give the impression that development picked up again. > And it did! Souceforge sites, new guy in charge etc. etc. etc. It sure has, but the upcoming version should be numbered according to what it is. And it's not a 1.0. I'd suggest calling this version whatever you like, release it, get feedback, update the code, fix bugs, NOT add feeatures or any new code *whatsoever* (except for closing bugs), test it and _then_ /maybe/ call it 1.0 and go from there. -Jan -- http://www.netmeister.org http://guinness.cs.stevens-tech.edu/~jschauma/
Re: call for patches
On 12-Dec-2001 Mads Martin Jørgensen wrote: > * Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [Dec 11. 2001 17:37]: >> So, 0.61.2 is almost ready to be released screaming into the world. If >> anyone >> has a patch floating around that fixes some problem I would love to hear >> about >> it. The recent open file descriptor bug shows how much the community has >> depended on the memory of this list to find bugs. > > Okay, now I'm gonna touch a subject which will probably start a huge > flamewar. But nevertheless, I want to mention it. > > How about calling the upcoming release Blackbox 1.0? > I intend to make a few more 0.61.x releases. After that a 1.0 will most likely occur. Personally I think it is silly, not every piece of software needs a 1.0 release. Knuth started at 3.1 and moved towards pi. I seriously doubt calling it 1.0 will make people use it any more or less than now. Knowing that someone is still involved and releasing versions is more likely to help this.
Re: call for patches
* Sean 'Shaleh' Perry <[EMAIL PROTECTED]> [Dec 11. 2001 17:37]: > So, 0.61.2 is almost ready to be released screaming into the world. If anyone > has a patch floating around that fixes some problem I would love to hear about > it. The recent open file descriptor bug shows how much the community has > depended on the memory of this list to find bugs. Okay, now I'm gonna touch a subject which will probably start a huge flamewar. But nevertheless, I want to mention it. How about calling the upcoming release Blackbox 1.0? There are some aspects of that: o The masses think a 1.0 release is better, and more people would probably use BB now it's out in a 1.0 release, therefore bugs will be discovered. o Developer phsycology--even though people claim they don't care, there is some fundamental phsycology about actually having a 1.0 release. One really feels like something have been closed, a project have been done, so now new energy can be put into the next move. After 1.0 we could have 1.0.x releases with bugfixes and 1.1.x for devel. o We would also give the impression that development picked up again. And it did! Souceforge sites, new guy in charge etc. etc. etc. I for one really don't care, but then again... If this one already came up I missed it, apologies for that. -- Mads Martin Joergensen, 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: Exiting Blackbox
On Tue, Dec11,01 16:16, Kyle Donaldson wrote: > On Tue, 11 Dec 2001, Jan Schaumann wrote: > > [snip] > > > > Now, if blackbox receives any of SIGSEGV,SIGFPE, SIGINT or SIGTERM, it > > calls this shtudonw-function, just as if "exit" had been selected from > > the menu. It would therefore stand to reason that if you CTRL-ALT-BSPC > > X, bb should receive a SIGTERM and save the current configuration. > > > > If it doesn't, something's fishy. > > >From what I can tell, when C-A-BS is pressed, X catches it and kills > itself, thereby taking down all clients, either by being child processes or > losing the connection to the X server. > right, and C-A-BS is there for emergencies, not for shutting down properly, so it shouldn't send any commands to anything, it should just kill them all (tm)! DC > --gile > -- > "When you're born a lover, you're born to suffer" > -- Depeche Mode, "Goodnight Lovers" -- Derek Cunningham [EMAIL PROTECTED] "All men by nature desire to know." -- Aristotle. Registered Linux User Number 195825
Re: newsticker -> toolbar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If i remember correctly, there's already an applet called something like BlackStatusBox linked off of http://bbtools.thelinuxcommunity.org/ check it out... and since you piqued my interest, i'm trying to get it myself to try it out (but it seems the patch is on a server in the UK that i'm having trouble getting to). On Wednesday 12 December 2001 06:26, Sascha Huedepohl wrote: > Hi, > i just thought about a news-ticker in the bb-toolbar. > Who needs the name of the current window? > Maybe a good idea? > > regards > sascha > > - -- [scott] :: "ein kalter Tod für den sprecher von Lügen" -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPA02E2kF5Bwr8hiXEQLA0gCeNIq5+1lD9luyA/0qFSct6HaP0a8An1Td wCBPQmXjGQJxD27UuIw0UW/k =F1uz -END PGP SIGNATURE-
newsticker -> toolbar
Hi, i just thought about a news-ticker in the bb-toolbar. Who needs the name of the current window? Maybe a good idea? regards sascha
