Ok thank you for this, I look for this in forums, but doesn't get anything. This link must be added in noccy's bbCLean N.E.B topic as I think. Big russian thanks for you.

*edited*
Ok, I look in source of last version and saw that noccy start to work for adding unicode.

*bbInterface*
In our russian forum I collect all request about bbInterface:
- more simple and small code, for example like this: @BBInterface Control Create Button NAME -x X -y Y -width WIDTH -command "@SomeBroam".
- some kind of entry field.
- OnMove OnResize OnFocus agents.
- relative arrangement of elements.
- Custom Tooltip agent.

At first want to see functions for xmplay and MPC (Media Player Classic) like functions for winamp.

wow!
I am very glad that BBI didn't die. And you have so grandiose plans...

Now some ideas.
Component-based architechture
Perfect! I have same idea quite ago. That allow other developers to create any agents & controls that they need for own plugins.
About inside structure...

Look at foobar2k. It has nice system of conponents. All conditions that you called are keep.

Maybe should make components scriptable... TCL or so on.

Specialized BBI scripts instead of broams
There is not bad to include in BBI++ support any script language (vbscript or javascript).
It helps to make some actions easy and allow simply work with COM objects.
Functions & variables.
Easy way to create variables and functions. Also simple saving it between sessions.
Nessesary to make scopes. For example: global to all, local for module, local for control & his childs.

Dev console
I like it! In old version so hard to debug scripts.

Good luck!

When you make a frame and set the style to none, you can still ctrl+right click on the invisible part of the frame and shows the BBI menu, without the need of editing the *.rc to another style to manage with the frame.
And a frame over another should not be pink colored when the style is none.

Not really, that's just more of the same - have to add a couple of lines in the source code, and those mouse actions could be handled.


That's already been in the source for ages, I think, just commented out.

Yep, that's more along the lines I was thinking. Will be added.

Adding flexibility is not a problem - introducing it in a way that's easy to maintain for the developer, and easy to use as well is more of a challenge. Having 200 options is nice, but if you're only interested in 10, you don't really want to scroll through a configuration panel with 200 items. Any suggestions on this issue, aside from the per-component config menu for toggling options I initially proposed?


Falls under the "specialized BBI scripts instead of broams" heading: more compact syntax for anything you'd want to do.


Comments are always welcome.


I plan to add that. It's not a great difference from current controls that can return a value, more of a quantitative difference than qualitative.


Oh, definitely. I have not checked out how feasible this would be, but if it's possible at all, it'd be a very nice addition.


No, can't really hack into the BBmenu. Building a menu yourself in BBI is not a difficult thing (see my rolldown menu used to demonstrate some new features in an older BBI version), but you got me thinking here. Variable arrays, user-defined structures, and whatever else would be needed so that you could make a custom menu where you can add a new menu item simply by adding a single line to text file. Sort of like the plain menu.rc.


Following from the previous menu.rc idea - how about the BBI config menu itself being customizable in such a way?


All of the above has been addressed in the topic in one post or another.


Could happen. Not sure whether it'll be needed in the end, though. The way I see it now:
- Want to access a feature of BBI? Use BBI's built-in scripting language
- Want to access a feature outside of BBI? Write a component and plug it into BBI.

Well, even if the new BBI won't have built-in support for TCL and the like, writing a component that adds such functionality should be possible. If it won't be, I'll know I've screwed up somewhere along the way.


Using LayeredExWindows (or whatever the heck they're called) for transparent backgrounds also means that the window won't receive mouse events when clicked in its transparent regions. The way to solve this without *.rc editing would be to bring up the BBI menu, and locate the control from there. In fact, such a menu listing all the controls was added in one version - got cut because it was far too slow with a larger number of controls - took seconds for the menu to pop up with 200 or so controls.



Finally, I'd like to point out that, as you can see, the two months are up. I should start working on this in a few days.

Hopefully, the codebase can let you do this simply & lightweight (that is, without any eye-crossing restructuring). Best of good fortune!

Very valid point.
I think it can be reasonable not to have everything in the configuration menu, but still configurable from the RC.
However it would be elegant to give an option to put out things in the config menu, maybe like this:


Of course it could be something simpler than "NotInMenu" and "InMenu", maybe 0 and 1, but I wanted to show the point.
Basic options would have an "InMenu" defaults, while advanced ones would be "NotInMenu".

Or if it sounds confusing to have different options visible for specific items and hidden for others, these could be set in the BBI plugin sepcific options in the RC like this:


What d'ya think?

I'd like to be able to make child objects transparent (buttons, plugins).

Some advises for the new bbi version with my poor english:

1,New Controler.
the 6th controler (after button,SWBUTTON,lable,frame,slider) which we can call it "textbox" such as bbbroam or uberbox .so you can use this to display the specities text you want, and set a variable in bbinterface just like the broam "@BBInterface Set name $text$".that would be usfull for user who want to input or change the variables in their own bbinterface.

2,broam return code.
bbinterface use they own broam to configuration themself step by step with bbinterface.rc as we know. so we can have a return code as variable after a boram was send, just for judge if the last broam was availability.

3,i didn't use wamplayer for long time as many people. would you mind to add other music player suppose with bbi such as foobar2k? i know there was some plugins for it . but it's not my want.

anyway, thanks for the plugin.

Well, well, well. Going to take a crack at a new one, eh? Sounds good to me, I've been away for too long, and you're welcome to take it over.

In any case, some useful contribution:

At one point, I started on BBInterface 2.0. It was a big project and I never finished it - things like doing work that provided a paycheck become more pressing - but here are some of the big ideas for it:

(1) Minimal core extensible with DLLs. The BBI core would provide a minimal implementation to provide the communication mechanisms between agents and controls, as well as defining a couple key agents and controls. DLLs would be used to provide all the agents.

So, someone wants to add an agent to control XYZ, they don't have to hack and rerelease BBI, they just write a very very tiny control DLL, and everything just meshes with BBI seamlessly. (This is, incidentally, why I originally wrote it in C and not C++ - easier extensibility via other programming languages, I wanted to make it so someone could write modules in Pascal or VB or whatever, without the burden of matching C++ types.).

Or, for another example, someone could write additional controls - even complex ones, like wharfs and taskbars - through a DLL, and they'd only have to program the visual elements, and they'd get all the interface functionality and access to all agents for free from BBI.

This was the grand dream that started it all, actually - eliminate the need to rewrite the same functionality over and over every time someone wants to do something by decoupling visualization (controls) from actions and behavior (agents).

(2) Things Have Properties. Properties Are Agents. That was the other big one. Make ALL properties of controls and agents be agents themselves. Right now many properties are primitives only - numbers, strings, booleans. Like, "button.x = 123", or any other real number. By making ALL properties as agents, you could have way more power - so, "button.x = mathagent(cpuagent.percentage * 3000)" - hooking together mathematical equations, other agents, and primitives. The potential behind this is immense.

(3) Reference agent. Allowing for referencing of other properties of other controls and agents. Like, "Button1.x = MathAgent(Button2.x + 200)". Also powerful, but creates potential for circular references, so you'll have to deal with that.

(4) Global singleton agents, not belonging to any control. Like, "GlobalX = 4; button1.x = GlobalX; button2.x = GlobalX". Or more complex and dynamic ones, like "Slider.Value = GlobalCPUUsage; Graph.Value = GlobalCPUUsage";

Oh, and one more thing:

Beware of second system effect. It is real and dangerous and will be your biggest challenge.

Just a note: priorities have shifted a bit, I'll get to fixing one of the larger bugs of BBI, namely the lack of support for nesting of transparent controls, and only then start the new project. It'll take some time for me to read through the relevant documentation on MSDN and then refamiliarize myself with BBI's inner workings after all this time, though.


Risen from the grave, not unlike myself, eh? Neat to see you around.


Paid Work, the greatest enemy of all hobby projects. I know what you mean.


Same thoughts here, as described in the opening post. I'm starting to realize that it's quite a bit easier said than done.

Points 2-4 I also hope to cover. Writing a custom interpreter for all that seems to be the bigger task, and making it relatively fast.


Well, it's the first time I'm writing a blackbox plugin (or Win32 app, for that matter) from scratch, actually. Also, the very reason I want to do that is because I feel bbInterface has become that "big pile" over time. Hopefully I won't end up committing the mistakes I intend to correct in the first place.

Transparent controls. YESSSS! And more window options/style options perhaps, like button/button pressed? Power to you...

I'd be happy if I could implement a kind of startbar for which a concept mockup can be seen in cairoshell's screenshots here:
http://cairoshell.com/downloadsmain/fil ... ndTask.jpg

That could go with:
-moving systembarex/bbleanbar from its original place
-include menus side by side in a BBI frame, maybe limiting their height
-and a shell function of listing recently started applications would be nice as well.

Is that totally unimaginable?

oh man, i'm gonna get flamed for this



yeah, after seeing szekelya's recent shot, i finally got around to building my own cairo-shell imitation startbar. and now i wish i had a transition effect, like - i want the whole thing just sliding from the edge of the screen, instead of just *bam* appearing, and *bam* disappearing again. just like i imagine it would be in cairo..

but i think that would be a little too 'bloaty' for bb, though..