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

[blizzy78]

Toolbar Plugin 1.7.4 is now available for download.

Note: If the download page is linking an older version for you, press F5 in your browser.

[finkmac]

Where can I get a copy of v1.7.3, or whatever version works with 0.23.5?

[skykooler]

Would it be possible now that 0.24 is released to make this mod wrap the 0.24 toolbar?

[blizzy78]

Would it be possible now that 0.24 is released to make this mod wrap the 0.24 toolbar?

Wouldn't that kind of defeat the whole purpose of this plugin?

[Alewx]

Wouldn't that kind of defeat the whole purpose of this plugin?

Not if your plugin is able to enhance and improve the usability of the stock toolbar

[Oinker]

Stock toolbar sucks. I just want that ugly-assed beast off my screen. We need options to turn off stock interface items.

[Agathorn]

Wouldn't that kind of defeat the whole purpose of this plugin?

[Majiir]

I'm really dreading the future i'm forseeing which is having to use both your toolbar AND the stock one. Its bad enough finding a place for one toolbar, now theres two and the place I used to put yours is now taken.

Ask Squad to implement the features modders have asked for. I will continue to use Blizzy's toolbar because it does what I need, and the stock one does not.

[Agathorn]

Ask Squad to implement the features modders have asked for. I will continue to use Blizzy's toolbar because it does what I need, and the stock one does not.

My point is what is to stop Blizzy from enhancing the stock one to do what modders want (or at least trying)? I mean thats the story of almost every mod in the game after all. Squad never gives us what we want, we do it ourselves.

[Schweehog]

Where can I get a copy of v1.7.3, or whatever version works with 0.23.5?

I'm also looking for the old version. I can't find it anywhere.

[hab136]

I'm also looking for the old version. I can't find it anywhere.

v0.5 of AutoAsparagus has Toolbar 1.7.3 in the ZIP: https://github.com/henrybauer/AutoAsparagus/releases

[Master Tao]

Also, if you click on the GitHub link in the first post, then releases, there are previous versions going back to version 1.0.0

[ragzilla]

No. Blizzy I respect what you have done, so please understand i'm not trying to be a jerk about this. In fact its because I respect what you've done that i'm so adamant about it.

You started this toolbar because mods were all doing their own thing with buttons and it was a mess. It was great what you did.

But now we have the game's on toolbar and yours and its going to be a mess again. I honestly believe what's best is for you to basically enhance the built in AppLauncher so we can keep everything clean and in one place again. Extend the AppLauncher to have more features like folders, and then work with what is there rather than making a second toolbar.

I'm really dreading the future i'm forseeing which is having to use both your toolbar AND the stock one. Its bad enough finding a place for one toolbar, now theres two and the place I used to put yours is now taken.

Toolbar's license (BSD 2-clause) is open enough that someone could fork and create a blizzy toolbar-applauncher wrapper if they so desired. Not sure if anyone's working on that yet.

[blizzy78]

Toolbar's license (BSD 2-clause) is open enough that someone could fork and create a blizzy toolbar-applauncher wrapper if they so desired.

Or better yet, submit a pull request. All that fork-if-you-don't-like-it nonsense is a bit ridiculuos.

[xEvilReeperx]

Or better yet, submit a pull request. All that fork-if-you-don't-like-it nonsense is a bit ridiculuos.

Makes perfect sense if they want to take the project in a direction you don't want to go. And since you don't want to make it a wrapper around the application launcher, what's ridiculous about forking the project? Has nothing to do with liking the toolbar or not

[ragzilla]

Or better yet, submit a pull request. All that fork-if-you-don't-like-it nonsense is a bit ridiculuos.

Would you be open to maintaining that in your codebase? Your response in #304 seems like you wouldn't be interested in that.

[blizzy78]

Makes perfect sense if they want to take the project in a direction you don't want to go. And since you don't want to make it a wrapper around the application launcher, what's ridiculous about forking the project? Has nothing to do with liking the toolbar or not

Would you be open to maintaining that in your codebase? Your response in #304 seems like you wouldn't be interested in that.

I'm not entirely opposed to supporting the App Launcher. I was just stating that it kind of defeats the purpose of my plugin, which I don't think you can deny.

Edit: But that's not the point I was trying to make. I was to say that I don't think all the forking is doing much good, and this comment is not specific to the Toolbar Plugin. It's much better to try and get together with the respective developers to combine efforts rather than splitting up the user base.

Edited July 21, 2014 by blizzy78

[xEvilReeperx]

Why the negative comment about forking then? It's not any of your concern what they decide to do with it after that. I know from experience that it's extremely difficult to convince you to change or add any toolbar features so if I read a post like #304, my first instinct would be to fork the project (if I had the time) also

[ragzilla]

I'm not entirely opposed to supporting the App Launcher. I was just stating that it kind of defeats the purpose of my plugin, which I don't think you can deny.

Edit: But that's not the point I was trying to make. I was to say that I don't think all the forking is doing much good, and this comment is not specific to the Toolbar Plugin. It's much better to try and get together with the respective developers to combine efforts rather than splitting up the user base.

That's one of the joys of open source though, if something doesn't handle something the way you want it to you can make it do what you want. If there's a receptive upstream maintainer you can get the work integrated there, but if there isn't you can fork and maintain your own. Forking on it's own isn't necessarily bad.

I'm absolutely horrible with .net but I may take a look at integrating applauncher behind toolbar to meet the needs of people who only have a few toolbar buttons and want to keep things on the AppLauncher. Saves plugin authors from having to support both if they don't want to. Or there might be some merit to extending ToolbarWrapper to integrate with AppLauncher if Toolbar isn't present, but that'll require plugin authors to rebuild using ToolbarWrapper (is it possible to use Toolbar without the wrapper?) if they aren't already.

[blizzy78]

Why the negative comment about forking then? It's not any of your concern what they decide to do with it after that.

I still can have negative feelings about the project being forked, no? (Again, I'm not talking about the Toolbar Plugin here, just project forks in general.)

I know from experience that it's extremely difficult to convince you to change or add any toolbar features

When you say "convince you to change or add any toolbar features" - I can only remember one particular thing you wanted changed. It's not that I always decline adding or changing anything in the Toolbar Plugin based on user requests. So it's not exactly "difficult" per se.

Forking on it's own isn't necessarily bad.

From the technical view, I agree. But in the longer term, it leads to a user base split, which I think is bad for the existing user base as well as the to-be-established user base of the fork.

But in any case, I just wanted to bring that small thing up, not make a whole discussion about it in this thread. That's not to cut off any discussion about it, it's just because it's off-topic.

is it possible to use Toolbar without the wrapper?

Yes, by maintaining a hard dependency on the DLL, and quite a few plugins do that already.

I think it would be best to implement that directly in the toolbar, and as another user has suggested, make it a user setting of some sort. That way, both kinds of third-party plugins could benefit from it, the ones with a hard dependency, and the ones using the wrapper.

Edited July 21, 2014 by blizzy78
clean up messy wording

[xEvilReeperx]

When you say "convince you to change or add any toolbar features" - I can only remember one particular thing you wanted changed. It's not that I don't add or change anything in the Toolbar Plugin at all based on user requests. So it's not exactly "difficult" per se.

1. Animated buttons/Direct texture access. That was a flat no with strange justification.
   
2. Consistent drawable placement. Added!
   
3. PopupMenuDrawable customization, specifically:
   
   1. 
      
   2. Consistent placement of menu (solved by #3)
      
   3. Ability to customize menu background or skin to avoid jarring with KSP theme (nope)
      
   4. Remove buttons at runtime (nope, whole menu needs to be recreated)
      
   5. Other control options, especially labels. Still not an option even though I feel there's very good justification to have one
      
      
      It doesn't really matter now, anyway. There are two toolbar options and developers can decide based on their needs

[blizzy78]

Let me just go over your points real quick. I might have turned some of them down in the past, I can't quite remember everything now. So let's instead focus on what I think of them right now.

Animated buttons/Direct texture access.

Animations: Okay, I think I'll add support for those (time permitting, as always.) I personally think animated buttons might be stretching things a bit, but on the other hand users will complain if they find it too heavy. So that's more of a concern of the author adding the animations rather than the Toolbar Plugin.

Direct texture access: Not going to happen.

Ability to customize menu background or skin to avoid jarring with KSP theme

Not sure where this comes from. Is that backgrounds for IDrawables in general? I think I like it, but not quite sure how that would look like. If you have specifics in mind, please let me know.

Remove buttons at runtime (nope, whole menu needs to be recreated)

That's the way PopupMenuDrawable is implemented right now. I can't quite remember if there was a specific reason to do it that way, at least it must have been easier to do (heh, if that's not reason enough )

Other control options, especially labels. Still not an option even though I feel there's very good justification to have one

Back then I agreed that it would be nice to have. Not having added it yet doesn't mean I turned it down.

It would be nice to have some specifics, meaning, what would you need? You mentioned that currently it's impossible to see which button opened up some drawable. Anything else?

[Diazo]

Direct texture access

Sorry for the tangent here, but what does this mean in context?

Currently create the texture as a image file and then tell the Toolbar where to find it.

If you want to change the texture, you have a second image file you change the button too.

To me that is as direct as you can get. I suppose you don't have access to the texture object in the toolbar assembly at runtime, but what would that gain you? (Assuming that is what direct means in this context.)

To add some relevance to this post, I just want to let you know that Toolbar has performed flawlessly on my computer with several mods (and toolbar buttons) installed. If there is something you would like me to do to give you a "working computer" setup for comparison please let me know.

D.

[xEvilReeperx]

Sorry for the tangent here, but what does this mean in context?

You currently assign textures to a button using TexturePath. I want to be able to assign a Texture2D directly using a similar property. I already have direct access to the pixels in the toolbar. I just want changing the texture to be more convenient and less inefficient. Every time I change an animation frame, toolbar will waste time performing 500+ string comparisons to find a texture I already have and could just hand to it.

[blizzy78]

Is that backgrounds for IDrawables in general?

I just realized that "backgrounds for IDrawables in general" doesn't really make sense. The IDrawable mechanism is just a framework so that something can be displayed. The whole drawing is done in the third-party plugin - there's no way I can inject a background there. (Of course the PopupMenuDrawable is a whole other story.)

That said, I should probably also add a default "window drawable" implementation. I've been using GUILayout.Window() in a few places now for drawables, and it's a bit of a pain to get it right. So that's where I could help out other developers a bit, too.