Custom button types (dropdown, toggle, checkbox, radio)

[nkt]

Please add support for select, like this:

[jerone]

What happens when you click that button? Does a dropdown menu popup? Is it a custom menu or a native select menu?

Can you supply an use-case.

Also, what app is that screenshot from?

[nkt]

@jerone it's webstorm, and use-case is a build system. Select allows you choose which build system you gonna run, and other buttons is "run" and "debug".
Webstorm uses not native selects, every option has it own icon, according to build system type. I guess firstly enough just native select.

[cakecatz]

👍 I like this.

[suda]

Custom button types (dropdown, checkbox, radio) are definitely something that tool-bar should support. 👍

[jerone]

@suda commented on 26 mei 2015 12:44 CEST:

Custom button types (dropdown, checkbox, radio) are definitely something that tool-bar should support. 👍

I do agree. I was thinking for the select/dropdown to use the same styling/layout from Atom's contextmenu. Have to find out where they defined that.

[cakecatz]

Maybe native select box cannot display font icons properly 😢
Check this FortAwesome/Font-Awesome#996

OSX 10.10. JS Bin

[MaximeWillinger]

👍 for toggle buttons associated to toggle actions !

[jerone]

@MaximeWillinger commented on 28 mei 2015 11:12 CEST:

👍 for toggle buttons associated to toggle actions !

Reply from cakecatz/flex-toolbar#19 @jerone on 22 mei 2015 11:02 CEST:

[..] Problem is that it's hard to know which state (active or inactive) a button should be in. Say I want a toggle button for Markdown Preview. How does the toggle button know which state it should be in? When pressed it could be set to active, and when pressed again it could be restored to inactive. Problem is that Markdown Preview could be closed manually, or called by a command. The toggle button doesn't know about those methods.

It is possible to fetch every command (https://github.com/atom/notifications/blob/ea5aaf3a8329ce53f1c9281ac3a1b7c3d8cf8909/lib/command-logger.coffee), but it's not preferred and could significantly impact the performance of all of Atom (source).

I did a quick test and it logged already a lot of redundant events while in idle state:

atom.commands.onWillDispatch(function(event){console.log(arguments);})

[suda]

The package which adds the button should take care of updating its state i.e.:

consumeToolBar: (toolBar) ->
  @toolBar = toolBar 'your-package-name'

  # Adding button
  @toggleButton = @toolBar.addButton
    icon: 'octoface'
    callback: 'markdown:toggle'
    tooltip: 'Toggle Markdown'

toggle: ->
  @enabled != @enabled
  @toggleButton.setChecked @enabled

If there's one package adding buttons to another one (like in case of flex-toolbar), listening for command dispatch and checking the result (i.e. if Markdown preview is visible) sounds about right.

[cakecatz]

What about use setInterval with $(selector) instead onWillDispatch ?

Like this.
source
demo

[suda]

I would say that the best approach would be to create PR for package you want to control with toolbar support (in this case markdown-preview) instead of having a separate package.

[c10b10]

Have you given up on this?

[jerone]

Custom buttons are on the backlog, but to quote myself from #79 (comment):

Without the user having a way to manage those third-party buttons, the user has no control of disabling if they don't want that. #49 needs to be implemented first...
...
If I look for example to my statusbar, it's already getting cluttered with tiles I don't use or can't hide...

[jerone]

I'm reopening this issue as it's still something that's on the roadmap for the future, immediately after #49

[nkt]

Ahh, sorry. I've just cleaned up issues which opened by myself.