There are a few features that - despite many months work - did not make it into bb4win_mod 1.18. Some of these have been widely trailed. Others have not.

There will continue to be a number of "under the hood" changes. This will include incorpration of the "cybershadow" anti-crash patch, which did not make it into bb4win_mod 1.18.

Once the initial set of features has been released, future versions may well be on the same kind of timescale as xoblite.

I welcome this new build, mostly because it’s promising a lot for the near future – well, as near as unkamunka can make it happen when he gets back from his 10 day hiatus. It crashed on me a lot, when experimenting with different plugins (sometimes even using plugins that should work under this shell, like unkamunka’s own bbleanbar 1.25) or even when right clicking on various elements. I really enjoyed the style syntax options, though curve isn’t working the way I supposed it should and it didn’t create a “glass” effect. I guess same names mean different things to different developers – one of the things ALL devs should agree on.
There are a zillion things I liked here. The “Kill” feature is excellent, for instance. And, like I said, style authoring is much more meaningful now – though the new syntax underlines the fact that some older plugins, like bbslit or bbpager, should be rewritten – unless you like garish colors
What I didn’t like has to do with the (much augmented, I have to admit) menus: I really love icons on the menus and their absence takes some of the glitter off. Also, the absence of volume on the menus takes out some of the usability AND styling options and I would very much like to see them both back. I also believe an “Edit Current Style” option should be added to the editing menu features. There are other thing missing too, which I think could be taken care of if some of us had the chance to test this build. All in all, this is a great interim build and can’t wait to see what this may develop to.

• 
• Certain components of bbSystemBar (very unexpectedly) cannot handle clicks on WinXP & Win2k (but are ok under Vista) TBA
• a list of problematic plugins (& problematic bbInterface syntax) would be most helpful.

• The lack of a "glass effect" is probably a side effect of grischka's having customised the color engine for something far less 4 specified colors.
• One of the purposes of having a "gradients only" release was to move syntax issues forward before someone - don't look at me ATM - takes up the rewrite of bsetroot.exe. It is quite possible that the "Over" & "Down" elliptical gradients may prove to be more of a possibility for backgrounds - rather then, say, menus. Both would almost certainly render more correctly using a different colour engine.
• It seems that perhaps you prefer the Split gradients to extend over the much larger range that - unintentionally - is generated by grischka's colour engine. If so, & there is general demand for this, then both syntax & parsing need to be set for this.
• It almost certainly possible for a colour engine to be hived out into a library that could be used by all shell devs - but this would be Core (menus, toolbars etc.) only. bbWinSkin, however, was thoroughly unco-operative in working with such a library.

• The "kill" menu code was originated by Alex3D & reflects clean-up by nocd5 and unkamunka. A tip of the titfer to Crowmag for (indirectly) pointing out the right name.
• bbSlit has long needed a update. tresni's version does not include puzzle-positioning & grischka's version has configuration bugs. There is also the lack of separate syntax support - (grischka's version has it, tresni's does not).
• There was definitely a gradient issue with bbPager - which is an outflow of the "grischka colour engine" issue mentioned above - nothing to do with bbPager itself.

• xoblite & bbLean users - which is where most of the new users of shells like this at present come from - seem to be quite happy without icons.
• The menu icons code that is around is mostly either resource-intensive or End-User labour-intensive. Something that strikes a fair balance appears to be needed & will appear when it is ready.
• ATM there is code that disables the drawing of any Volume Control if the user is running Vista (or later versions of Windows). OTOH leaving VolumeControl out altogether reduces resource use markedly - on all platforms.
• A Style is a priceless piece of art & should not be readily made available for tinkering by any old EndUser. "Edit Current Style" (will have) migrated to the Windows|Bro@ms menu - along with all *3* About boxes. A Style (hopefully) does not affect functionality. Although it could be put in an RC file, it most usually is not - yet another reason it does not belong under Edit RCs.

I am not at all clear what you are talking about here:

• Time resources are limited for us all. Some people are obsessive enough to "test to destruction". They make good beta testers. ATM the only other person I share builds with is qwilk.
• The purpose of this build was to show how "4 specific colour" gradients rendered using the bbLean-based colour engine. There was clearly long pent-up demand for this - 250+ downloads for something that is clearly (I hope) labelled *beta - not for beginners* is more than one could reasonably expect.
• To that extent, the intention was to update Style syntax, retain bbStyleMaker compatibility & expand the colour range. It would *not* have been called bb4win_mod. At the end of the day, the surgery on grischka's parsing engines was radical enough that it ceased to be an update. Given that, the name was changed & *some* fully tested bb4win_mod functionality were added. (5+ years later, AFAICS the "Configuration" menu now actually works in full.)
• The release remained primarily focused towards gradient possibilities. To me, the quality is disappointing. OTOH the upgrade of dithering is definitrely a step forward.
• IMHO one of the chief reasons that qwilk has been unable to get xoblite bb4 out of the door is the copious availability of beta testers, but that has been his decision. If he were to put up a post saying that I spend too much time Forum responses & bb4win SourceForge site issues (earlier it was the Wiki), I would not argue with him.

These comments are in partial response to a multi-topic post here:A StyleFile is not an RC. Even if it were, moving it where you suggest would make it much harder to get to. WinKey+S is the default setting for EditStyle for all flavours of bbKeys. VolumeControl requires a proper slider - way beyond the "normal" size & scope of a menu. It is resource-hungry. From Vista onwards, it requires additional software. In short, it is something for a plugin & not the core. Any plugin that wants to use VolumeControl styling will find support for that in bb4win_mod.Such a feature is possible, but is not in the present "queue".

ATM the functionality timetable looks like this:

• 1.19
  • native parsing of Openbox styles
  • further work (as necessary) on BorderWidth, MarginWidth & WindowTitleHeight
  • potential bugfix on certain Tray icons (e.g. RemoveSafely)
  • ETA October(???) 2008
• 1.20
  • menu icons
  • ETA December 2008-2009(???)

It seems that:
1.
left double click on desktop doesn't work.
I treid:
blackbox.desktop.LeftDblClick: @BBCore.ShowMenu .\menu\LeftDouble.rc
blackbox.desktop.LeftDoubleClick: @BBCore.ShowMenu .\menu\LeftDouble.rc
blackbox.desktop.DblClick: @BBCore.ShowMenu .\menu\LeftDouble.rc
blackbox.desktop.DblLeftClick: @BBCore.ShowMenu .\menu\LeftDouble.rc
blackbox.desktop.DoubleLeftClick: @BBCore.ShowMenu .\menu\LeftDouble.rc
2.
It was useful but it doesn't exist anymore
# Process Priority (EliteForce)
# 0 = idle, 1 = below normal, 2 = normal, 3 = above normal, 4 = high
blackbox.processPriority: 4

That is correct. For bb4win_mod, DoubleClick is not an option - as there are already many Click options already built in.

From the extensions.rc file That's 12 basic click options plus another 12 for the X buttons. Again, you are referring to bbClean NEB functionality - which is not the same as bb4win_mod.

bb4win_mod has a greater accent on minimalism & simple functionality. Hence, the Kill menu (under Processes) & MinimiseToTray - neither of which are in bbClean NEB.

Is there a way to use your transparency technique, but only on corners? Perhaps, paint some magic pink on a pixel of each corner and make that transparent?

You would need to be able to set the colour for corners individually - from the rest of the window. AFAIK that's not yet been discovered to be possible.

Fluxbox has had it for many years, though I'm not familiar with their method.

My reply was ambiguous. The reference was to making rounded corners on M$ Windows. Doing such things on *nix - in this case - is a completely different issue........

I know someone who has done it with a bb4win branch, at least alpha blended corners. They've yet to release it though. Supposedly it only took about five lines of code.

I shall not bug you on this subject any further