diabol's todo/wishlist

All these relate to https://github.com/x...bclean-xzero450 as xzero and mojmir have already moved bb a great deal into the direction where i've been meaning to take it (slooowly )

Anyways, I'm not an eye-candy person, but I do love small neat features and as a dev person this is a cross between a todo and a wishlist

0) merge bbMean changes into bbclean-xzero on github

Good thing I didn't change so much!

1) cmake: 32bit parts in 64bit bbleanskin's build (engine, wrapper process).

I'll probably fix this myself soonish, but frankly this will be my first time working with cmake, soooo got some reading up to do.

mojmir is on it

2) bbleanskin: option to set transparency in right-click menu

I've been meaning to add this for ages and it wouldn't even be hard to implement.

To draw the menu, bbleanskin gets the systemmenu items and attaches them to it's own menu which shares the same code as the other menus, so attaching an up-down item for transparency of the current window (as is done in so many other places in bb's menu already) wouldn't be hard.

3) bbMeanPlug32 - 32bit plugin host and/or plugin wrapper

Wouldn't it be nice to just load some old and forgotten 32bit plugins in 64bit bb?

I'm thinking of creating a dummy blackbox32 executable which acts as a plugin host. It would communicate via a named pipe or similar with the 64bit blackbox host.

Now I am not sure how much work would need to go into synchronizing the instances and other issues like hosting a 32bit plugin window in a 64bit slit might occur.

Another possibility would be to individually wrap the plugins in a 64bit adapter which does basically the same, but still I am not sure how well that would work since in bb plugins and the main like to merrily pass around pointers to window handles and the like.

Will need to investigate this further..

4) code documentation/cleanup

If you had a look at blackbox' code and a look at litestep's code then you will get what I mean

Seriously, it's hard for new developers to get into blackbox development because the code is not extensively documented.

Also the structure of the code could need a lifting. It's awesome that the build system was brought up to date. I think the next logical step would be to clean up the code, abstract away differences of windows versions and such (the current source still supports windows 95!).

5) asynchronous icon loading

I guess this is why grischka marked menu icons as experimental in the code..

To load icons for items in the menu, bb uses windows' shell api or such which has to, at least once, load the icons into it's own internal cache.

Now this happens acceptably fast for individual items (~20-100ms on my machine), but when you open a folder with many items in it, bb might hang for multiple seconds.

A solution to this would be to load the icons in an iconLoaderThread and show a placeholder while they are not available.

Similarly there is a bug which affects windows which hang themselves. BB blocks when it probes a window for it's icon. Now if the window it question hangs, it won't respond and bb hangs forever (or until you kill said window)

6) bells and whistles

I remember some neat features like a volume control from either bbClean or bbLeanMod in the main menu.

Last time I checked it was either not present or just plain broken on 64bit ._.

EDIT: anyways, moar neat features

7) litestep plugin loader

That would be totally overkill, a man can dream. (Also one of the ls devs startet work on a bbLoader for litestep some time ago, it's not really usable yet, but nice anyways)

done by Tres'ni before, should ask him for the code or sth

8) background slideshow

When you set multiple background pictures in Personalization on Windows 7+, under explorer they would neatly change with a fade out/in effect after an interval. On bb they unfortunately don't. After the time is up, the old background stays until a region of the desktop window is forced to be redrawn. Not a big bother, but would be neat if this worked correctly.

9) core menu plugin

We should totally make the core menu pluggable, as has been done with the slit and the bar.

The menu code itself is used all over blackbox and thus can't be easily ripped out, but the core menu itself could be gutted.

That would make the main codebase smaller and more maintainable (the plugin codebase is a different story )

10) bbMeanPlugNet: .Net plugin loader

It's time for a confession. I am not exactly a C++ developer - in my heart (and at work) I am a C# person and I would love nothing more than being able to create a .Net ecosystem for bb. It would open up so many possibilities for plugin developers. For instance it wouldn't be hard to create a C# plugin that acts as a scripting host and loads lua or python or ruby or javascript or you-name-it-it-probably-runs-on-the-clr-or-has-an-interpreter-ready and executes it.

Indefinitely postponed. Reason: it is super easy to write a bb plugin in C# with some C++ magic

11) bbIconBox' Pager in bbLeanBar

Simply a list of clickable workspaces, would complement my dwm-look

12) bbdMenu

replicating dwm's dmenu capabilities:

a horizontal menu which contains a list of every executable in the PATH, upon typing it narrows down

13) window tiling

not exactly a simple feature on windows.. but windawesome does it and with a .Net plugin loader a marriage wouldn't be impossible

14) vim-like keybindings (or rather bindings for key-sequences)

I am not exactly a fan of vim, but this would be even more fun for screwing with *nix people than my arch wallpaper with bb4win

15) in the far future i would like to do some crazy wallpaper magic

i would especially like to implement some 3d recognition algorithms to recover heightmaps from background images, split fg/bg and such.

based on that i would animate the desktop background in subtle ways, maybe in response to music

Ahhh, so much to do and so little time

I love them all!

By merging BBMean with the other guys' build you intend to keep spit graphics and such, right?

Two notes:

6) Volume control was always there. You can see it on the menus of all my screenshots And, thanks to XZero450, it inherited all the new style goodies - split graphics, outline text etc. Way back, some guy added a Time option on the main menu, but unfortunately you had to bring up the menu again in order to update the time.

7) Tres'ni released such a plugin a long time ago, I can look for it in my archives and upload it here, if you want me to. I tested it a long time ago and it worked with SOME Litestep modules, exactly as he cautioned...

It would be nice to have that plugin on here, if you can find it

It would be nice to have that plugin on here, if you can find it

Here it is...

 lsine.zip   76.41KB   7 downloads

Update - Just a quick summary of what I'm currently working on

bbInterface winamp album art

winamp5 has an api for album art, but from what I can tell it's hard or impossible to interface from outside,

so the safest way to get album art for currently playing items is to grab the filename of the currently playing title and determine where the album art is located, based on how winamp does it.

probably winamp has a cache where it stores extracted images, apart from that this would mean extracting the art from the mp3's id tag or using folder.jpg

.Net plugin loader

it's refreshingly simple to write a bb plugin in .Net, but it's pretty useless without access to bb's api

i am currently writing a C# wrapper to the api, since using it raw would be terribly clunky

also further investigation is required for keeping .Net gui stuff in line with bb's style

api cleanup / plugin plugins

this is probably not worth the effort i put into it, but it's terribly fun, so i'll do it anyways

i want to eventually clean out the closet and convert bb's codebase to some neat c++ code, however currently plugins depend on ~95 exported functions to be present in blackbox.exe to work (for bbclean it's less, for xoblite i don't know) and since i don't want to break existing plugins a mechanism to load them will be neccessary

also in the long run i want to support plugins for litestep and older flavors of bb, so the past day i've been looking for a way to isolate the blackbox api without creating a heap of pluginhost processes.. and have found it

the bottom line is, when a plugin-loader loads a plugin it will have to modify the plugin's library import table to redirect the api calls from bb to the plugin-loader's api. unfortunately this can't happen at runtime, because LoadLibrary would fail if the process doesn't expose the api which the plugin tries to import, so what the plugin-loaders will be doing is the following:

- read the plugin into memory (raw)

- check if it's compatible with bb's current api, if so, just load it and be done, otherwise

- change the entries in the dll's import table which point to blackbox to point to the plugin-loaders' api instead

- save it as a plugin-loader specific version (<plugin>.<api>.dll)

- load the api-specific version

another option would be to replicate what LoadLibrary does and injecting the redirected api references in memory, however the PE file format is less likely to change across windows versions than LoadLibrary (especially with the way Win9x vs WinNt load libs), so that is out of question

this relinking process of course could be done upfront and theoretically it would allow to mix and match plugins from any version of bb with any other, given that somebody writes the appropriate api modules..

Update update:

found a simpler solution: spoofing the exporting module names on-the-fly before calling LoadLibrary, so the import fixup gets redirected to the pluginplugin's api instead of the main module's

also pluginplugins are live and I am working on the 32bit loader now. surprisingly 32bit and 64bit processes can pass handles around, which makes the ipc a whole lot easier than i thought. that means the biggest problem is proxying menus and styles

Update update update update:

so far i've got the server part (64bit plugin) and client part (32bit host) initialization done.

server and client can already send messages back and forth via named pipes and the message protocol works (tho not all messages are implemented)

i've got the api ipc figured out (untypified wrapper via api annoations in the server called with a generic invocation message)

what's left is to implement the api handler thread (server side), the rest of the messages and the client-side api wrappers