[1.2.0] Toolbar 1.7.13 - Common API for draggable/resizable buttons toolbar

[Majiir]

If you do release with a 000 name, consider adding a KSP version check so the plugin deactivates itself after KSP 0.22. This way, you can reevaluate your decision after KSP 0.23, and most people update mods after a major game release anyway.

Oh, and speaking of that. Will unresolved dependencies stop breaking the game as well?

Not that I know of. How would that work, anyway? If a dependency isn't available, a plugin might try to execute code that doesn't exist.

[blizzy78]

I know that you are planning on it, but I wanted to reiterate that it is very important that you allow us to control in which scene(s) the icons show.

I have added API to add an extensible point to control visibility in a flexible way. (buzzword bingo anyone?)

Example code: https://github.com/blizzy78/ksp_toolbar/blob/master/TestButtons/TestButtons.cs#L42-L48

[TriggerAu]

Wow, I too was going to look at this for a next project Good job Blizzy78.

i'd be interested in being able to leverage this kind of thing, but I do have one suggestion/idea that I have been researching.

What do you think of using reflection/late dll binding to make the call to the interface. Then other mod writers simply include a code file in our mod, we can test for being able to bind in your dll, and if it cannot find the dll it still displays the way we already do?

This means people could have a have a choice of the toolbar or not, and also means no need to include two plugins in a bunch of downloads.

I can provide some help on that if you are interested - I plan to use the method to allow others to interface to KAC in the future

[Galane]

One thing the KSP UI desperately needs is for buttons that toggle the state of things to show on the buttons themselves their state. As it is, no button using the built in KSP theme/style does that. Some change a tiny icon (enabling/disabling a fuel tank), some change text next to the button. Some, such as Control From Here, change *nothing visually*.

A toggle button should in some way emulate the style of a real pushbutton that locks in when on and pops out when off. That way all the player has to do is right click a part and at a glance can see the on or off status of all toggle-able functions. In the case of Control From Here it would definitely show which part has control, instead of the current system where it's impossible to know by looking at or reading the popup menu on control pod parts.

There's a huge number of ways for a GUI button to show its status, but the least ambiguous way is to alter the look of the button itself. One very common example is in multimedia programs where something directly on the Record button turns red. It's an emulation of the red light on physical equipment that was often mounted in or behind the button.

There's a long standing convention in GUI design for functions that have two or more settings or options. Where only one of a group may be active, the selection graphics should be round. They're called "radio buttons" after the station selector buttons on old car and home radios where only one at a time could be pushed in, which would pop out the previously pushed in button. Before GUIs on computers, round circles were used on paper forms where only one in a group should be marked. Radio buttons should show a solid dot when selected.

When any number of options in a group may be selected, the selection graphics should be square or square-ish and are called checkboxes after the square boxes on things like paper forms with lists of things where you may check all that apply. Checkboxes should display a checkmark or X or some other mark that doesn't nearly fill the box to avoid any visual confusion with radio buttons.

Like toggle function buttons, radio buttons and checkboxes visually display their change of state.

Clearly and unambiguously displaying the status of things, and sticking to the radio button and checkbox convention (no mater how creatively designed the graphics are) enables the user/player to *quickly* see how things are. That speed can be vital in KSP when you have only a short time to avoid disaster.

I've used and worked on computers for 30+ years. Software that goes by these simple conventions is easy to use. The major point of a GUI is that once you've learned to use one, you can quickly learn any other - as long as it uses similar techniques for how the controls operate.

But then the two biggest proponents and implementors of standardized GUI design have often drastically broken their own rules. Yeah, I'm looking at *you* Apple multimedia apps (all of them from Quicktime 4 on) and Microsoft Office!

Google User Interface Hall of Shame.

[blizzy78]

Alright, thank you for that little excourse, Galane.

[Trueborn]

Some mod community standardization, I like it. I especially like the idea of the toolbar to handle multiple mods. If it gets a toolbar, Steamgauges is in.

[blizzy78]

If it gets a toolbar, Steamgauges is in.

Not sure if that is what you mean, but mod support is generic. There is no need for me to specifically add SteamGauges in any way - you can just use it at will.

(If you talked about something else, please let me know

[Trueborn]

I'm just saying I don't see a whole lot of utility to replacing my current button with yours unless you implement the toolbar style where multiple buttons are part of a single bar. If I start up a new mod I'll probably use it regardless, though.

[blizzy78]

I'm just saying I don't see a whole lot of utility to replacing my current button with yours unless you implement the toolbar style where multiple buttons are part of a single bar.

Right. I have thought about adding toolbars, but haven't made a final decision yet. It all depends on how far you want to go with this feature: Allow a single toolbar or multiple? Can buttons only live in toolbars, or can they be standalone (as they can now)? If you have multiple toolbars, there needs to be some way to drag a button from one to the other. Especially so if toolbars can be configured to auto-hide if the mouse pointer is somewhere else. You also need some way to create/delete toolbars in the first place.

In the end it all comes down to effort vs. usefulness.

[Trueborn]

I did have visions of the Wow toolbars, where you could have like 8 of them. And then I remembered that you probably don't need that many buttons for KSP mods... But hey, you could always start with one and go from there.

[softweir]

As a user I would only ever use one buttonbar: I don't use many mods and wouldn't feel the need for multiple buttonbars. I wouldn't really want to move buttons all over the place and I dislike each mod having its own button wherever the mod-creator puts it, and where possible I cluster them all together. So I personally would be very happy with a minimalist buttonbar!

However, I can't help but think that it should be possible to organise the API so all this is invisible to plugins using it: they don't care if the buttons are docked to a buttonbar or isolated, they just need to be able to register a button, set its visibility and be informed of click events. (It *would* be useful if the API made the location available at the time a button is clicked so plugin authors can implement drop-down menus.) So at this stage I would suggest you produce the minimal feature-set (up to you to decide if that consists of a buttonbar or individual buttons) and find out how easy or hard that is before going on to elaborate the feature-set.

[blizzy78]

And then I remembered that you probably don't need that many buttons for KSP mods... But hey, you could always start with one [toolbar] and go from there.

Right.

However, I can't help but think that it should be possible to organise the API so all this is invisible to plugins using it: they don't care if the buttons are docked to a buttonbar or isolated, they just need to be able to register a button, set its visibility and be informed of click events.

That's exactly what this is all about I'd like to transfer as much control over the buttons from the plugin authors to the players.

So at this stage I would suggest you produce the minimal feature-set (up to you to decide if that consists of a buttonbar or individual buttons) and find out how easy or hard that is before going on to elaborate the feature-set.

Well a "minimal feature set" already exists (although not recommended for distribution yet.) Please see the OP for a video, downloads, and links to example source code.

[blizzy78]

It *would* be useful if the API made the location available at the time a button is clicked so plugin authors can implement drop-down menus.

I'd rather have the Toolbar Plugin provide a means to support drop-down menus.

[TriggerAu]

I too am a fan of the idea of a single bar with docked icons Blizzy78. Even if its not that I look forward to seeing what you come up with

[blizzy78]

I'm currently working on it, but don't hold your breath just yet.

[TriggerAu]

Hope that wasnt taken the wrong way, am happy to wait, I know how busy it can get

[blizzy78]

Oh no, not at all

Just wanted to let you know that it won't be released like today or tomorrow, but it will take a little while. In the meantime, feel free to check out the source code on GitHub, compile against it, and see if anything crops up.

[Mihara]

I'd rather have the Toolbar Plugin provide a means to support drop-down menus.

...I must say, I would like nothing better than an easy to use GUI toolkit I could just link to and not worry about it myself, and your plugin looks suspiciously like a starting point for one.

I suck at GUIs.

[blizzy78]

Okay, so I've been mucking about with a toolbar yesterday, and so far it's looking quite nice. I hope to push my code changes to GitHub tonight, zip up another pre-compiled and runnable download, and make a new video demonstrating things.

Also, I'm seriously considering dropping button text support for toolbar buttons. It's not that I can't get it to work (it already does), but text buttons look really ugly in combination with icon buttons on the toolbar. They also do take up a lot more space than a single icon.

Also, I've made code changes so that icons on the buttons should be 24x24 pixels, while the buttons themselves will be 32x32 pixels.

I'd like to point out that things are still a little bit in flux right now, and will continue to be until I've released the final version that is ready to be included into third-party plugins.

[blizzy78]

Toolbar is in.

I have updated the OP for a new video as well as a new pre-compiled demonstration download. Source code is available on GitHub as well. Please enjoy.

Edited December 5, 2013 by blizzy78

[nothke]

Toolbar is in.

I have updated the OP for a new video as well as a new pre-compiled demonstration download. Source code is available on GitHub as well. Please enjoy.

Amazing! Believe it or not, I had the same idea for dragging the edge of the window to change grid size. But couldn't find a technical solution how to do it with GUI xD

[blizzy78]

You can actually only drag the lower-right corner to resize the toolbar. But yeah.

[Trueborn]

Cool. SteamGauges will be ready to release with the toolbar when you clear it for public consumption. Are you looking into a way to allow users to change button order?

[blizzy78]

Yes I am. I have not decided if that feature should make it into the first release, though. A quicker approach would be to just auto-sort by "namespace.id" for now.

[PrivateFlip]

I will be working hard to ensure that the API will be upwards-compatible, so that a third-party plugin compiled against an older version of the Toolbar Plugin will work fine with a newer version of the plugin.

This would be my mayor concern, I'm glad you're on it.