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

[blizzy78]

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

I encourage you to check the current API on GitHub to see if there's anything that stands out. Better to find things sooner than later

[TriggerAu]

Blizzy78, this is looking seriously good, nice work.

[SirJulio]

Hello Blizzy and awesome work, i can't wait for you to release this.

Just a question, the GPL's folks are not clear on it (Damn i hate that license ... =p) so let's ask for your opinion. I create a work based on your dll without modifying it, by definition in .Net all is dynamically linked, so do i need to license my whole work in GPLv3 or can i go with my licence of choice (of course your work (dll, source, art etc ...) stay on GPL) ? Sorry to bother you with that, but i prefer to stay safe on license issue. =)

[a1270]

Hello Blizzy and awesome work, i can't wait for you to release this.

Just a question, the GPL's folks are not clear on it (Damn i hate that license ... =p) so let's ask for your opinion. I create a work based on your dll without modifying it, by definition in .Net all is dynamically linked, so do i need to license my whole work in GPLv3 or can i go with my licence of choice (of course your work (dll, source, art etc ...) stay on GPL) ? Sorry to bother you with that, but i prefer to stay safe on license issue. =)

I'll be rude and interject as i have been forced to read up on this stuff.

It's actually very clear. https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL How it's linked does not matter. https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic

TLDR: Your work MUST be under a GPLv3 compatible license.

Skimming the thread it seems like a lot of Creative Commons licensed plugins and GPLv3 is incompatible with everything but CC0(aka Public Domain) from what i can tell. Any plugin under a license with a non-commercial clause is for sure incompatible, the GPL doesn't discriminate when it comes to usage. On a side note: KSP is most likely included in the system library exception of GPLv3 along with the dotnet libs.

Back to not sleeping and reading documentation.

[blizzy78]

I will be switching to the BSD 2-clause license. As much as I like copyleft licenses, I do not fear forks cropping up. But more importantly, I don't want to create any serious roadblocks that will hinder the adoption of the Toolbar Plugin into third-party plugins.

[SirJulio]

It's actually very clear. https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL How it's linked does not matter. https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic

TLDR: Your work MUST be under a GPLv3 compatible license.

I'm not a lawyer but it seems to be not clear as you think for a lot of people. Anyway, the point was for blizzy to clarify his intentions for me and he did it. Thanks blizzy and keep the good work =)

[blizzy78]

I will be switching to the BSD 2-clause license.

Done.

/10chars

[blizzy78]

Toolbar Plugin 1.0.0 is now available for download and public consumption. I have edited the OP to provide a download and a basic list of instructions on how to include it into third-party plugins.

I'd like to thank everyone for their thoughts and suggestions. I'm now thrilled to see what you all will be doing with this

[Trueborn]

SteamGauges version 1.3.2 is now live with Toolbar integration.

[SirJodelstein]

Hmm, i must be doing something wrong or missing something. The one button i created shows up, but without an Icon, and the debug log shows a warning

[Error]: error loading button texture: C:/Spiele/KSP 0.22 DEV/KSP_Data/../GameData/PersistentTrails/PluginData/Main-NoRecording.png

I double-checked the file existence and correct size (24x24 png), but the error persists.

Next: Whenever i click on the button, the toolbar jumps around a little. It repositions itself to place the clicked button centered below the mouse. But perhaps thats just because the button is not actually there? Toolbar text doesnt show up either.

Here is my code for the button. I have placed it in the Awake function of my plugin. Or do i have to call that block in each "OnGUI" call?

            mainWindowButton = ToolbarManager.Instance.add("MainWindow", "mainWindowButton");
            mainWindowButton.TexturePath = GUIResources.IconNoRecordingPath;
            mainWindowButton.ToolTip = "Persistent Trails - toggle main window";
            mainWindowButton.Visibility = new GameScenesVisibility(GameScenes.FLIGHT);
            mainWindowButton.OnClick += (e) =>
            {
                Debug.Log("button1 clicked, mouseButton: " + e.MouseButton);
                mainWindow.ToggleVisible();
            };

[TriggerAu]

Hmm, i must be doing something wrong or missing something. The one button i created shows up, but without an Icon, and the debug log shows a warning

[Error]: error loading button texture: C:/Spiele/KSP 0.22 DEV/KSP_Data/../GameData/PersistentTrails/PluginData/Main-NoRecording.png

I double-checked the file existence and correct size (24x24 png), but the error persists.

Next: Whenever i click on the button, the toolbar jumps around a little. It repositions itself to place the clicked button centered below the mouse. But perhaps thats just because the button is not actually there? Toolbar text doesnt show up either.

Here is my code for the button. I have placed it in the Awake function of my plugin. Or do i have to call that block in each "OnGUI" call?

            mainWindowButton = ToolbarManager.Instance.add("MainWindow", "mainWindowButton");
            mainWindowButton.TexturePath = GUIResources.IconNoRecordingPath;
            mainWindowButton.ToolTip = "Persistent Trails - toggle main window";
            mainWindowButton.Visibility = new GameScenesVisibility(GameScenes.FLIGHT);
            mainWindowButton.OnClick += (e) =>
            {
                Debug.Log("button1 clicked, mouseButton: " + e.MouseButton);
                mainWindow.ToggleVisible();
            };

oh oh oh, I know the answer to this one... by about 30 minutes). After an hour and a half of the same pain I found this out . The Gamedatabase loader doesn't load any textures/files inside a PluginData Folder. I created a new Folder alongside my PluginData folder for ToolbarIcons and put the 24x24 pngs in there and it all came together. Its probably documented somewhere so I can feel silly later, but give that a go.

So in my case instead of the icons being in TriggerTech/PluginData/KerbalAlarmClock , I moved em to TriggerTech/ToolbarIcons and changed my string names. Just about to upload my video too

[TriggerAu]

Heres the Kerbal Alarm Clock integrated with the Toolbar - user can choose to use either button model, and the button icon changes in the toolbar same as the native one does

I really want to be able to make a late call to this Toolbar.dll so people can install KAC without having to have the Toolbar.dll. Their choice, before I publish a new version of KAC. So I am gonna look at calling the toolbar by reflection.

Firstly let me say, this toolbar is great, Have some rep

@Blizzy78, a couple of questions:

1. Do you have any issues if I go down the path of a late call by reflection?

2. I'd suggest moving the toolbar-settings.dat location to be inside the folder with the toolbar.dll ( Line 35 of Internal/ToolbarManager.cs according to github)

3. This one is just my opinion, so feel free to take it or leave it... I feel the edge snap would look better if the toolbar went another couple of pixels off screen. This would mean if you drag it to the edge it looks like it is sticking from the edge, and hides the rounded corner. For example below.

Once again thanks.

[SirJodelstein]

oh oh oh, I know the answer to this one... by about 30 minutes)

Unfortunately, that did not help. Moved the icons from GameData/PersitentTrails/PluginData to GameData/PersistentTrails/Icons. Still getting the error. Moving the code to OnGui helped somewhat, atleast now it draws an empty clickable button instead of just the toolbar frame.

[Trueborn]

I've gotten it to work in the awake method, though it took me quite a while to get it to recognize my texture as well. I did end up renaming it as well as moving it out of the plugin directory. Unfortunately, I did both at the same time, some I'm not sure which one actually fixed it.

[blizzy78]

Hmm, i must be doing something wrong or missing something. The one button i created shows up, but without an Icon, and the debug log shows a warning

[Error]: error loading button texture: C:/Spiele/KSP 0.22 DEV/KSP_Data/../GameData/PersistentTrails/PluginData/Main-NoRecording.png

I'm not doing anything special with the texture, loading it as usual through the GameDatabase:

GameDatabase.Instance.GetTexture(TexturePath, false)

The error you see does not stem from the texture size, it will put a different error into the debug log if you exceed that size.

Next: Whenever i click on the button, the toolbar jumps around a little. It repositions itself to place the clicked button centered below the mouse. But perhaps thats just because the button is not actually there?

Yes, there's a minor bug in there that those buttons still show up while they shouldn't.

Toolbar text doesnt show up either.

Text buttons are no longer supported. I chose to leave it in there though because I'm planning to use it for drop-down menus.

Here is my code for the button. I have placed it in the Awake function of my plugin. Or do i have to call that block in each "OnGUI" call?

No, you only need to do that once. It doesn't matter where, because that code doesn't really do much. The actual work will be done much later during ToolbarManager's OnGUI method. For example, the TestButtons example code constructs all its button in its constructor.

Edit: I see that you're using "[KSPAddon(KSPAddon.Startup.Flight, false)]", so that shouldn't cause any problems with the GameDatabase not being ready for use.

mainWindowButton = ToolbarManager.Instance.add("MainWindow", "mainWindowButton");

Please do not use "MainWindow" as your namespace. It's better to use your plugin's name.

1. Do you have any issues if I go down the path of a late call by reflection?

2. I'd suggest moving the toolbar-settings.dat location to be inside the folder with the toolbar.dll ( Line 35 of Internal/ToolbarManager.cs according to github)

3. This one is just my opinion, so feel free to take it or leave it... I feel the edge snap would look better if the toolbar went another couple of pixels off screen. This would mean if you drag it to the edge it looks like it is sticking from the edge, and hides the rounded corner.

1. Nope, it's your call

2. Will look into that. For now I chose to put it there because of fear that players might overwrite their settings. But after all, other plugins do it the same way, for example MechJeb. If you overwrite MechJeb's settings, you're in for lots of frustration. So I guess I should be moving that file.

3. Thanks, good idea. I think I will be doing that when I come around to implement (optional) auto-hiding at screen edges.

Edited December 7, 2013 by blizzy78

[SirJodelstein]

Got it. I always tried to feed an absolute file path + Filename + fileExtension to the texturepath. Using the Gamedatabase obviously makes things different (root is "GameData", no file extension). Oh dear, that took way too long to figure out. Anyway, thanks for your hints, I'll release an update soon!

[blizzy78]

Got it. I always tried to feed an absolute file path + Filename + fileExtension to the texturepath. Using the Gamedatabase obviously makes things different (root is "GameData", no file extension). Oh dear, that took way too long to figure out. Anyway, thanks for your hints, I'll release an update soon!

https://github.com/blizzy78/ksp_toolbar/blob/master/Toolbar/IButton.cs#L70-L73

[PrivateFlip]

Please do not use "MainWindow" as your namespace. It's better to use your plugin's name.

The id can be a generic name like mainbutton, right?

I had some brief problems with texturepath. While figuring it out, now got it to work, I found a small discrepancy; your documentations mentions the following:

                /// The texture path must be relative to the "GameData" directory, and must not specify a file name suffix.
                /// Valid example: MyAddon/Textures/icon_mybutton

However the texture path used in your TestButtons.cs does not seem to comply with this as the directory mentioned is not relative to the GameData directory, but it does seem to work. I can imagine the only reason for this is because TestButtons.dll is using "blizzy/000_Toolbar/img_buttonTypeMNode" and that the TestButtons.cs on github is a different version, but if not this is something you might want to look into.

The way I've implemented the Toolbar in my Multiple Saves DA plugin is by using a fall through method where the plugin checks if your plugin is present and uses it if so. Otherwise it falls back to the native minimized button setup. EDIT: But this doesn't work. My bad; posting before testing Guess it'll be a hard dependency.

Edited December 7, 2013 by PrivateFlip

[blizzy78]

The id can be a generic name like mainbutton, right?

Correct. The Toolbar Plugin doesn't really care what it is, except for maintaining button order.

However the texture path used in your TestButtons.cs does not seem to comply with this as the directory mentioned is not relative to the GameData directory

In early versions I had everything installed under GameData\blizzy\Toolbar\, so that's where this is coming from. Don't pay too much attention on the actual texture paths in TestButtons.cs, they will always depend on the actual installation.

The way I've implemented the Toolbar in my Multiple Saves DA plugin is by using a fall through method where the plugin checks if your plugin is present and uses it if so.

Right, but I'd really like to encourage everyone to actually include the Toolbar Plugin into your plugins' downloads. Of course I can't make anyone do my bidding if that's not your thing

[PrivateFlip]

Right, but I'd really like to encourage everyone to actually include the Toolbar Plugin into your plugins' downloads. Of course I can't make anyone do my bidding if that's not your thing

Yes, will do this, see the edit to my previous post.

[XanderTek]

This is a wonderful addition to the modding community! My only suggestion at the moment: It's a bit hard to see/grab the border around the buttons to resize or drag the toolbar. It seems to be only a few pixels wide, and blends in with the blackness of space.

[TriggerAu]

Right, but I'd really like to encourage everyone to actually include the Toolbar Plugin into your plugins' downloads. Of course I can't make anyone do my bidding if that's not your thing

I plan to advise people how good this is and to use it, but just dont want to have it as a hard dependency - I dont want to do that with interplugin calls in my own mods so I already had it on the list to investigate.

[blizzy78]

It's a bit hard to see/grab the border around the buttons to resize or drag the toolbar. It seems to be only a few pixels wide, and blends in with the blackness of space.

Right. As I already wrote over in the players' thread, I have plans to improve on that. Right now I'm in the middle of adding a toolbar-specific dropdown menu, which is coming along quite nicely. In that menu there will be an option to lock/unlock the toolbar's position and size. Unlocking will make the complete toolbar draggable.

Edited December 7, 2013 by blizzy78
added in-development screenshot

[blizzy78]

I've edited the OP to put up a new video that shows the current state of development. (yet to be published)

[MedievalNerd]

Nice, this would probably be awesome for the Realistic Progression Lite's Custome Experiments! Not sure I'll have time to figure out how to implement just yet, but as soon as I have time I'll give this one a shot.

Looks great!