First off, I'll say that I like BBInterface quite a bit. In fact, so much that I'd decided to add some features to it. That, however, is one of its problems - it has become a Frankensteinian monster. Sure, it was once human, but to improve it, parts have been taken out, and better ones stitched back. And now no one can keep it in control anymore.

Horror-inspired metaphors aside, the source code is quite a mess now, and I'm partly to blame for that. Fixing that would quite probably take more effort than redoing the entire thing from scratch - and that's precisely what I intend to do. However, with the amount of changes I intend to make, it wouldn't be very accurate to call this project a re-done BBInterface. I intend it to be a distinct plugin, while doing everything BBI did (and more), and doing everything better.

A fresh start also brings the possibility of reimagining things with itself, redesigning everything from the ground up. The best way to figure out what would actually be needed in such a plugin, I thought, would be to ask those who'd end up using it - you people. The input of plugin developers and those making extensive use of BBInterface's functionality would be especially welcome. Note that at this point I'm not looking for suggestions that are mere bugfixes or extensions to previous functionality. The question isn't what parts of BBI should be doing better, but what those parts should be in the first place.

Now, here's a feature list (in no particular order) of what I'd like to see, with explanations for each item following afterwards. Of course, the list will be expanded as ideas surface.

Component-based architechture: This is a probably the most important improvement I want to do. Instead of being a massively interdependent whole, the program should be composed of smaller, communicating components that can be developed, compiled, and configured independently of the rest. Not unlike plain blackbox plugins, except with communication not being limited to broams.
Components are described by the functionality they provide, other components they depend on, and the extension points they define where other components can be plugged in. BBI already had something similar with agents (want to handle mouse presses? Use the mouse handler agent. Want to change your volume with a slider? Use the mixer agent. Etc.), I want to expand on that concept. Ideally, for any sort of functionality you'd want you could code the component and plug it in without much hassle. Or conversely, any sort of functionality you don't need, you could just unplug.
The Eclipse Platform for Blackbox? That's the idea, more or less.

C++ instead of C: Of lesser interest to the end-user, greater interest to anyone wanting to get involved in the development, the code will now be written in C++, in an object-oriented way, making better use of STL classes. No more char*, no more handmade list implementations, and so on, and so forth. Overall, this should read to code that's easier to read, maintain, and less prone to error.

Hierarchical control structure: While you could embed controls into frames previously, this wasn't reflected in the way controls were stored - it was one huge list either way. Fixing this issue will make searching through controls faster, as well as making control naming less restrictive. That is, you can now create a frame called "Frame" and make it have a child with an identical name. The concept of modules will be retained, as a distinct unit of transportable data as well as a separate namespace to prevent name collisions.

Specialized BBI scripts instead of broams: Broams are nice in that they are universal, less nice in that they're not terribly effective, and too damn wordy in most cases. Instead of "@BBInterface Control SetWindowProperty MyFrame Width 100" you would have "MyFrame.width = 100;". Using an interpreter made for this purpose, you could also add better scripting capabilities, such as various control flow operations (loops, ifs, etc.) and context-aware commands that didn't necessitate specifying the same thing over and over again. For instance, a control creation could look something like this:

As for interaction with other plugins, you'd be able to use a broam to instruct the contents of a file to be interpreted, or just pass in the actual commands themselves in the broam.

Templated controls: Considering that most of the control types are pretty similar, just with different functionality hard-wired into them, an alternative approach would be to have more generic control types that would have different specializations. For instance, a button is simply a frame that changes its appearance on mouse down, and fires some event on mouse up. Then, you would call upon such templates to automatically specify various properties of your controls. It would also be possible to define your own templates for custom control types, to avoid having to replicate the setup process for every such control you make.

Customizable menus: Putting everything and the kitchen sink into the program allows for a wide array of functions, however, it also makes navigating excessively long configuration menus a chore. So, allowing for the user to further customize which functionality of a component he/she needs would make the menus less cluttered. There's no need to display possible actions for left, right and middle button presses and releases when you'll only ever be doing something interesting on a left click.

Dev console: A separate window, allowing for more practical input of broams and BBI-specific commands, as well as serving as an error log. Clicking through a hundred popup messageboxes gets tiresome, while turning off error messages leaves you scratching your head trying to figure out what went wrong.



...And that's it for the time being. Note that the project is currently in the pre-planning phase, meaning that it'll be months before I'll actually get some work on this done. I figured it would be useful to put it up for discussion ahead of time, though.

Oh, one more thing: the project needs a name. bbInterface++ seems like an obvious choice, but it's not exactly imaginative. Do tell if you've got better ideas than that.

(Sorry if this isn't the proper forum for this sort of stuff... I couldn't really figure out which would be. so feel free to move it if needed.)

What about bbwidget?

As for the bro@ms, I find it very intuitive that the current config is made of bro@ms. It is very easy to make changes (I have scripts that align BBI according to screen resolution for docked and undocked modes of my notebook) just by sending in broams rather than starting up another instance with a separate config. If the config will change to a more easily readable form, but everything can be controlled with sending a bro@m, it will be even better.

Would be happy to betatest.

First, i don't like idea of rewriting plugins… Almost every time when dev is saying that will rewrite something from scratch (Liam and Tresni ) it takes from a year to infinity to finish it;) But if you like, my wishes:

- pull-down menus like in GEM/Mac. Something like OnHoverMouseCursor, to which i could pin broam showing menu would be sufficient.
- unicode.
- Foobar2000 (unicode) agent. There is source of bbFooman which could be integrated.
- drag and drop of elements, like in linux panels. But this would move bbinterface++ more to be such panel than to be a interpreter of script language…
- easier possibility of copying elements between configs. Now, if i want to copy small element from other person's config it's really difficult to me.
- maybe possibility of loading tray programs as separate objects? There always will be more windows tray programs than blackbox plugins, so idea of convincing such program to think „i'm loaded into tray” is neat.

That won't be needed, actually. Sending in broams that would load a file and interpret it is still going to be an option. You'd be able to use a broam that interprets the string you passed in as an argument, say "@BBI.exec MyFrame.width = 100;". Also, edited the first post for clarity.


When there'll be stuff to betatest, sure. Anyway, I don't really see a point to limit access to test versions, except when they're not easily usable by your average end-user.


Well, if it's gotta be done, it's gotta be done. Still, I'd say this would be the faster way. We'll see, I guess.


I'm not seeing what you're getting at here, as I don't use linux regularly. Care to elaborate a bit?


How is the support for modules and the "Save this control as..." function lacking for this purpose?


Customizable menus should arise naturally from the modular structure of the program, though I know I won't fiddle around with them too much as long as other stuff needs doing. As for the Dev Console, it'll have to be done early on - there's not much of a point to adding an easy way to detect errors after I've fixed them.

Panels have more predefined and ready to use elements. You can just d'n'd them from list like this:

Maybe bbInterface++ should have such list with few modules in-a-box? I know that even more now is in the „Control Options” menu, but list look more user friendly.
Personally i don't see much (ready to use;) modules now… „Save this control as...” looks promising.

SPHERICAL OBJECTS!!!!! Ok, I think that was loud enough.

Warning: This post is completely off-topic, you have been warned.


Who? Me?

You're correct, I do take forever to do that stuff but there is a reason (actually a few of them.)
First and foremost is called Real Life I am a full-time student, father, and part-time IT Manager. That means that M-F between the hours of 9AM-7PM, I'm not home. On Wednesday and Thursday make that 6AM-7PM as I do my teacher observations on those day, Monday & Tuesday I don't get home till after 9PM normally. This will only get worse next semester when I student teach and will be away from home 6AM-7PM M-F with obligations Monday nights still. As it stands I never really see my oldest 2 kids.
Second, I don't use bb4win on the day-to-day. I help out here and there, beta test xoblite on request, etc, but day-to-day, I use Explorer. Don't have time to fiddle with shells.

So because of those 2 reasons I tend to prioritize what I do based on time w/ family, what I actually use, and then what looks fun or will increase my knowledge. While bb4win and the plugins fall into the last of those categories, I have other stuff that I am working on that takes precedence. So normally bb4win only gets a look when I'm either really bored or really frustrated at everything else. Then I'll spend 2-3 days hacking on shit and call it good for 6months - year.. That's just the cycle

So, sorry about all the wait for my stuff. It's why I normally make source available too, that way someone else can do it

If can, would you mind to let the interface support PNG transparent and mouse over even effect (sorry for my English)?
The magic pink is really terrible when we want a good effect.

I've got another idea for a name...
BBKing

(since BBI is the king of blackboxplugins)

I'm happy to find this post!
If you can make something that would replace bbInterface you'll deserve a monument in your hometown I hope that you'll blow upthe community with it.
But hopes, hopes...

Ok some ideas:
Semi-transparencies is really great stuff, but I suppose it's rather hard to do, and rather far from BB minimalism...
I'm trying to get to work bbFooman plugin to make some alt small interface for my big combine Foobar2000, so transparencies would be VERY helpful, but now I suppose we can't make even custom-transparent buttons (ff00ff) on one frame?! (if I'm not mistaken)
The second thing I think would be helpful is _delayed_ autohide\autoshow, so we won't see our panels in the games accidentally.

...oh almost foggoten. ^) I was surprised when I realised that I can't (kinda stupid sentence *) make text written on sliders, could be useful for volume...

As for the name,,, maybe some kind of [bbJoint]...

That's all my ideas for now. pkt-zer0, I count on you dude 8D

I agree with ClockworkB transparencies is one thing is in need. That pink color that appears when you use style none is terrible.

B B king?

That was the idea, yeah...
He's a great musician! (been listening to "When Love Comes To Town" by him and U2 when I came up with that one)

Yeah, you can sort-of do that with modules, too. Modules have the limitation that only one instance of a module can be loaded at a time, but templated modules is something I could see being added, too.
That there aren't many pre-packaged modules available currently might be due to the fact that, I believe, few people are familiar with the functionality at all, and that there isn't really a place to share them. The former issue could be solved with this new plugin having this functionality right from the start, and the latter issue is something I intend to address in the second half of my glorious master plan for world domination.

Two things.
1) Yes, I know about the magic-pink-where-there-should-be-none issue, it's basically the single most requested bugfix.
2) When I said this:

...these are the sort of suggestions I referred to as unneeded. The reason for that is quite simple: they aren't going to be relevant for quite a while. Bugfixes are pointless without bugs to be fixed, and now there isn't even any code to be bugged. Extended functionality would be pointless because the groundwork for them needs to be there in the first place.

So, I was thinking of suggesting more fundamental things instead. For instance, staying with the window display aspect, the window drawing part could be separated from the rest, so it could be changed independently. Say, some guy could write a DLL that allows controls to be displayed as 3D shapes using Direct3D acceleration. And to use that, all you had to do was loading the plugin and changing your references to Window objects to 3DWindow objects, or something similar.
Yes, the example is a bit far-fetched, but I hope you get the basic idea.