Re: new NETWM key grabber
On Wed, Jul 10, 2002 22:16:18 at 10:16:18PM -0500, Ben Jansens wrote: > > Do you use the window list cycling currently found in bbkeys? > 1) Anything that allows you to work without the mouse is good! 2) windos list cycling is good, yes 3) open windows list in root menu and scroll it via keyboard is even better Ciao, Marco Fioretti -- Don't you wish you had more energy... or less ambition?
Re: ghostview
On Thu, 11 Jul 2002 18:24, Sean 'Shaleh' Perry wrote: > On 11-Jul-2002 Tim Howe wrote: > > For some reason ghostview's interface doesn't seem to work under > > blackbox. I am using Blackbox 0.62.1 on OpenBSD 3.1 and on another > > machine running OpenBSD-current. I have the same problem on both boxes. > > > > I can use ghostview just fine in fvwm, so I am pretty sure it's a > > blackbox issue. I am using ghostview 1.5 and ghostscript 7. I seem to > > recall having the same problem with blackbox-0.61.1. > > > > Is this a known issue? I can find no info on it. Is there any way I > > can provide more info if nobody else can replicate the problem? > > > > TimH > > "doesn't seem to work" is REALLY vague. Might as well start off with "my > car is making this odd noise". The versions are important, but more > important is a detailed description of what is failing and how. Use a > screenshot if you think it would help. > > Also, please grab beta2 and try it. I read the ICCCM.ps from X with > ghostview a few times a week and have not had any problems. Is it more of a 'knock' or a 'ping'? Fran :):):)
Re: new NETWM key grabber
Quoting Ben Jansens <[EMAIL PROTECTED]>: > we're not sure just what kind of feature people out there want in their > keyhandler. So, I'd like to take a bit of a poll. > Do you use the window list cycling currently found in bbkeys? Yes I do, as I try to do most things without the mouse. Here are a few things that I think would be new and I'd personally like added, if it's not too much :) * Mouse events. That is, the ability to assign key combinations to mouse events (move, click). I currently use external apps that I call thru exec with bbkeys. * Workspace cycling ability. Basicly the same it's done with windows (hold Alt and cycle with Tab -- of course, I would use something else for workspaces). * An alternative for [window] cycling: an event like "go to the last window". This way I could just hit "Menu" and bounce between the same two windows. It would be nice to also have this for workspaces. It would be different from the old bbkeys window-cycling because there would be no list of windows to cycle through, just jump back and forth between two windows/workspaces. Ciprian Popovici
Re: new NETWM key grabber
On Wed, 10 Jul 2002 23:03:21 -0700 Kolbe Kegel <[EMAIL PROTECTED]> wrote: > I'm not sure if this behavior would be compatible with the NETWM thing, > but it would be really nice to be able to specify keysyms instead of > just keys. For example, I have one of those multimedia keyboards and I > would love to be able to use my window manager's keygrabber to assign > actions to them instead of having to do it through xmms. > You can do it! I start xmodmap in my .xinitrc (xmodmap ~/.Xmodmap &) and .Xmodmap contains keycode 165 = XF86Sleep keycode 158 = XF86Mail keycode 178 = XF86WWW keycode 151 = XF86Memo keycode 163 = XF86Launch2 keycode 162 = XF86Launch3 keycode 164 = XF86Launch4 keycode 161 = XF86Launch5 add Mod4 = Multi_key and my .bbkeysrc loks like this KeyToGrab(S), WithModifier(Mod4), WithAction(ShadeWindow) KeyToGrab(F4), WithModifier(Mod4), WithAction(Close) KeyToGrab(M), WithModifier(Mod4), WithAction(MaximizeWindow) KeyToGrab(M), WithModifier(Mod4+Mod1), WithAction(MaximizeHorizontal) KeyToGrab(M), WithModifier(Mod4+Control), WithAction(MaximizeVertical) KeyToGrab(D), WithModifier(Mod4+Mod1), WithAction(ToggleDecor) KeyToGrab(Tab), WithModifier(Mod1), WithAction(NextWindow) KeyToGrab(Tab), WithModifier(Mod4), WithAction(PrevWindow) KeyToGrab(Right), WithModifier(Mod4+Control), WithAction(NextWorkspace) KeyToGrab(Left), WithModifier(Mod4+Control), WithAction(PrevWorkspace) KeyToGrab(1), WithModifier(Mod4), WithAction(Workspace1) KeyToGrab(2), WithModifier(Mod4), WithAction(Workspace2) KeyToGrab(3), WithModifier(Mod4), WithAction(Workspace3) KeyToGrab(4), WithModifier(Mod4), WithAction(Workspace4) KeyToGrab(5), WithModifier(Mod4), WithAction(Workspace5) KeyToGrab(Up), WithModifier(Mod4), WithAction(UpWorkspace) KeyToGrab(Down), WithModifier(Mod4), WithAction(DownWorkspace) KeyToGrab(Left), WithModifier(Mod4), WithAction(LeftWorkspace) KeyToGrab(Right), WithModifier(Mod4), WithAction(RightWorkspace) KeyToGrab(XF86AudioMute), WithModifier(None), WithAction(ExecCommand), DoThis(~/bin/mute.sh) KeyToGrab(XF86AudioLowerVolume), WithModifier(None), WithAction(ExecCommand), DoThis(aumix -v -1) KeyToGrab(XF86AudioRaiseVolume), WithModifier(None), WithAction(ExecCommand), DoThis(aumix -v +1) KeyToGrab(XF86WWW), WithModifier(None), WithAction(ExecCommand), DoThis(galeon) KeyToGrab(XF86Sleep), WithModifier(None), WithAction(ExecCommand), DoThis(xset dpms force standby) KeyToGrab(XF86Sleep), WithModifier(Mod4), WithAction(ExecCommand), DoThis(nethack-gnome) KeyToGrab(XF86Search), WithModifier(None), WithAction(ExecCommand), DoThis(aterm) KeyToGrab(XF86Mail), WithModifier(None), WithAction(ExecCommand), DoThis(sylpheed) KeyToGrab(XF86Launch2), WithModifier(None), WithAction(ExecCommand), DoThis(bbconf) KeyToGrab(Help), WithModifier(None), WithAction(ExecCommand), DoThis(~/bin/show-xmms-track) KeyToGrab(Pause), WithModifier(Mod4), WithAction(ExecCommand), DoThis(xmms -t) KeyToGrab(XF86Memo), WithModifier(None), WithAction(ExecCommand), DoThis(gtop) KeyToGrab(XF86Memo), WithModifier(Mod4), WithAction(ExecCommand), DoThis(gps) KeyToGrab(XF86Launch3), WithModifier(None), WithAction(ExecCommand), DoThis(gmc) KeyToGrab(XF86Launch4), WithModifier(None), WithAction(ExecCommand), DoThis(gcalc) KeyToGrab(XF86Launch5), WithModifier(None), WithAction(ExecCommand), DoThis(gimp) KeyToGrab(XF86AudioLowerVolume), WithModifier(Mod4), WithAction(ExecCommand), DoThis(xmms -f) KeyToGrab(XF86AudioRaiseVolume), WithModifier(Mod4), WithAction(ExecCommand), DoThis(xmms -r) /Mattias -- mattias östergren | /"\ compsci student | \ / ASCII Ribbon Campaign gävle, sweden| X No HTML in e-mail http://spikboll.net | / \
Re: new NETWM key grabber
On Thu, Jul 11, 2002 10:19:17 at 10:19:17AM +0200, Ciprian Popovici wrote: > > Here are a few things that I think would be new and I'd personally like > added, if it's not too much :) > > * Mouse events. That is, the ability to assign key combinations to mouse > events (move, click). I currently use external apps that I call thru exec > with bbkeys. > I would like that a lot too! Marco Fioretti -- We are drowning in information but starved for knowledge. -- John Naisbitt, Megatrends
Re: ghostview
> I can use ghostview just fine in fvwm, so I am pretty sure it's a > blackbox issue. I am using ghostview 1.5 and ghostscript 7. i have gv 3.5.8 and GNU Ghostscript 7.05, no problems... maybe your ghostview is just _really_ old Sam -- I'm going to raise an issue and stick it in your ear. -- John Foreman
Re: new NETWM key grabber
On Thu, Jul 11, 2002 at 11:34:32AM +0200 or thereabouts, Marco Fioretti wrote: > On Thu, Jul 11, 2002 10:19:17 at 10:19:17AM +0200, Ciprian Popovici wrote: > > > > Here are a few things that I think would be new and I'd personally like > > added, if it's not too much :) > > > > * Mouse events. That is, the ability to assign key combinations to mouse > > events (move, click). I currently use external apps that I call thru exec > > with bbkeys. > > > > I would like that a lot too! > > Marco Fioretti > -- > We are drowning in information but starved for knowledge. > -- John Naisbitt, Megatrends dito Cycling between last used windows/workspaces would be nice! bbkeys' menu-cycling feature comes handy when choosing among a huge list of windows. But as I tend to run several rxvt's with the same title (i.e. "rxvt"), choosing the right one is a mere guess. What would be nice to solve this is to look upon the window's child processes and display the last one found or the last common process found if child-processes fork again. (Use "ps auxfw" or "pstree" to get an idea.) Or at least an optional feature to display the pid, too. Thanks
Re: new NETWM key grabber
Ben Jansens wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey folks. > > So, work has begun as of tonight on a next generation key handler for > blackbox. It will be written against the NETWM spec as much as possible. But, > we're not sure just what kind of feature people out there want in their > keyhandler. So, I'd like to take a bit of a poll. > > Do you use the window list cycling currently found in bbkeys? Yes, all the time. The ability to execute programs via key commands is also extremely useful. Matt > Thanks for your feedback! > xOr > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD4DBQE9LPiC7BLuAtLlBOARAkrzAJ9rX7JVR9OuTJJzKnt51nIJKTSiYQCYpAXf > JhjhypODbZPwTZzzMxYVLQ== > =/cri > -END PGP SIGNATURE- >
Re: new NETWM key grabber
On Wed, Jul10,02 22:35, Ben Jansens wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wednesday 10 July 2002 10:33 pm, Derek Cunningham wrote: > > On Wed, Jul10,02 22:16, Ben Jansens wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Hey folks. > > > > > > So, work has begun as of tonight on a next generation key handler for > > > blackbox. It will be written against the NETWM spec as much as possible. > > > But, we're not sure just what kind of feature people out there want in > > > their keyhandler. So, I'd like to take a bit of a poll. > > > > > > Do you use the window list cycling currently found in bbkeys? > > > > yes I do... but it's useless, for me at least. > > > > What I WOULD like to see is an emacs-like ability to string characters > > together. ie: CTRL+Z+R will perform some action, and CTRL+Z+T will perform > > some other action. Think that's doable? > > Thats in the todo list. So, yes. :) I should note that after reading through the other responses, I misunderstood what you meant by "window list cycling". I use ALT+TAB all the time, and I use ALT+(1|2|3|...) all the time too, so an emphatic YES to window list cycling. :) DC PS: I had thought you meant the stupid little list that pops up WHILE cycling windows. :) -- Derek Cunningham [EMAIL PROTECTED] "Human beings act intelligently only after they have exhausted the alternatives" -- Abba Eban Registered Linux User Number 195825
Re: new NETWM key grabber
On Thu, Jul 11, 2002 06:40:18 at 06:40:18AM -0400, Gerrit Hoetzel wrote: > dito > > Cycling between last used windows/workspaces would be nice! > > bbkeys' menu-cycling feature comes handy when choosing among a huge list of windows. > But as I tend to run several rxvt's with the same title (i.e. "rxvt"), choosing the >right one is a mere guess. What would be nice to solve this is to look upon the >window's child processes and display the last one found or the last common process >found if child-processes fork again. (Use "ps auxfw" or "pstree" to get an idea.) > Or at least an optional feature to display the pid, too. > > Thanks Gerrit, that's an rxvt issue, isn't it? WHy should it depend/be solved by the window manager, whatever it is? AFAIK, there *is* a way to give to an rxvt a (constant) unique title, and maybe from that you can make it dynamic, i.e. to change according to the current process. I can't find the URL for rxvt titles, but would like to know if you find it and manage to make it dynaimc. Ciao, Marco Fioretti P.S.: please wrap your lines at 72/75 chars, thanks! Red Hat 7.2 in 8 MB of RAM: www.rule-project.org/ -- The three most dangerous things are a programmer with a soldering iron, a manager who codes, and a user who gets ideas.
Re: new NETWM key grabber
Do you use BASH? Try something like this in your .bashrc: export PROMPT_COMMAND='echo -n "^[]2;`hostname`:`pwd`:`history 1`^G"' Note that the "^]" and "^G" need to be control characters. With bash + rxvt ( + linux? ), you should get something like this for the title of the rxvt: chris-lap:/home/chris: 6 echo "blackbox rules" I'll leave it as an exercise to the reader to remove the "6" and to add in the pid of the rxvt. :) Gerrit Hoetzel wrote: > bbkeys' menu-cycling feature comes handy when choosing among a huge list of windows. > But as I tend to run several rxvt's with the same title (i.e. "rxvt"), choosing the >right one is a mere guess. What would be nice to solve this is to look upon the >window's child processes and display the last one found or the last common process >found if child-processes fork again. (Use "ps auxfw" or "pstree" to get an idea.) > Or at least an optional feature to display the pid, too. > > Thanks > -- Chris Grossmann web: http://www.grossmann.us
Re: new NETWM key grabber
Speaking of wrapping lines, please ignore the line wrap in the middle of the "export" command. :) Chris Grossmann wrote: > Do you use BASH? > > Try something like this in your .bashrc: > export PROMPT_COMMAND='echo -n > "^[]2;`hostname`:`pwd`:`history 1`^G"' > > Note that the "^]" and "^G" need to be control characters. > > With bash + rxvt ( + linux? ), you should get something like > this for the title of the rxvt: > > chris-lap:/home/chris: 6 echo "blackbox rules" > > I'll leave it as an exercise to the reader to remove the "6" > and to add in the pid of the rxvt. :) > > > Gerrit Hoetzel wrote: > > bbkeys' menu-cycling feature comes handy when choosing > > among a huge list of windows. But as I tend to run > > several rxvt's with the same title (i.e. "rxvt"), > > choosing the right one is a mere guess. What would be > > nice to solve this is to look upon the window's child > > processes and display the last one found or the last > > common process found if child-processes fork again. > > (Use "ps auxfw" or "pstree" to get an idea.) Or at > > least an optional feature to display the pid, too. > > > > Thanks > > > > -- > Chris Grossmann > web: http://www.grossmann.us > -- Chris Grossmann web: http://www.grossmann.us
Re: new NETWM key grabber
Just wanted to say that I find the notion of "rightWorkspace" "leftWorkspace" etc invaluable.. I always visualize my bbpager as a 2x4, and being able to move pacman-like through the worskspaces is a joy. (Or is it more like dig-dug?) xOr wrote: > Hey folks. > > So, work has begun as of tonight on a next generation key handler for > blackbox. It will be written against the NETWM spec as much as possible. But, > we're not sure just what kind of feature people out there want in their > keyhandler. So, I'd like to take a bit of a poll. > > Do you use the window list cycling currently found in bbkeys? > > Thanks for your feedback! > xOr > -- Chris Grossmann web: http://www.grossmann.us
Re: new NETWM key grabber
One feature that I haven't seen mentioned is context sensitivity. I would like the ability to have keys do different things when the pointer is over the root window versus other WM decorations. I'd also like to be able to pass certain keys through to selective applications. -g signature.asc Description: This is a digitally signed message part
Re: new NETWM key grabber
Thanks a lot for the hints. I use bash (and linux). An HOWTO about dynamic title can be found at: http://sunsite.unc.edu/LDP/HOWTO/mini/Xterm-Title.html A short summary: I added the following lines to my ~/.bashrc: if [ "$TERM" = "rxvt" ] || [ "$TERM" = "xterm" ]; then echo -ne "\E]2;Terminal $$ `date "+%H:%M:%S"`\a" fi This sets the terminal's title ONCE to: "Terminal PID TIME". Thats seems enough to distinguish between several terminals. Although I don't know if it proves useful, yet. Another example given in the how-to is utilizing the PS1 env-var. export PS1="\[\033]0;\u@\h: \w\007\]bash\$ " This changes the title every time the working directory changes. Maybe useful, too. Chris, your example has a major downside: Using env PROMPT_COMMAND the title is set AFTER the entered command has been finished. So, if you run mc and afterwards xeyes the terminal's title remains "... mc ..." while xeyes is running. But thanks for the hint, anyway. P.S.: I added "set wrapmargin=72" to vimrc -- Gerrit Hoetzel On Thu, Jul 11, 2002 at 08:58:33AM -0400, Chris Grossmann wrote: > Do you use BASH? > > Try something like this in your .bashrc: > export PROMPT_COMMAND='echo -n > "^[]2;`hostname`:`pwd`:`history 1`^G"' > > Note that the "^]" and "^G" need to be control characters. > > With bash + rxvt ( + linux? ), you should get something like > this for the title of the rxvt: > > chris-lap:/home/chris: 6 echo "blackbox rules" > > I'll leave it as an exercise to the reader to remove the "6" > and to add in the pid of the rxvt. :) > > > Gerrit Hoetzel wrote: > > bbkeys' menu-cycling feature comes handy when choosing among a huge list > > of windows. > > But as I tend to run several rxvt's with the same title (i.e. "rxvt"), > > choosing the right one is a mere guess. What would be nice to solve this > > is to look upon the window's child processes and display the last one > > found or the last common process found if child-processes fork again. > > (Use "ps auxfw" or "pstree" to get an idea.) > > Or at least an optional feature to display the pid, too. > > > > Thanks > > > > -- > Chris Grossmann > web: http://www.grossmann.us
Re: new NETWM key grabber
On 11-Jul-2002 Georg Nikodym wrote: > One feature that I haven't seen mentioned is context sensitivity. I > would like the ability to have keys do different things when the pointer > is over the root window versus other WM decorations. I'd also like to > be able to pass certain keys through to selective applications. > > -g > the paradigm is basically "send an event to a window if one is focused and this command makes sense on a window".
Re: new NETWM key grabber
> 3) open windows list in root menu and scroll it via keyboard is even >better > because of the separation of bbkeys and blackbox, menu scrolling is not going to happen.
Re: ghostview
>> On 11-Jul-2002 Tim Howe wrote: >> > For some reason ghostview's interface doesn't seem to work under >> > blackbox. I am using Blackbox 0.62.1 on OpenBSD 3.1 and on another >> > machine running OpenBSD-current. I have the same problem on both boxes. >> > for the record his issue is that he can not select text for copying in ghostview. This is a ghostview issue, not blackbox. It is not designed for copy and paste operations.
Re: new NETWM key grabber
On Thu, 11 Jul 2002 10:19:17 +0200 (MEST) Ciprian Popovici <[EMAIL PROTECTED]> wrote: > * Mouse events. That is, the ability to assign key combinations to mouse > events (move, click). I currently use external apps that I call thru exec > with bbkeys. I'm not sure what you mean, but here is a list of number-pad keys that may do mouse events. I do not, however, think they can be assigned to different keys or combinations. Shift-NumLock ... toggle MouseKeys 1,2,3,4,6,7,8,9,home,pgup,pgdn,end,left,right,up,down ... move pointer 5 ... click default button / ... set default button to 1 * ... set default button to 2 - ... set default button to 3 + ... double-click default button 0,insert ... lock default button .,delete ... unlock default button -- Joseph Applegate (SB-X) [EMAIL PROTECTED] | [EMAIL PROTECTED]
Re: ghostview
Sam Halliday declaimed: > > I can use ghostview just fine in fvwm, so I am pretty sure it's a > > blackbox issue. I am using ghostview 1.5 and ghostscript 7. > i have gv 3.5.8 and GNU Ghostscript 7.05, no problems... maybe your > ghostview is just _really_ old > My understanding is that 'ghostview' has been frozen at 1.5 for some time and the 'gv' is peferred because it's actively maintained. debian$ apt-cache show gv Package: gv Priority: optional Section: text Installed-Size: 548 Maintainer: Christian Kesselheim <[EMAIL PROTECTED]> Architecture: i386 Version: 1:3.5.8-26 Replaces: gv-2d, gv-3d, fvwm-common (<< 2.0.46-BETA-2) Provides: postscript-viewer, pdf-viewer Depends: gs, libc6 (>= 2.2.4-4), xaw3dg (>= 1.5-6), xlibs (>> 4.1.0) Conflicts: gv-2d, gv-3d Filename: pool/main/g/gv/gv_3.5.8-26_i386.deb Size: 224714 MD5sum: 0a7d08737441944fea050dd9676b4efb Description: A PostScript and PDF viewer for X using 3d Athena Widgets `gv' is a comfortable viewer of PostScript and PDF files for the X Window System. . It uses the `ghostscript' PostScript(tm) interpreter and is based on the classic X front-end for `gs', `ghostview'. It is more comfortable and more powerful than `ghostview'. Task: tex HTH, PM -- Paul Mackinney [EMAIL PROTECTED]
Re: ghostview
I installed gv and it works great. Thank you for the info. I can stop bitching now and get down to some typesetting... =] TimH On Thu, 11 Jul 2002 09:49:01 -0700 paul <[EMAIL PROTECTED]> wrote: > Sam Halliday declaimed: > > > I can use ghostview just fine in fvwm, so I am pretty sure it's a > > > blackbox issue. I am using ghostview 1.5 and ghostscript 7. > > i have gv 3.5.8 and GNU Ghostscript 7.05, no problems... maybe your > > ghostview is just _really_ old > > > My understanding is that 'ghostview' has been frozen at 1.5 for some > time and the 'gv' is peferred because it's actively maintained. > > debian$ apt-cache show gv > Package: gv > Priority: optional > Section: text > Installed-Size: 548 > Maintainer: Christian Kesselheim <[EMAIL PROTECTED]> > Architecture: i386 > Version: 1:3.5.8-26 > Replaces: gv-2d, gv-3d, fvwm-common (<< 2.0.46-BETA-2) > Provides: postscript-viewer, pdf-viewer > Depends: gs, libc6 (>= 2.2.4-4), xaw3dg (>= 1.5-6), xlibs (>> 4.1.0) > Conflicts: gv-2d, gv-3d > Filename: pool/main/g/gv/gv_3.5.8-26_i386.deb > Size: 224714 > MD5sum: 0a7d08737441944fea050dd9676b4efb > Description: A PostScript and PDF viewer for X using 3d Athena Widgets > `gv' is a comfortable viewer of PostScript and PDF files for the X > Window System. > . > It uses the `ghostscript' PostScript(tm) interpreter and is based > on the classic X front-end for `gs', `ghostview'. It is more > comfortable and more powerful than `ghostview'. > Task: tex > > HTH, PM > -- > Paul Mackinney > [EMAIL PROTECTED]
Trigger/Navigate Menu Via Keyboard?
I see there has been some discussion about being able to invoke the menu and navigate it using the keyboard. What's the definitive word on this? -Roy
JBuilder and Blackbox-- Dialogs Way Too Big?
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
RE: Trigger/Navigate Menu Via Keyboard?
On 11-Jul-2002 Roy Wood wrote: > I see there has been some discussion about being able to invoke the menu > and navigate it using the keyboard. > > What's the definitive word on this? > > > -Roy basically the only way it will happen is to move bbkeys back into blackbox proper.
RE: JBuilder and Blackbox-- Dialogs Way Too Big?
On 11-Jul-2002 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 All of the window code lives in Window.cc. The functions are for the most part obviously named. What would REALLY help track this down is the following: xprop and xwininfo on any over sized window version of the jre involved do you have ttf fonts enabled and working? I have seen sporadic complaints about odd sized windows. Unfortunately ALL of the complaints involve closed source apps and closed source java implementations so tracking them down is proving very, very hard. Please open a bug about this problem on the Tracker and fill it with data.
call for help -- need Java programmers
Have you or a friend recently been through a college programming course where they forced you to learn Java? Now is your chance to use this knowledge to help the blackbox community. We are receiving reports of odd sized windows. Transients, main windows, all of them. Simple programs which open and modify windows sizes AND demonstrate this bug would be VERY helpful. Be sure if possible that the app looks correct under twm or some other trusted window manager, preferably several. Yeah, I could probably learn Java in a few days and try to write test apps myself. But I would rather not, yes I am an open source idealist and Java is just a little too dirty for my tastes. One of the problems I am encountering is the applications which show these bugs are commercial and I can not run them personally. If you live in the San Francisco bay area I am willing to hack at a common location (your place, my place, whereever). Some nice ale would be appreciated but definately not required.
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.
Re: xprop and xwininfo on JBuilder dialog, running blackbox (Oversized dialogs problem)
Can you do the same in a different wm? Maybe twm? Øyvind Stegard wrote: > 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. > -- Chris Grossmann web: http://www.grossmann.us
RE: xprop and xwininfo on JBuilder dialog, running blackbox (Ove
> WM_NORMAL_HINTS(WM_SIZE_HINTS): > program specified location: 278, 241 > program specified size: 1054 by 743 > window gravity: NorthWest this is the baffling bit. Blackbox is doing EXACTLY what the program asked it to do. These hints are set when the program is first launched before blackbox can touch them. So near as I can tell, we are doing just what we are supposed to do. In the application it goes like this: create a window, specifiy a x,y coordinate and the width and height // occasionally the size or position is specified after window creation but // before the mapping map window when the map window step occurs blackbox receives a notification of a new window. It does: receive map request query new window's hints apply hints to the window frame it creates place window in the new frame By the time the map request is made all of the size hints are established.
RE: xprop and xwininfo on JBuilder dialog, running blackbox (Ove
>this is the baffling bit. Blackbox is doing EXACTLY what >the program asked it to do. Weird. Anyone with any sort of familiarity with another wm have any idea what they are doing that is different? -Roy
RE: xprop and xwininfo on JBuilder dialog, running blackbox (Ove
On 11-Jul-2002 Roy Wood wrote: >>this is the baffling bit. Blackbox is doing EXACTLY what >>the program asked it to do. > > Weird. Anyone with any sort of familiarity with another wm have any idea > what they are doing that is different? > > > -Roy I have read the twm, wmaker, and E code. Near as I can tell -- nothing. Remember, the wm should NOT matter here as the hints are set before the wm gets a chance to change anything. What I would like to hear first is that after simply exiting blackbox, starting another wm, and running JBuilder (or any offending application) everything is fine. This would help me confirm this is a problem in blackbox (or jave <-> blackbox) and not a bug in the jvm or other software. Currently I am working on adding heavy debug messages to the Window class which I will send to this list. Hopefully this will show the discrepancy.
RE: Mandrake Linux menus
Hello, Mandrake generates a blackbox menu automatically. Just include /etc/X11/blackbox/blackbox-menu in your blackbox menu. You can also edit it using the menudrake utility. In menudrake, make sure you change your environment to blackbox. Ben the pAved earth http://www.thepavedearth.com -- Original Message -- From: "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> Date: Wed, 10 Jul 2002 20:32:11 -0700 (PDT) >On 11-Jul-2002 D. Olson wrote: >> I use this distro (please don't insult me) and when I looked at fluxbox's >> menu config file, it had a list of all the mandrake menus... And it said that >> the file was automatically generated and to not mess with it. >> >> I would like to write a script that adds the mandrake menus into my blackbox >> menu without and is automatically generated at login. I can do all that, >> except I don't know how I can get the mandrake menus generated into a >> blackbox menu file. >> >> Does anyone know how to do this? >> >> >> >> I did it manually by copying and pasting into the blackbox menu file from the >> fluxbox menu file. The result I achieved is that there is a Mandrake submenu >> with all the mandrake menu items in it. >> > >in Debian we have a program call update-menus which reads /usr/lib/menu which >contains one file per package. Each file is parsed and pieced together via a >script provided by each window manager package. If you look more closely you >may discover a similar approach in Mandrake. > >Unless flux is radically different, the include directive should help as well. >Look at data/README.menu. >
RE: Mandrake Linux menus
On 11-Jul-2002 Ben Rasmussen wrote: > Hello, > Mandrake generates a blackbox menu automatically. Just include > /etc/X11/blackbox/blackbox-menu in your blackbox menu. You can also edit it > using the menudrake utility. In menudrake, make sure you change your > environment to blackbox. > >> same name and location as the Debian menu BTW.
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.
verbose Window patch
Enclosed is the verbose patch i mentioned on the Java thread. gunzip verbose.patch.gz cd blackbox patch -p0 < /path/to/verbose.patch make when you run the new binary the path from initial request to final display has a print whenever the window size would have changed. There are also additional prints in the methods called when a window requests a change. Typical output looks like this: 0xc00046: initial (30, 25) w: 100, h: 43 the initial number is the window id in hex, it matches the output of xwininfo. I could not include the window's title because it is not available that early in the code. If blackbox really is causing problems I expect to see a reasonable value for initial and then weirdness later. There is a print in there which says: sizes reflect the frame from now on after this, expect the x,y width, height to be slightly different. The numbers now reflect the managed blackbox frame not the initial data from the client window. In general the window will move down around 15 - 20 pixels, have its height increased by around 20 - 30 pixels, and its width adjusted from 2 - 10 pixels. Going from w: 100, h: 43 to w: 1000, h: 300 should not happen unless something requested the change. When you test JBuilder I would ask that you move any ~/.jbuilder (or whatever it is called) aside and run the app as if you just installed it. In fact, if you create a dummy user on your machine and run the program from that account it would ensure none of your personal settings were involved. Some of these apps store the last known width, height and coordinates to open at that spot later on. So if bad values were stored last time you will see them this time. Please let me know if the list manager eats the attachment. verbose.patch.gz Description: verbose.patch.gz
Re: Testing the JBuilder (java?) oversized dialog problem with other WMs
On Thu, Jul 11, 2002 at 09:52:08PM +0200, ?yvind Stegard wrote: > 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 Does twm/others set some sort of root hint that it could be using? Does blackbox? I can't think of another way for it to behave differently.. xOr -- I am damn unsatisfied to be killed in this way. msg07718/pgp0.pgp Description: PGP signature
Re: verbose Window patch
> Enclosed is the verbose patch i mentioned on the Java thread. Are you still willing to "install" a Java-app. and try for yourself? I've just "created" (read: modified an existing) one which reproduces the error 1 time out of 2-5 times you try... > gunzip verbose.patch.gz > cd blackbox > patch -p0 < /path/to/verbose.patch > make I could try this as well... // Martin
Re: Testing the JBuilder (java?) oversized dialog problem with o
> > > Does twm/others set some sort of root hint that it could be using? Does > blackbox? I can't think of another way for it to behave differently.. > xprop on root shows no hints under twm, wmaker sets a few. I really see nothing. I am hoping the user tests will at least give me enough information to file bugs with the vendors.
Re: verbose Window patch
On 11-Jul-2002 Martin Egholm Nielsen wrote: >> Enclosed is the verbose patch i mentioned on the Java thread. > Are you still willing to "install" a Java-app. and try for > yourself? I've just "created" (read: modified an existing) > one which reproduces the error 1 time out of 2-5 times you > try... > definately, send it to me directly or place it on a public site so as not cause too many attachments and large mails to hit the list. >> gunzip verbose.patch.gz >> cd blackbox >> patch -p0 < /path/to/verbose.patch >> make > I could try this as well... > two debuggers are better than none (-:
Re: new NETWM key grabber
On Wed, Jul 10, 2002 at 11:33:14PM -0400, Derek Cunningham wrote: > On Wed, Jul10,02 22:16, Ben Jansens wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hey folks. > > > > So, work has begun as of tonight on a next generation key handler for > > blackbox. It will be written against the NETWM spec as much as possible. But, > > we're not sure just what kind of feature people out there want in their > > keyhandler. So, I'd like to take a bit of a poll. > > > > Do you use the window list cycling currently found in bbkeys? > > > > yes I do... but it's useless, for me at least. > > What I WOULD like to see is an emacs-like ability to string characters > together. ie: CTRL+Z+R will perform some action, and CTRL+Z+T will perform > some other action. Think that's doable? Or maybe distinguish sth. like vi's command and insert mode. "Insert" mode would give the focused window control over the keyboard, "Command" mode would give control to the key grabber; and special (vi-like) commands could be issued: e.g. typing "20j" in command mode would move the current window 20 times down. Or: different windows could be assigned to differnt keys. This way one could easily switch between last used windows. Or: Typing "sP7" could be interpreted: start the program (which was assigned to key P) and put it to workspace 7. And so on... The command mode key could e.g. be Ctrl; so by pressing Ctrl+F1 one could still switch workspaces by a 'single' keystroke. This would be a nice feature, especially as this concept might prove to be very flexibe and might make mouses a bit more useless (or who uses a mouse in vi?). > > DC > > -- > Derek Cunningham > [EMAIL PROTECTED] > > "Human beings act intelligently only after they have > exhausted the alternatives" -- Abba Eban > > Registered Linux User Number 195825
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: Testing the JBuilder (java?) oversized dialog problem with o
On 11-Jul-2002 Øyvind Stegard wrote: > 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. > According to this: 0xa0002b: initial (42, 60) w: 870, h: 446 tip of the day requested to be opened 870 pixels wide by 446 pixels high. That line is the first thing blackbox has a chance to do on the window. Again, this does not look like a blackbox bug. I know, it only happens in blackbox so something odd is happening. Damned if i know what though. Thanks for helping out.
start app in specific workspace
Is there a way to start a prg in workspace no. X ? If so, how to implement into the default X-startup script ? I would like to initially start (using xtoolwait ?) an xterm in workspace No. 1 mozilla in workspace No. 2 ... -- Gerrit Hoetzel http://www.hzhome.mine.nu/gt/
additional verbosity
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. verbose2.patch Description: verbose2.patch
Re: JBuilder and Blackbox-- Dialogs Way Too Big?
On Thu, 11 Jul 2002 13:23:33 -0400 "Roy Wood" <[EMAIL PROTECTED]> 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). What version of Jbuilder are you using? I have hade similar problems with Jbuilder5 myself (but not 100% sure it was with blackbox). I can check with Jbuilder6 tomorrow, and maybe Jbuilder7 later. (I'm very interrested in this because we have to support jbuilder to the student at my university) /nils g
RE: additional verbosity
On 11-Jul-2002 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. Dammit, I had it working, then fusted a copy/paste. The fprintf in this patch should use xmaprequest.window, not .parent as its output.
Re: JBuilder and Blackbox-- Dialogs Way Too Big?
On 11-Jul-2002 Nils Grundback wrote: > On Thu, 11 Jul 2002 13:23:33 -0400 > "Roy Wood" <[EMAIL PROTECTED]> 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). > > What version of Jbuilder are you using? I have hade similar problems > with Jbuilder5 myself (but not 100% sure it was with blackbox). > > I can check with Jbuilder6 tomorrow, and maybe Jbuilder7 later. > > (I'm very interrested in this because we have to support jbuilder to > the student at my university) > > /nils g If you do see this behavior, please run blackbox with the patches I have posted today.
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.
Re: Mandrake Linux menus
On Thursday 11 July 2002 03:41 pm, you wrote: > Hello, > Mandrake generates a blackbox menu automatically. Just include > /etc/X11/blackbox/blackbox-menu in your blackbox menu. You can also edit > it using the menudrake utility. In menudrake, make sure you change your > environment to blackbox. That's strange... Look: [dana@digory dana]$ cd /etc/X11/blackbox/ bash: cd: /etc/X11/blackbox/: No such file or directory [dana@digory dana]$ What am I doing wrong? I am in Blackbox now (it's the onyl WM I use now - it rocks), so I KNOW that it works. My current menu file is in my ~/.blackbox/ folder. I don't want just Mandrake's menu as my Blackbox menu, as I like the options to configure and restart and quit bb in there. As well as other stuff. Oh, and FYI, menu-update is included with Mandrake too, but I never used it. -- D. Olson The Mandrake eXPerience http://mdkxp.by-a.com/ MUB-NWN http://nwn.by-a.com/ WinXP - the best thing since induced vomitting.
Re: call for help -- need Java programmers
Sean 'Shaleh' Perry declaimed: > Have you or a friend recently been through a college programming course where > they forced you to learn Java? Now is your chance to use this knowledge to > help the blackbox community. > > We are receiving reports of odd sized windows. Transients, main windows, all > of them. Simple programs which open and modify windows sizes AND demonstrate > this bug would be VERY helpful. Be sure if possible that the app looks correct > under twm or some other trusted window manager, preferably several. Yeah, I > could probably learn Java in a few days and try to write test apps myself. But > I would rather not, yes I am an open source idealist and Java is just a little > too dirty for my tastes. > > One of the problems I am encountering is the applications which show these bugs > are commercial and I can not run them personally. > > If you live in the San Francisco bay area I am willing to hack at a common > location (your place, my place, whereever). Some nice ale would be appreciated > but definately not required. Sean, I have JBuilder 6 Personal and don't see the problems. Will install 7 & see what's up. Sun has lots of sample programs, I can do some hacking on this tonight. I manage a computer lab at Mills college in Oakland (intersection of 580 & 13) could almost certainly get approval for you to come hack there when you have a test program that shows the bug. Could provide a P2/256 Dell system. Regards, PM -- Paul Mackinney [EMAIL PROTECTED]
Re: new NETWM key grabber
Brandon Thigpen wrote: > What I would like to see the most is the ability to bind keys to pop > up the root menu, and be able to move around in it using the vi keys > (j,k,l,etc). I also use Alt+Tab for window switching, and have set > up bbkeys to start some programs I use often: > > Alt+x = xterm > Alt+e = mutt (e for "email") > Alt+p = pan > Alt+o = opera > etc. > > and I do this to swithch workspaces: > > Alt+1 = workspace1 > etc. > > I've asked here before about being able to open the root menu with a > key instead of right-clicking on root window, but apparently it was > impossible at the time. If I could do this, I wouldn't have to use > the mouse at all -- much faster once you get used to it. > > Thanks > Yes, if at all possible, i'd really like to see root menu control from the keyboard too, i know this is on everyone's TODO lists. What i personally use the most are command exec, direct workspace switching (ALT+1 for wksp 1) and ALT+Tab for window cycling. So please keep these features :)
Re: additional verbosity
On Fri, 12 Jul 2002 00:32:15 +0200 <[EMAIL PROTECTED]> wrote: > 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. the second patch sould be applied with a "-p1" option. -- Jamin W. Collins
Re: call for help -- need Java programmers
On Thu, 11 Jul 2002 10:40:24 -0700 (PDT)
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote:
> Have you or a friend recently been through a college programming course
> where they forced you to learn Java? Now is your chance to use this
> knowledge to help the blackbox community.
Hmmm no real college programming, but I hope you'll still accept my
submission. =^P
> We are receiving reports of odd sized windows. Transients, main
> windows, all of them. Simple programs which open and modify windows
> sizes AND demonstrate this bug would be VERY helpful.
Attached is a simple GUI java app which can reproduce the problem ~ 1 in 5
times under Blackbox (source and class). I've also attached the
redirected output from Blackbox with the requested verbosity patches. The
window id for the java app was always 0x121.
> Be sure if
> possible that the app looks correct under twm or some other trusted
> window manager, preferably several.
Ran this same app under Window Maker 25 times without a replication of the
error.
> If you live in the San Francisco bay area I am willing to hack at a
> common location (your place, my place, whereever). Some nice ale would
> be appreciated but definately not required.
I don't live in the SF area, but a beer is certainly on me for a fix to
this.
Note: didn't figure anyone would mind all the items being directly attach
as they are only a whopping 1633 bytes total.
--
Jamin W. Collins
DemoApp.class
Description: application/java-vm
import javax.swing.*;
public class DemoApp
{
static JFrame aWindow = new JFrame("Quick Demo App");
public static void main(String[] args)
{
aWindow.setBounds(50, 100, 400, 150);
aWindow.setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
aWindow.setVisible(true);
}
}
bb-log.gz
Description: Binary data
Re: call for help -- need Java programmers
> >> We are receiving reports of odd sized windows. Transients, main >> windows, all of them. Simple programs which open and modify windows >> sizes AND demonstrate this bug would be VERY helpful. > > Attached is a simple GUI java app which can reproduce the problem ~ 1 in 5 > times under Blackbox (source and class). I've also attached the > redirected output from Blackbox with the requested verbosity patches. The > window id for the java app was always 0x121. > as I commented on the other thread, my second patch has a small problem. s/xmaprequest.parent/xmaprequest.window/; >> If you live in the San Francisco bay area I am willing to hack at a >> common location (your place, my place, whereever). Some nice ale would >> be appreciated but definately not required. > > I don't live in the SF area, but a beer is certainly on me for a fix to > this. > (-:
Re: new NETWM key grabber
On Thu, 2002-07-11 at 08:57, Derek Cunningham wrote:
> On Wed, Jul10,02 22:35, Ben Jansens wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On Wednesday 10 July 2002 10:33 pm, Derek Cunningham wrote:
> > > On Wed, Jul10,02 22:16, Ben Jansens wrote:
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA1
> > > >
> > > > Hey folks.
> > > >
> > > > So, work has begun as of tonight on a next generation key handler for
> > > > blackbox. It will be written against the NETWM spec as much as possible.
> > > > But, we're not sure just what kind of feature people out there want in
> > > > their keyhandler. So, I'd like to take a bit of a poll.
> > > >
> > > > Do you use the window list cycling currently found in bbkeys?
> > >
> > > yes I do... but it's useless, for me at least.
> > >
> > > What I WOULD like to see is an emacs-like ability to string characters
> > > together. ie: CTRL+Z+R will perform some action, and CTRL+Z+T will perform
> > > some other action. Think that's doable?
> >
> > Thats in the todo list. So, yes. :)
>
> I should note that after reading through the other responses, I
> misunderstood what you meant by "window list cycling". I use ALT+TAB all the
> time, and I use ALT+(1|2|3|...) all the time too, so an emphatic YES to
> window list cycling. :)
>
> DC
>
> PS: I had thought you meant the stupid little list that pops up WHILE
> cycling windows. :)
Heh. Careful, matey. xOr's the one who helped me put that "stupid
little list" in. =:) I happen to love it. *shrug* One man's stupid
is another man's most favoritest new toy.
>
> --
> Derek Cunningham
> [EMAIL PROTECTED]
>
> "Human beings act intelligently only after they have
> exhausted the alternatives" -- Abba Eban
>
> Registered Linux User Number 195825
>
--
,-//
| Jason 'vanRijn' Kasper :: Numbers 6:22-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: call for help -- need Java programmers
On Thu, 11 Jul 2002 19:25:46 -0700 (PDT) "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > as I commented on the other thread, my second patch has a small problem. > > s/xmaprequest.parent/xmaprequest.window/; Grrr I thought I'd gotten all of those. Should have use the F&R function rather than eyeballing it. =( If it would help I can rerun the tests. -- Jamin W. Collins
Re: call for help -- need Java programmers
On 12-Jul-2002 Jamin W. Collins wrote: > On Thu, 11 Jul 2002 19:25:46 -0700 (PDT) > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > >> as I commented on the other thread, my second patch has a small problem. >> >> s/xmaprequest.parent/xmaprequest.window/; > > > Grrr I thought I'd gotten all of those. Should have use the F&R > function rather than eyeballing it. =( If it would help I can rerun the > tests. > fixed patch attached (-: verbose2.patch Description: verbose2.patch
Re: call for help -- need Java programmers
On Thu, 11 Jul 2002 20:39:32 -0700 (PDT) "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > On 12-Jul-2002 Jamin W. Collins wrote: > > > Grrr I thought I'd gotten all of those. Should have use the F&R > > function rather than eyeballing it. =( If it would help I can rerun > > the tests. > > fixed patch attached (-: Updated bb-log attached. Window ID this time is 0x1400021. -- Jamin W. Collins bb-log.gz Description: Binary data
Re: call for help -- need Java programmers
On 12-Jul-2002 Jamin W. Collins wrote: > On Thu, 11 Jul 2002 20:39:32 -0700 (PDT) > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > >> On 12-Jul-2002 Jamin W. Collins wrote: >> >> > Grrr I thought I'd gotten all of those. Should have use the F&R >> > function rather than eyeballing it. =( If it would help I can rerun >> > the tests. >> >> fixed patch attached (-: > > Updated bb-log attached. Window ID this time is 0x1400021. > on my machine it asks to be 789 x 269 which becomes 791 x 288 after the frame is added. It asks this AFTER this window is visible but fast enough that you do not notice it. This is directly from a XMoveResize window call or equivalent in the swing code somewhere. I added another print directly from the values in the event we receive. While I accept that this is not occuring under other wms, I am at a great loss as to why the java gui toolkit is sending us bogus configure requests. I wonder if further testing would reveal other wms where this occurs. One thing I have noticed is that the swing toolkit sends new and different WM_NORMAL_HINTS, so without the debug messages we could not see the size the window actually loads at. Your app requests 400x150 yet it is initially mapped at 390x120 and a new WM_NORMAL_HINT and configure request later on changes the size. The problem appears to have something to do with the delay in the window loading. If I run: for i in `seq 1 10`; do /opt/java/j2re1.4.0_01/bin/java DemoApp & done it is almost always one of the last 3 that shows up an odd size. Another item of interest is the odd configure request is almost always 2x (1.5 or 2.5) the window size. Like it stacks up two requests and sends them as one almost. A reliable way to cause this would be handy. Until then your app has helped a lot. I am still waiting for a report from Chris about his problem with 1x1 windows.
Re: new NETWM key grabber
> In <[EMAIL PROTECTED]> > "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > > 3) open windows list in root menu and scroll it via keyboard is even > >better > > > because of the separation of bbkeys and blackbox, menu scrolling is not going > to happen. I long this feature. Can bbkeys control the mouse pointer by arrow keys without any modifiers, only when the root/window menu displayed? Is it possible that bbkeys emulates mouse movements and click actions? -- yamasaki <[EMAIL PROTECTED]>
Re: start app in specific workspace
Gerrit Hoetzel <[EMAIL PROTECTED]> writes: > Is there a way to start a prg in workspace no. X ? > > If so, how to implement into the default X-startup script ? > I would like to initially start (using xtoolwait ?) an > xterm in workspace No. 1 > mozilla in workspace No. 2 > ... bblaunch ? Like this? bblaunch xemacs -w 1 & bblaunch -w 2 "aterm -tr +sb -fg white -bg black -fn 10x20 -geometry 75x25+80+90" & bblaunch -w 3 aterm -sr -sl 1024 -ls -bg black -fg white -tr -trsb -tint red & exec blackbox hth Glyn
