Re: Konqueror and Java applets
On Monday 16 September 2002 23:22, Martin Rowe wrote: On Monday 16 September 2002 11:22 pm, Sean 'Shaleh' Perry wrote: [snip] Can you supply some urls for me to test? Try http://www.400times.co.uk which has some navigation 'bubbles' on the left. In Galeon they appear in the browser window, in Konqueror they end up in a separate window positioned +0+0. There's a screenshot at http://www.dbg400.net/download/java_window.jpg (121Kb) if it helps. Regards, Martin this appears to be a netwm issue so hopefully it will be solved in the coming months. Brad and I have begun talks about the new 0.70 code. Perhaps it will only be vapourware a while longer.
new mailing list address
Due to problems with our current mail archives and issues with the speed that admin requests are handled we are moving the mailing list to asgardsrealm.net which Jamin Collins hosts. This is a gracious offer on his part. Brad will have the [EMAIL PROTECTED] mail sent to the new list so no messages should be lost. If all goes well this will be activated sometime tonight. The mailing list archive can be found here: http://asgardsrealm.net/lurker/splash/index.html The new addresses for list use are: # List posts (restricted to subscribers) [EMAIL PROTECTED] # List admin contact (directed to me currently) [EMAIL PROTECTED] # Subscribe [EMAIL PROTECTED] [EMAIL PROTECTED] # Unsubscribe [EMAIL PROTECTED] [EMAIL PROTECTED] # List Help [EMAIL PROTECTED]
Re: Fwd: Re: man page edits.
On Tuesday 17 September 2002 13:49, Robert wrote: That's 'their file name' assuming that hasn't already been picked up, and it probably should mention that it doesn't search subdirectories of that path. (It also ignores file~ but that's getting a bit arcane) got that already, thanks.
Re: Java/Blackbox oversized window bug with IBM JRE
Nope, I have not tried this wm. Just visited the web page where it belongs. I could give it a whirl later today, perhaps. Will tell my observations of how it behaves with java. (I'll try JRE's from Sun and from IBM) there were reports that fvwm was exhibiting similar symptoms.
RE: Java/Blackbox oversized window bug with IBM JRE
On 25-Jul-2002 Roy Wood wrote: One of the posts mentions SwingSet2 demo. Does anyone know what this is and where I can get it? It's a demo showing off the Swing GUI toolkit. Dunno about Sun, but IBM includes it with their SDK. Pretty nifty, I guess. Demonstrates that Java is still kinda sluggish compared to a pure-native GUI toolkit like Gtk though. It also is a greay way for people test Blackbox's java support under the various jre's they are using. Try all of the demos, see which ones act funny.
Re: Java/Blackbox oversized window bug with IBM JRE
Yup, a bit exaggerated. The speed of the newest JVMs is great, if you ask me. Most Java apps I use, run quite smoothly. Btw, I experienced the bug with the Blackdown JRE too, but the problem was more often too small dialogs than too big.(Like dialog sizes of 2x10 pixels and such) - *Covering my head from flying coffee cups/other easily accessible/throwable desktop objects* =). it is definately different with each jvm. So I've tried three different JVMs now, none of them likes to cooperate with Blackbox. Also worth mentioning, all applications I've tried are quite heavy, and needs a bit of loading time. I think I remember hearing someone talk about this. the more the machine is grinding the more likely the window is to be incorrectly sized has been my observation. I am at a loss for a solution to this issue. This is a Java problem but I know that we are making it worse.
Re: Java/Blackbox oversized window bug with IBM JRE
It was my understanding that it was based off of Blackbox. Teach me to open my fool mouth... if it's based off of Blackbox, it's only in spirit, 'cause even *I* can tell the two of them don't look anything like each other. Like Gnome would ever adopt anything written in C++ in the first place. Yah, right... KDE is more likely to dump kwin and adopt Openbox. :) /me puts on the dunce cap. Did find more than a few statements on the web talking about Sun and Metacity, though. :) (-: no worries omae we all have those days ...
any programmers with time on their hands
So here is one way to track down the Java bug. Disable almost all of BlackboxWindow::BlackboxWindow(). Slowly enable line by line until the bug occurs. At least then we know where and can learn why. Also, I have heard the 0.62 does not demonstrate this problem but I have also heard that it is affected. If we could test this better another possibility is to attempt to port 0.62's constructor over and see if it helps.
Re: decor updates in cvs
On 24-Jul-2002 Mr.X wrote: I found something fairly interesting, thought I'd check here to see if anybody else can reproduce it before I submit. Using Sylpheed (0.8.0), if you hit the Get button a dialog pops up and shows the download status of the mail. If you toggle the decor of this dialog off, then back on again it doesn't gain a maximize button, but it DOES gain a window handle. To reproduce this you have to either have a lot of mail, a really slow connection, or cat-like reflexes, but it is happening. Every other dialog I've tried works fine, Sylpheed is the only one doing this. Oh yeah, I almost forgot, I'm using CVS as of...well, might as well be a few seconds ago. I think I found it, committing now. Let me know. For reference this also happen(s|ed) with mozilla's url window. Part of the problem is that there is no memory associated with the decor setting. So if you have a window with minimal decor already and you toggle it off, then on bbkeys sends: decor none decor normal # but what if I was tool or tiny and not normal? The current code tries to be smart and not give a maximize button to a window that can not be maximized and what not but I think this is a losing battle. In the mozilla case it sets no iconify button via mwm hints. However it does not also disable iconify in general. So it is available from the window menu. When you toggle the decor off and then odd the code reads the abilities of a window and sees that it can be iconified and adds the iconify button. There is no way to check for whether or not the window had one before decor was toggled. Yeah I could add an old_decor variable but that seems like a waste.
Re: Slight niggle/bug perhaps.
On 24-Jul-2002 Marc Wilson wrote: On Wed, Jul 24, 2002 at 12:23:53PM -0700, Sean 'Shaleh' Perry wrote: As I see it the best we can manage would look like this. process deleted Didn't you just describe bbappconf/bblaunch? :) yep, that was kind of the point (-:
Re: decor updates in cvs
Actually, it could be an interesting thing to solve (albeit a very minor one): when I open a window with a text form in it, sometimes it isn't the right size to display the whole text, and having only the close-minimize buttons, but no handles, it is uncomfortable to scroll back forth. If I do toggledecor twice (off ,then on again) handles appear. I noticed this behavior at this site: http://www.tectimes.com/foros/listado.asp?codforo=4nomforo=Linux If you open any post there with Mozilla (version up to 1.0) you will see what I mean. Oh, this happens in a screen res of 1024x798, if it is of any use. This happens in Opera too, but the browser lets me resize those windows independently of the wm. So I would guess it's a problem with the website, not with bb. Adriano mozilla sets several hints detailing exactly what decor we should give it. The problem is these hints are destroyed when you toggle decor. The lack of resize handles is by request.
RE: beta3 mouse shading
On 23-Jul-2002 Matthew Weier O'Phinney wrote: I determined what changes I needed to make -- the beta series wheel mouse patch only applies to switching workspaces, and thus only affected Screen.cc; the original patch I had was from x0r, and also had code for the window shading and thus affected Window.cc. I determined where to insert the code, did so, compiled, and everything works beautifully now. Since I know others on the list like to use this particular patch, I've now got another question: how do I make the patch? I'm not a C programmer, and I don't normally create or use patches. Do I simply do a diff on my files versus the original source? basically. cd blackbox make distclean cd .. cp -a blackbox blackbox-orig cd blackbox hack hack hack make distclean cd .. diff -pruN blackbox-orig blackbox mystuff.patch the -pru option is the format I prefer, other projects may request -prc. Once you have your patch go to sf.net and place it on blackbox's patch tracker so others can enjoy.
Re: beta3 mouse shading
On 23-Jul-2002 D. Olson wrote: Thank you so much! I applied the patch manually (cuz I don't know how to do it properly and I don't feel like finding out atm) and I recompiled and made an RPM. Yay! It works great. cd blackbox patch -p1 /path/to/patch
decor updates in cvs
If you use windows with no decor or minimal decor or are a heavy bbtool user please consider testing the cvs code. I made a few cleanups today which appear to be sound but I would like to hear positive results from a few users. Specifically: does your window lose its close button unexpectedly? if you toggle decor on and off does the decor change?
Re: decor updates in cvs
if you toggle decor on and off does the decor change? yep, the decor does change. one new thing that i did notice is that windows without decor get it back on a bb restart, but then continue to behave normally. what used to happen (and i'm not sure if this is a new change or not) was the window would get decor back but would think that it was decor-less (so if you toggled again it would continue to have decorations, a second toggle would turn them back off). point is the current behaviour seems better than what i'd previously observed. any way that they can continue to stay decor-less through a restart? perhaps I was not clear. I mean if you toggle decor off, then toggle it back is the decor displayed the same as it was before it was disabled. As to the decorless window over a restart, I am looking into it.
Re: decor updates in cvs
Sorry, I am dumb... Is there a hot key to toggle this or something? Actually, more importantly, is this a feature available beta3? bbkeys has a binding for this there is no way to do it directly from blackbox.
Re: decor updates in cvs
As to the decorless window over a restart, I am looking into it. excellent. keep up the good work! for whatever reason the decor was not handled by the code which restores a window on startup. I added in the code. Needs loads of testing.
Re: decor updates in cvs
It also seems to work fine across a restart. Only thing I can see is when I un-decor a shaded window, it unshades (that's fine) but when I re-decor it it stays unshaded. Is this intended? Not that it's a big problem... I was just wondering if it was meant to do that. Oh, and why or are a heavy bbtool user? My bbtools all sit in the slit, and don't focus, let alone decor... many bbtools set states so that the maximize button is not displayed.
Re: decor updates in cvs
On 23-Jul-2002 Matt Wilson wrote: I'm not sure quite what's caused it, but it was something to do with switching decor on/off multiple times - two of the three windows I was decor-switching have done it: now the decor draws in unfocused state fine, but focused state doesn't update the decor properly - all but the font(-color) stay as if unfocused. This happened to Ximian Evolution and an XTerm, but not the galeon window I was doing the same to... hmm, can not reproduce it here, but this is why I asked for testers.
Re: will stop maintaining Dutch NLS and manpage after 0.65 (was
I would like to enquire about what sort of responsibility, and what the requirements are for maintaining the blackbox manpage. I would love to assist Blackbox develop, and considering I don't have the programming knowledge (at the moment), this is a good place to start I believe. One of the long time users and commenters here Brigham Young is taking over this task. Feel free to contact him. Basically it requires solid writing skills and the ability to document things so users can understand them. You would need to keep up with feature changes, additions, removals, etc.
RE: Success: Building 0.65.0beta3 with MIPSpro
On 22-Jul-2002 Brian Hechinger wrote: it works. yay!!! ok, here's what i needed to do. first of all, set the following environmental variables: CC=/usr/bin/cc CXX=/usr/bin/CC CXXFLAGS='-LANG:std' or for more optimization (what i used on my R10K Octane): CFLAGS='-O2 -OPT:Olimit=0 -mips4' CXXFLAGS='-LANG:std -O2 -OPT:Olimit=0 -mips4' only CXXFLAGS is used. the next step is to remove '-Wall -W -pedantic' from CXXFLAGS in src/Makefile and util/Makefile, unless someone knows how to get configure to not put those in there in the first place. after that, apply the included patch, make, make install, enjoy. that's all there is to it!! I will look over your patch and get back to you. As for the -Wall -W -pedantic, search for them in configure.in. If you can submit me code that detects the compiler is not gcc and removes the flags I would be greatful. Otherwise the bulk 90%+ of the users of blackbox use gcc so it is better for the few to override than to change it for the many.
RE: will stop maintaining Dutch NLS and manpage after 0.65 (was
I will update for 0.65 on Monday! But after the summer I'll be starting a freesoftware project under KDE, so i'll switch (for some time) to KDE as default desktop (to learn more about it). enjoy (-: To make all my spare programming time available to the new project next year I would like to hand over some little things to someone else. I'm looking for: * a new Dutch NLS maintainer * a new Blackbox Manpage maintainer! please email me personally after around Aug. 1st 2002, because I will then unsubscribe from the list (if I manage to do so:-) I wish Blackbox and you all the best, and I'll really come back to Blackbox after some time!! Wilbert let me publically thank you for your effort. You revitalized the nls support in blackbox and your docs have really helped people learn and use the window manager we all know and love. I am sorry to see you go but at the same time I understand that only through change can we grow. Good luck where the winds take you. Mr. Brigham Young has agreed to take over the man page work. I hope everyone helps him as much as they help me. We still need a Dutch nls maintainer.
Re: Success: Building 0.65.0beta3 with MIPSpro
I will look over your patch and get back to you. there are really only two changes that were made, first, '#include cstdlib' was removed since MIPSpro doesn't use it, and second, std::abs() doesn't exist on MIPSpro so i had to use the abs() in the C math routines, and needed to add '#include math.h' in the files that tries to use abs(). math.h is the wrong header, it should be stdlib.h (in C++ cfoo means it is the wrapper for foo.h). I can drop the std:: and use stdlib.h. As for the -Wall -W -pedantic, search for them in configure.in. If you can submit me code that detects the compiler is not gcc and removes the flags I would be greatful. Otherwise the bulk 90%+ of the users of blackbox use gcc so it is better for the few to override than to change it for the many. i agree 100%. it's not hard to edit that stuff out. if i can figure out how to get configure to cope with non-gcc, would you like me to set a define so that the MIPSpro changes in the source can be wrapped? i don't know that there is any sane solution to what i needed to do to get it all working. hopefully we can avoid source changes. However I would like configure to be able to set the compiler flags properly.
Re: a shot in the dark
On 22-Jul-2002 Roy Wood wrote: I did not bother trying to dig through the thousands of messages (-: Yesterday evening I received a mail from one of Sun's people asking me to please test under 1.4.1 beta they just released. Downloaded it this morning. I also forwarded them the URL that Roy provided me for that XML apps FAQ. Feeling much better about blackbox at this point (-: For what it's worth, I installed the IBM Java SDK on a machine over the weekend, and things seem to work perfectly with it (though I admittedly had only a little time to play with it). I suspect it is just Sun's problem yep, that is the going sentiment.
Re: [eloli@hotmail.com: Blackbox web site]
On 22-Jul-2002 Mike wrote: I don't know what the big deal is. I'd just leave it, who cares, not worth the time/thought/effort. If people are going to get all freaked out over something like this, let 'em. Cygwin is a more accurate depiction anyway so that is what the webpage now says.
Re: will stop maintaining Dutch NLS and manpage after 0.65 (was
Hmm, ok, count me in then. My first language is Dutch and my second is English, so I don't really expect any problems with it. I'll look at the current Dutch manuals to see what style they're written in (e.g. formal or plain Dutch) and I'll just write the new ones just like it. If you want me to, ofcourse ... I would like the translated man pages to reflect the content in the English man pages. So it would be best if you waited on Brigham's new version. Feel free to contact him and work out the specifics. Maybe you can help him copy edit.
RE: custom menus on a per-style basis.
On 22-Jul-2002 Benjamin Bunck wrote: Is it possible to associate a custom menu to a particular style? Ben No, sorry. The style is simply a layer of paint it does not affect the underlying structure.
RE: new bbconf release - 1.8
On 18-Jul-2002 Jason 'vanRijn' Kasper wrote: re, all bbconf 1.8 is set loose. This fixes a small buglet in the keybinding editor whereby you'd go, like, hey, add me one of them command thingeys, and bbconf would go, like, sure, dude, but wouldn't really do anything. Or something like that anway. Also, new with this release, I've gotten Congress's approval to stop building RPMs and .deb's. I've made it so danged simple to do it that it's just a waste of my time for me to do it myself. If you want a .deb, either wait for the good shaleh to package it, or type make dist-deb. That easy. If you want an RPM, type make dist-rpm. package is in Incoming should show up on the mirrors sometime on Thurs Jul 18.
Re: bbconf 1.8 configure error(libqt3 detection)
I have verified that this library IS available with ldconfig -v. Any tips on how I can get the configure script to properly detect the installed qt-libraries ? libqt-mt is different from libqt. libqt-mt is what KDE uses. Perhaps that will help you track it down. does bbconf actually use Threads or is this another piece of ancestral baggage from kdevelop in bbconf's configure script?
Re: bbconf 1.8 configure error(libqt3 detection)
I have verified that this library IS available with ldconfig -v. Any tips on how I can get the configure script to properly detect the installed qt-libraries ? libqt-mt is different from libqt. libqt-mt is what KDE uses. Perhaps that will help you track it down. xOr Isn't just libqt-mt the [m]ulti[t]hreaded version of libqt ? I have the libqt-mt.so.3.0.4 file installed and recognized by the dynamic linker.(All development files are also installed) So I should have the correct library installed. I cannot see why bbconf configure script won't recognize it. I have also tried all the --with-qt-dir=..., --with-qt-libraries=, --with-qt-includes= switches and setting the QTDIR variable. Also, there are several different symlinks pointing to libqt-mt.so.3.0.4, in the lib-dir, with various simpler names including libqt-mt.so. unless you have libqt-mt-devel or whatever your dist calls it the configure script won't find it.
Re: bbconf 1.8 configure error(libqt3 detection)
unless you have libqt-mt-devel or whatever your dist calls it the configure script won't find it. Yep, like I said, I have all the development files installed as well. (libqt3-devel-3.0.4 package). I also jsut noticed that someone has filed a bug on the same problem at bbconf.sf.net. you are missing the point. libqt3-devel is NOT libqt3-mt-devel. Their configure script expects you to have installed the mt lib and devel.
Re: bbconf 1.8 configure error(libqt3 detection)
This was intended, since libqt-mt is more commonly used than libqt. The -devel files for this however becomes funny. When I install qt from the source, I have to reconfigure teh source dir (the headers etc) to be mt or not depending on what the app is wanting that I'm compiling. Perhaps there is another libqt-mt-devel package which conflicts with the lib-qt-devel package so that you you can have one or the other installed as needed? under Debian I have both qt-devel and qt-mt-devel installed. It sounds like the configure script could be made smart enough to use either.
RE: blackboxWM website update
On 18-Jul-2002 Scott Furt wrote: To whoever out there has the time/permission to make changes to the blackboxwm.sf.net page, could you please update my link on the screenshots page to be: Scott Hurring http://hurring.com/screenshots/blackbox/ I mostly have screenshots of different styles that i either created or really like -- there are links to download the relevant styles. Thanks a ton. That'd be me.
screenshots page updated
page updated as per the 3 requests. Have a good day.
new Tracker on sf.net
I added a new Tracker to sf.net: website. Add your screenshot urls, contents adds/removes/changes, or whatever.
RE: cvs won't build: blackbox.cc:358: parse error before `'
On 18-Jul-2002 paul wrote: Subject says it all. I'm getting the source via the standard anonymous cvs instruction provided by Sourceforge: cvs -z3 -d:pserver:[EMAIL PROTECTED]:\ /cvsroot/blackboxwm co blackbox Let me know if you need more info. TIA, PM -- Paul Mackinney [EMAIL PROTECTED] I just did a fresh checkout with that command line to be sure. It compiles under both 2.95.4 and 3.1 here.
a shot in the dark
I have submitted a bug about the Java issue on the java.sun.com bug tracker. Log outputs, an example program, and as much detail as possible was supplied. No I really do not expect much in return. We shall see though. I may need those of you who can easily reproduce the problem to submit info on this bug.
after 0.65.0
When 0.65.0 is release I plan to take about a month off from blackbox hacking. As some of you have commented my level of involvement is quite high and I am neglecting other obligations. This will also give me a chance to clear my mind and be fresh for the work ahead. Bugs in 0.65.0 (if any are noticed) will be dealt with of course and dot releases made if needed. I intend to keep 0.65.x alive until 0.70 is released at the very least.
Re: 0.65.0 status
I can not recreate the licq dock issue. Anyone? What is the dock issue? I periodically use Licq and have seen no problem with it. fresh bug on the track stating that licq does not dock itself. They neglect to state a version of blackbox so this may be an old bug that is no longer affecting us. The Java issue is important however I do not see a solution in the near future. I am open to suggestions. I wouldn't hold the release on it. List it as a known-quirk with possible pending resolution. An FAQ item for now. That is my take as well.
RE: NLS - Norwegian/NO language support in Blackbox
On 18-Jul-2002 Øyvind Stegard wrote: Hi again, I noticed that Norwegian language support is missing from the Blackbox distribution. Perhaps I could do some translating, since Norwegian is my mother tongue.(If the Blackbox maintainers are interested in this) I'm afraid I would need some instructions on how to do it, since I've never translated any typical multilanguage GNU/Linux app before. (But I suspect it simply involves putting in translated strings in some preprocessor macro files or something ?) It is quite simple. Copy one of the other nls directories, da_DK is a good one. Then look at C/*.m. This is the master file with the original language text. The format is quite simple: $ #FocusLast # Focus Window on Workspace Change $ #DisableBindings # Disable Bindings with Scroll Lock lines with a $ at the beggining are tags for the nls parser. The lines starting with # are the strings to be translated. Edit the Makefile.am to reflect your language. Then cd .. to nls/ and edit Makefile.am and add your language to the SUBDIRS list. Then cd .. and edit configure.in. Near the bottom at your language to the list (please keep it in alphabetical order). Run automake --foreign --include-deps and then run autoconf. Everything should be ready for a make make install. Then send the patch to the Patch tracker on sf.net. It should only take a few hours the work is easy just tedious.
Re: bbconf 1.8 configure error(libqt3 detection)
Or you could just apt-get install bbconf (-: And settle for 1.6??? (-: I uploaded 1.8 this time last (Wed) night.
Re: bbconf 1.8 configure error(libqt3 detection)
Arg! I really thought I understood how to check that a package was installed, but apparently not. when in doubt: dpkg --get-selections|grep foo.
Re: Compiler Options
An easy way to add compiler options is to run the configure script with a few special environment variables set to the values you want. CXX == c++ compiler CXXFLAGS == compiler flags When I build blackbox, I run configure like this ... $ CXXFLAGS=-O2 -march=i586 -Wall ./configure ... The other thing you can do is go in and modify the Makefile after configure has run. my typical line is this: CXX=g++-3.1 ./configure we recently mod'ed the configure scrpt to add -g -O2 -Wall -W -pedantic to CXXFLAGS.
scroll lock patch in cvs
I just committed the code which allows Scroll Lock to disable blackbox's keybindings. It is the last option in the Config menu. *NOTE* you *MUST* do a make install or the new entry will *NOT* appear. Unfortunately this also means anyone who maintains an NLS entry needs to send me an update.
Re: intent to remove Top and Bottom Center option from slit
On 16-Jul-2002 Jamin W. Collins wrote: On Tue, 16 Jul 2002 10:18:47 -0700 (PDT) Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: Does anyone actually use either option and would miss it? Now is your chance to speak up! In most cases, I've simply left the slit in it's default bottom center location. I've never really bothered moving it to a new location. you mean BottomRight. I am referring to TopCenter or BottomCenter. Which means the slit loads in the exact middle of the top or bottom edge of the screen.
Re: intent to remove Top and Bottom Center option from slit
On 16-Jul-2002 Es Bee Ex wrote: On Tue, 16 Jul 2002 10:18:47 -0700 (PDT) Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: Does anyone actually use either option and would miss it? Now is your chance to speak up! I don't use it now but I have in the past. Why do you want to remove it? I still think the toolbar and slit should be unified. :) It is/was complicating the code, plus I always felt it created an ugly desktop. Supporting options no one uses is kind of pointless.
Re: grouping windows
On 14-Jul-2002 Gerrit Hoetzel wrote: On Sun, Jul 14, 2002 at 10:51:35PM +0200 Tig [EMAIL PROTECTED] wrote: crazy throught, no idea about programming possiblities and all that... I see this kind of thing a bit. Someone has any idea, seems resonable to a number of people, not so useful or even wanted by others. Here is my idea, what about a 'plugins' option for black box (in the future). Blackbox is that fast, light window manager you have been looking for... Plugins? Supporting plugins usually means plenty of code and probably will slow down the fast wm. Plugin support might be a nice feature, but at what cost? Modules which are compiled against the source code (just like loadable modules to the kernel) if need be. But this is again very similar to compile time options. And compile time options is what Sean dislikes... It all boils down to goals. Blackbox first and foremost is about simplicity. I like a LOT of what Havoc has to say about Metacity. Many of his comments also apply here. My stance may cost this project a few users. But then again, leaving out pixmap support for the widgets loses us users too. Every choice is a balancing act. In the end it is about what Brad and I want and are willing to code and support. Please, do not bring up plugins around him, please (-: His day job at Trolltech has forced him to code support for plugins in Qt. On the subject he has many comments not all of them fit for typing. Plugins are nifty, they solve some problems. However that is not what Blackbox is all about. At the same time do not take my comments to mean we are ignoring user requests. Much of the work over the last 8 months has been user driven and this will continue. We are just willing to say no now and then.
RE: [patch] blackbox-0.65.0beta2 anti-aliased fonts
On 15-Jul-2002 Mike wrote: Hey, I updated Johannes Winkelmann's 0.65.0alpha2 aa patch, originally from http://www.hta-bi.bfh.ch/~winkj/. Works pretty well :) 40k is a bit much to send out to a list I figure, so just grab it from my site: http://www.gozer.org/c/c/blackbox/blackbox-0.65.0beta2-aa.diff Mike AA support will be interesting. I know people want it but it is XFree86 4.x specific. Which means more ifdefs. Brad also believes AA is a crock and a waste of time. Personally I have not seen much benefit either way. This is something I plan to look at after 0.65.0 is released. xOr has a nifty approach we may consider using.
Re: alt and ctrl hotkeys
On 15-Jul-2002 Martin Egholm Nielsen wrote: But since neither of them (Shaleh and Wilson) seemed very thrilled about that one, I just came up with a another suggestion... Don't include me in that... I support the idea of changing it at compile time. Sure, but did Shaleh's suggestion apply to compile-time? I read it as a runtime feature... Regards, Martin Options: full runtime user config runtime on/off toggle minimal user config compile user config compile time disable It is just as easy to make the option for disabling a runtime choice so the compile time is not really a valid option. If I go with the minimal config people will want more options so it is also not really valid. As been stated both Brad and I dislike compile time options. They lead to difficult debugging, make it hard for binary distributors, and in general can be runtime choices with slightly more work. Some items must be compile time. Anti-alias support and shape support for instance because they depend on support in XLib. So we do not consider this an option. That basically leaves the simple toggle idea -- hit Scroll lock and alt+mouse bindings are ignored -- or we have full runtime options like waimea. At this stage in the game I am willing to add the simple toggle. The runtime options may be reconsidered if bbkeys (or an equivalent) is placed inside blackbox.
Re: grouping windows
given that i started this thread i think it's time for me to apologize for doing so. :) this is a common issue on the list, do not feel bad. Basically we have two main groups of people. There is the old timer who has used blackbox since before 0.50. They like it just like it is and fight against any change. Then there is the recent convert. He remembers some whiz feature from his last wm and thinks it would be nice if blackbox had it. Often either the hackers (Brad and I) or the users and sometimes both disagree. Occasionally the idea has merit and is either added to the wishlist or coded promptly. Blackbox's goal is not to be every other wm. There are so many out there because each one has its own merits and reason for being. We are happy pointing people to another wm when they are unhappy if that means not compromising blackbox. This is not always popular and sometimes leads to discussions. I have no problem having them. It helps all of us establish what we want and what we don't. Not everyone hear may know this but my hacking roots are in the Debian project. LONG discussions are something I am very accustomed to. They don't bother me. It is not very often I take anything personally. My opinion about open source hacking is quite simple. Bugs reports are great. Do not berate someone for submitting them, thank them. I always try to. User feedback is similar. Even if I 100% disagree and have no intention of doing what they ask it is important that each person have the ability to express any issues or desires they have. My stepfather always tells me acceptance does not mean agreeing. Wise words. Sure some people will laugh and others will send flame. Such is life on the Net. As project coordinator I always try to remain calm and explain my rationale. As I like to tell xOr, an argument is never truly over with me. Give me real, valid reasons and explanations and I can be swayed. But also expect me to give you equally valid reasons against. To wrap up, what I am trying to say is I hope no one on this list is ever discouraged from voicing an opinion or idea. It may be subsequently shot down but at the same time we just might think it is brilliant. And Matt I may bitch and complain about your little bugs but I appreciate them just the same. In fact I now have a special style which has ugly borders just to test out proper pixel positions from now on.
Re: grouping windows
On 15-Jul-2002 Ciprian Popovici wrote: Quoting Sean 'Shaleh' Perry [EMAIL PROTECTED]: Give me real, valid reasons and explanations and I can be swayed. But also expect me to give you equally valid reasons against. Which reminds me :) that none of the messages against window tabs have provided any arguments. In certain cases (like using Gimp) I still say they would be useful. They provide a way to save desktop space. Well? Ciprian Popovici Not only no, hell no. (-: I did not make that comment earlier in the thread. As for why. Mostly aethetic reasons. I do not find the tabbing method attractive. Beyond that most people I have talked to who stopped using fluxbox listed tabs as a feature they disliked. In fact the person who started this thread is opposed to them. It seems tab users like flux and move there but the opposite is also true, those who dislike tabs do not often remain flux users. So I would rather send people who must have tabs to flux and take the flux users who do not want them.
Re: [patch] blackbox-0.65.0beta2 anti-aliased fonts
If this could be wrapper into a separate class, the #ifdef would be in one place only and therefore not really disturbing the source (except for the font code). Plus it would simplify the rest of the code a bit by remove some duplicated code - even if you don't plan to implement AA support for now. yep, BFont coming your way (-:
RE: Yet another *tiny tiny* feature suggestion
On 15-Jul-2002 Øyvind Stegard wrote: Hi there I know many people here oppose most new feature suggestions, and I understand, I think most Blackbox users will agree when I say that we don't won't a bloated and big wm. That being said, I would still like to point out a little issue that I have encountered: When working with maximised applications there is nowhere to right click to open the Blackbox menu. So I must either resize the current application(and possibly others underneath it) or change workspaces and open the blackbox menu there(where some desktop space is visible), and launch whatever I need. How about a possibility of making a keybinding (with bbkeys) that will *only* bring the menu up (in the middle of the screen or something), nothing more. No key navigation or anything, I can use the mouse after the menu has become visible =). It would make things a bit easier and shouldn't require much code (?) to implement. post 0.65.0 there will most likely be a away to access the root menu via the toolbar which will assist those running in rootless mode.
RE: Solution of Framemaker on Linux/blackbox
On 15-Jul-2002 Marco Fioretti wrote: FYI, this is the conclusion of the story. Any comment/explanation/ further trick arer appreciated, as I confess I don't understand completely why the solution below works. It sounds like FrameMaker was designed for Solaris where the X server is always running in 24bit mode. Simply having someone change the X setup on your machine so it ran in 24 instead of 16bpp mode would have fixed this. An X developer must support each color depth on their own or via the toolkit. Applications which handle graphics often took this time on only bit depth because of the work involved. Raster's imlib that E uses has a substantial chunk of code which internally maps everything to 24 bit then renders it out in the actual bit depth of the server.
RE: Screenshots
On 15-Jul-2002 Derek Cunningham wrote: Could the website maintainer (Shaleh?) please update the link to my screenshots. I've included considerably more info here: http://www.nosleep.ca/screenshots.html Which will answer the 2 or 3 emails I receive each week. :) On my todo list.
RE: ScreenShots... too
On 15-Jul-2002 Reinaldo Nolasco Sanches wrote: http://slackware.linuxbr.org/ss.jsp but this eventualy can change... ...put in BlackBox site :) yours too.
Re: Emulating a right-click on the root window
1) you typically won't want to send i've just clicked the lmb, but show me the menu. for this to work, blackbox would have to have keybindings, which is not the case... kinda chicken and egg. That is the preferred solution, but there seems to be lots of resistance to the idea, despite a lot of user demand. Though maybe if we keep whining long enough Mom and Dad will take us to Disneyland. :-) not resistance, just not this week. My first goal is to get 0.65.0 out the door. There have been no instability reports lately. After 0.65.0 is out the next step is netwm support. Once this is fully working then we move on to library separation. In here we also have the bbtools rewrite -- pager, keys, etc. Once all of this is working features can start really being considered. In the end I believe key bindings will go back in the wm. However as you can see from the above list that won't be for at least 6 months. The next question will of course be how can I help. What we need right now is people abusing the wm to find any cracks or crevices. The sooner we release 0.65.0 the sooner the fun stuff begins.
Re: Emulating a right-click on the root window
On 15-Jul-2002 Es Bee Ex wrote: On Mon, 15 Jul 2002 11:38:00 -0700 (PDT) Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: Once this is fully working then we move on to library separation. In here we also have the bbtools rewrite -- pager, keys, etc. Do you have an outline of blackboxlib or some documents(even a draft) on it that you can share with the list? It sounds very interesting to me. It is something we know we want but have not worked on heavily because of our focus on 0.65. In simple terms we are taking all of the classes the bbtools borrowed and making a library out of them. On top of this we will help the bbtools standardise the class that John Kennis and others created. The obvious objects are: menu timer BaseDisplay (which will be broken into a wrapper for Display and then event loop) Image and ImageControl i18n there will most likely be something like a BApplication class which any program would subclass kind of like KDE and other OO libraries. The goal is to provide for SIMPLE programs like bsetroot or any of the bbtools. Not a text editor, email application, etc. I do not see the need in creating a new GTK+ or QT. But it should be really simple to create something like bbweather and the tool authors should benefit from sharing their classes instead of doing code maintenance on borrowed objects.
Re: Yet another *tiny tiny* feature suggestion
On 16-Jul-2002 Marc Wilson wrote: On Mon, Jul 15, 2002 at 11:27:11AM -0700, Sean 'Shaleh' Perry wrote: post 0.65.0 there will most likely be a away to access the root menu via the toolbar which will assist those running in rootless mode. The version of blackbox provided by fink has had this forever. You can access *any* of the menus via the taskbar. Right, various versions of this patch have been presented. I believe adding some version of this will be beneficial to sections of the user base.
Re: alt and ctrl hotkeys
Myself, I use Mod4Mask, which is the Windows key on your average keyboard. Shaleh, is there some reason this can't be added to configure as a changeable option at build time? It gets asked a LOT. I do not want to add any compile time options. Giving people the ability to disable blackbox's bindings while working in specific applications covers more of this need than simply changing the keybinding would. Just abuot any binding chosen would conflict with something.
Re: alt and ctrl hotkeys
On 14-Jul-2002 Marc Wilson wrote: On Sun, Jul 14, 2002 at 09:48:05AM -0700, Sean 'Shaleh' Perry wrote: Giving people the ability to disable blackbox's bindings while working in specific applications covers more of this need than simply changing the keybinding would. Just abuot any binding chosen would conflict with something. I disagree. It's far less consistent to expect people to remember which application uses what for a modifier, and then expect them to remember that for THIS one, they need to use a disable, and for this one over here, they do not. so far most people are not hampered by the keybinding. So far I have heard gimp, Maya, and emacs with a mouse (which is a sin anyways (-:). Disabling it seems the best choice. Otherwise you can edit the source as you suggested. Not to mention what happens when you enable the disable, and then forget to turn it off later. I shouldn't have to do the idiot-level thinking. That's what the computer is for. It seems oh right, this binding is interfering -click- ah better is less idiot level thinking to me. But as with all interface issues there are always lots of opinions on the right way.
Re: grouping windows
On 14-Jul-2002 Ciprian Popovici wrote: Saturday, July 13, 2002, 7:43:43 PM, Sean 'Shaleh' Perry [EMAIL PROTECTED] wrote: On 13-Jul-2002 Roman Neuhauser wrote: Sorry if this is a complete nonsense, but is it possible now / after some coding to have blackbox treat several windows as one? it is technically possible, but the implementation is not simple. How would you select the each window to be part of the group? unselect them? How would you give a visual notification that these windows are selected? I believe fluxbox implements such a feature by using tags (similar to browser pages tags) to group windows together. However, I also believe that only one window in the group is visible at any given time. It may or it may not be what Roman wanted. yeah, you group windows of the same type together, only one is visible. Just like web pages in a browser. Sean, what are your thoughts on this tag-grouping feature? Would it be hard or awkward to implement? I think it could prove useful in certain occasions. The window tabs feature. Brad and I really dislike it (-:
Re: alt and ctrl hotkeys
Ok, then how about offering the user the opportunity to disable keybindings on a given workspace?! sorry, it would be hard to get it per workspace.
Re: start app in specific workspace
On 13-Jul-2002 Robert wrote: Having just installed bblaunch, I notice some misleading messages $ bblaunch -s -w 4 pan # no errors $ bblaunch -s -w 5 pan Warning: XGetCommand can't allocate enough memory Yes there is a workspace 5 and it starts anyway (in wksp 5) Also bblaunch -w 4 emacs -q Warning: XGetCommand can't allocate enough memory and it starts in the current (not 4) workspace I have supplied the author with patches for this. Basically the man page says if XGetCommand returns 0 it means there was insufficient memory. In fact it returns 0 for ANY error, including the window having no WM_COMMAND set.
Re: Blackbox/GNOME conflicts
I didn't know about openbox. In the office I have stock RH 7.2, which doesn't have gnome 2 has it? I'll try it at home, though. openbox is a fork of blackbox 0.62.1. They basically did a lot of the same work as the 0.65 series (STL, cleanups) as well as new stuff -- netwm, wheel mouse, etc. The person working on it also hacks on blackbox with Brad and I so openbox ends up being a test bed for ideas that slowly percolate into blackbox proper. If you find a patch I have/will not include there is a good chance it is in openbox. So basically if you want a specific feature not in blackbox and going over to fluxbox scares you then openbox may be then solution until blackbox acquires your feature. Currently netwm is a strong reason to try out openbox for some people.
Re: new NETWM key grabber
It would still be nice to have Blackbox support showing the menu in response to a bbkey event. It would also be nice to have Balckbox support navigation of the menu via the arrow keys. There seems to be a lot of resistance to doing this in Blackbox though. Whatever. the goal is to support only the netwm and not have a proprietary protocol. There is no allowance for menu hooks in the spec. Supporting key control of the menu is a sufficient amount of code that we might as well not have bbkeys or epistrophy and just move the bindings into blackbox. Then we run into I can configure everything but XX in blackbox, why not? and we end up making all of blackbox user configurable -- blam, we have left the land of minimalism and sleekness. Perhaps this path will be taken, but it is not on the map at this point. Oh-- another thing I discovered was that X has an XKB module that supports using the keyboard as a mouse anyway, so this is all probably unnecessary (thought still kinda fun). yeah, but try to use it (-:
RE: grouping windows
On 13-Jul-2002 Roman Neuhauser wrote: Sorry if this is a complete nonsense, but is it possible now / after some coding to have blackbox treat several windows as one? It would've saved me a few seconds (and writing this email :) right now if I could somehow move several windows across the screen at once. it is technically possible, but the implementation is not simple. How would you select the each window to be part of the group? unselect them? How would you give a visual notification that these windows are selected?
RE: bbmenu? [Was: Re: new NETWM key grabber]
Why not take out the menu and call it bbmenu? It could have its own keybindings or be incorporated with bbkeys somehow. Doing this you would have to let people decide for themself (probably in .blackboxrc) what a right-click on the background should start. This may be a bad idea, I don't know. Once the bblib is available the menu code from blackbox will be public. Someone could easily implement this idea then. Removing menu support from the wm is plain wrong and won't happen. However there is no reason you can't use a 3rd menu app and just ignore the one in blackbox.
Re: bbmenu? [Was: Re: new NETWM key grabber]
That is in fact how oroborus (an even more minimalistic window manager than blackbox) has always functioned. It provides no menus internally. sawfish too, and others. Personally, I believe a wm should be usable without 3rd party additions. Not 100% how we'd like, but usable.
RE: alt and ctrl hotkeys
On 14-Jul-2002 neuron wrote: Posted this thread on a messageboard not related to bb, and got in reply that I may wanna try this mailing list, so I am :) running Maya on linux is SWEET, but .. I can't seem to get it working well in my favorite window managers. not the first time this has come up. It is a little annoying currently and is actually the oldest bug in the sf.net Tracker on blackbox. Before I took over maintenance of blackbox it had a feature where if num, scroll, or caps lock was on the blackbox key bindings would not work. People complained about this because they liked num or caps lock. I am considering adding this back in as an option in the config menu. Comments?
RE: Java dialog problem encountered in other apps
On 12-Jul-2002 Øyvind Stegard wrote: Just wanted to point out that I just experienced the dialog problem with LimeWire running JRE1.4.1 from Sun (the newest, as far as I know). Problem does not seem to be specifically related to just JBuilder, but perhaps it's worse with JBuilder than other Java apps. --- ØS. nope the problem just seems limited to commercial Java apps (-: Two people have given me demo apps which open at odd sizes SPORADICALLY, like 1 in 5 or 10 opens.
Re: call for help -- need Java programmers
I expect the output to look this (non Java app) 0xe048ec: before manage (259, 172) w: 800, h: 600 0xe048ec: initial (259, 172) w: 800, h: 600 0xe048ec: after hints (259, 172) w: 800, h: 600 0xe048ec: sizes reflect the frame from now on 0xe048ec: after upsize (0, 0) w: 802, h: 619 0xe048ec: after gravity (259, 172) w: 802, h: 619 0xe048ec: after configure (259, 172) w: 802, h: 619 0xe048ec: end of constructor (259, 172) w: 802, h: 619 0xe048ec: just before show (259, 172) w: 802, h: 619 You seem to be missing most of the debug messages, did you only apply the verbose2 patch?
Re: Java dialog problem encountered in other apps
On 12-Jul-2002 Jamin W. Collins wrote: On Fri, 12 Jul 2002 15:23:53 +0200 Øyvind Stegard [EMAIL PROTECTED] wrote: Just wanted to point out that I just experienced the dialog problem with LimeWire running JRE1.4.1 from Sun (the newest, as far as I know). Problem does not seem to be specifically related to just JBuilder, but perhaps it's worse with JBuilder than other Java apps. The problem is most certainly not specific to JBuilder. I think Shaleh's on to something with his previous statement about system load. I suspect that JBuilder puts a decent load on the system during it's startup (haven't used it specificially). -- Jamin W. Collins I just wish I could see the swing/awt code. I'd probably sign a NDA right now. Java windows appear to start at arbitrary sizes and then control everything via hints, often changing the hints right up until the initial window manager display. It is most peculiar. When I have time I plan to experiment with writing test apps that act like Java windows. Will see what that shows us. All I can say is, man, Java is weird.
Re: call for help -- need Java programmers
Let me parse this for everyone, so they can understand my frustration. 0x28000a9: fallback configure (0, 18) w: 1012, h: 783 we received a configure notify BEFORE we had managed the window, so we blindly applied it. The numbers printed are the ones from the configure event, no tweaking. 0x28000a9: before manage (0, 18) w: 1012, h: 783 this is the value of the window hints before we call the BlackboxWindow constructor. Again, no interference. 0x28000a9: initial (0, 18) w: 1012, h: 783 this is the value of the window hints checked again by the constructor, still no touching on our part 0x28000a9: after hints (0, 18) w: 1012, h: 783 we have read the wm_normal, motif, and other hints, no size changes occur here 0x28000a9: sizes reflect the frame from now on 0x28000a9: after upsize (0, 0) w: 1018, h: 812 we apply the window manager frame to the client 0x28000a9: after gravity (0, 18) w: 1018, h: 812 we apply the window gravity to the frame 0x28000a9: after configure (0, 18) w: 1018, h: 812 we call XMoveResizeWindow() using all of the settings from above 0x28000a9: end of constructor (0, 18) w: 1018, h: 812 at this point we have checked for transience, applied any hints, etc 0x28000a9: just before show (0, 18) w: 1018, h: 812 show() is what actually displays the managed window and frame 0x28000a9: change request (0, 18) w: 1018, h: 812 we received a ConfigureRequest 0x28000a9: normal hint (0, 18) w: 1018, h: 812 0x28000a9: normal hint (0, 18) w: 1018, h: 812 we received new WM_NORMAL_HINTS As you can see, everything looks kosher. The window size is not what the user expects though.
RE: Java Dialog Goofiness - How Can I Help Now?
On 12-Jul-2002 Roy Wood wrote: There's been lots of discussion on the problems with JBuilder/Java dialog problems, but I've lost track of what I can do next to be of help. Anything I can do at this point? I've got a box here running JBuilder 6, and I'm ready to help out. -Roy I am going to spend today doing my real work (getting paid). Will ponder this and attack it as best I can. What would help is someone finding an open source Java app or three that demonstrate this problem consistently. Since the programs reported so far require purchasing and ownership I am unable to do extensive tests here. Being able to read the Java code of the app would help so I can see what they expect to happen. Another plan of mine is to add similar debug info to another wm, possibly twm. This way we can see how the two differ more easily.
Re: Java dialog problem encountered in other apps
All I can say is, man, Java is weird. It's not weird, it's advanced (little humor from the Debian list) =^). (-: Isn't the source for the Blackdown implementation available? Looks like it is: http://blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux-8.html #ss8.4 I could not find it on their ftp site, I do not believe it is. Perhaps we could see if the Blackdown JRE can reproduce the problem and then riffle through the source? no, i can not reproduce this with your DemoApp under JRE 1.3.1 from their site. deb http://ftp.gwdg.de/pub/languages/java/linux/debian/ woody non-free apt-get install j2re1.3
Re: call for help -- need Java programmers
On 12-Jul-2002 Ben Jansens wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 12 July 2002 11:35 am, Sean 'Shaleh' Perry wrote: Let me parse this for everyone, so they can understand my frustration. 0x28000a9: fallback configure (0, 18) w: 1012, h: 783 Does twm not pass this along? It'd be interesting to knwo what the dialog's size is before this event is applied to the window... twm, E, wmaker all apply then event in the same manner we do, nearly the same code. Passing this event along is required by the ICCCM by the way. What it looks like the java code is doing is this: XCreateWindow(display, dummy_x, dummy_y, dummy_w, dummy_h) XMoveResizeWindow(display, window, real_x, real_y, kinda_real_w, kinda_real_h) // delay XMapWindow(window) I say kinda_real because the values change for some of the programs.
RE: stay on top feature
On 12-Jul-2002 Gerrit Hoetzel wrote: Isn't there still a 'stay on top' feature for normal windows missing ? read on, only if you are realy interested :-) I have to write some sentences more, so that the mail robot does not complain about a too short message. I haven't yet had a look at the source code. But code code for stay on top of toolbar and slit as well as features for lowering and raising special windows might be utilized !? It is on the list for post 0.65.0. All of the way we handle the window list needs a complete rewrite. Stickyness is a hack currently. When we are done you will have on top/bottom and real sticky windows.
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. 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.
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: 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: 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
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
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.
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 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: 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.
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: 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: 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: 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 FR 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 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 FR 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: blackbox + sylpheed behaviour
but the window will also be moved down and right (exactly the borderwidths of title bar and left border). When calling sylpheed repeatedly, its window moves down all along. I think it's a bug in the sylpheed code, but maybe related to blackbox. Sylpheed is sending us a configure event with a new x,y location. We respond to this event and move the window. 100% according to the ICCCM. The same behavior occurs in wmaker and I believe twm. E on the other hand will not show this problem. E is taking the allowed stance of I am a window manager, I can ignore hints. The problem is the window manager is required to treat a configure request just like a first mapping, so we have to apply the window gravity to the event. If sylpheed really wants to position its own windows it needs to use StaticGravity. The real answer to this bug is they need to stop sending useless configure requests. The only request they need to send is an XRaiseWindow() or the gtk equivalent. Wilbert, since I am not on the sylpheed list please be sure this makes it to them.
RE: new beta
On 10-Jul-2002 Sam Halliday wrote: hmm, you wanted testing of the new beta2... after use for ~24hours (well, not all use... a night of it doing nothing and a day of work) i noticed that slide bars under all my apps stopped working correctly. the apps were using various toolkits, gtk+ , xlib, motif the usual. i dont see how anything i could have done would have globally changed the default slider action. The mouse selction of text also went a bit funny too. slide bars under all my apps, can you explain this more? Provide a sample app that shows this issue?
Re: new beta
On 10-Jul-2002 Sam Halliday wrote: slide bars under all my apps, can you explain this more? Provide a sample app that shows this issue? well i think scroll bar is the technical term, but it escaped me at the time... it happenned under nedit, xmgrace and sylpheed-claws, the main windows. i exited X and came back into blackbox and all is fixed, ill let you know if it happens again. a screen shot would also help. The command 'import' in the ImageMagick suite is a good one.
RE: building blackbox with MIPSpro
MIPSpro does not honor the C++ thing where variable scope is kept withing a for loop (for example) and so in the instance where the same variable name was used twice in the same function within seperate scope, i had to change one to be different so that MIPSpro could cope. would i be asking too terribly much to ask that the the variable scope rules meet that of plain old C so that blackbox will cleanly build on SGI kit using MIPSpro as the compiler? there were only, i think maybe 4 or 5 instances of this happening, so it's not a terribly huge undertaking, and would help out tremendously thouse of us who like to use MIPSpro. that is so amazingly lame. lame. lame. I will accept a patch (diff -pru) for this. However I can not promise we will not forget to follow this in the future. You should contact the compiler vendor and inform them the year is 2002 a.d./ c.e./whichever and there is an ISO C++ standard they should be following.
