Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#1538 closed enhancement (fixed)

TableOperations: add config option to control currently-forced linebreak in toolbar

Reported by: ejucovy Owned by: ejucovy
Priority: normal Milestone: 0.97
Component: Plugins Version: trunk
Severity: normal Keywords: toolbar
Cc:

Description

The TableOperations plugin always adds a linebreak to the toolbar before appending its table buttons; its code contains:

var toolbar = ["linebreak", "inserttable", "toggleborders"];

In my application I prefer a layout where the table buttons are on the same line as the buttons that precede them.

The following patch extends the existing Xinha.Config.TableOperations configuration object to let the user control whether this forced-linebreak behavior is active.

Attachments (1)

tablelinebreak.diff (1.6 KB) - added by guest 7 years ago.

Download all attachments as: .zip

Change History (5)

Changed 7 years ago by guest

comment:1 Changed 6 years ago by ejucovy

  • Cc ejucovy@… removed
  • Owner set to ejucovy

To clarify: my configuration also uses cfg.flowToolbars = false.

comment:2 Changed 6 years ago by ejucovy

  • Resolution set to fixed
  • Status changed from new to closed

Since it doesn't *force* a linebreak unless flowToolbars is set to false, forceToolbarLineBreak is badly named. I renamed it to addToolbarLineBreak and committed in r1282.

comment:3 Changed 6 years ago by ejucovy

  • Keywords toolbar added
  • Reporter changed from guest to ejucovy

Hmm, I do just want to add that this is a pretty silly solution -- but I can't think of a better one. There are a couple of issues that make me feel like an overhaul of the toolbar system would be useful -- some kind of alternative configuration that would let the user (meaning, the person who configures Xinha) *fully* specify the toolbar, after all plugins have registered their buttons. Among other things, this would require some kind of sensible API for querying the available buttons. It would also have to be fully backwards-compatible and let plugins continue to try to register "sensible default" locations in the way they do now. And, I have no idea what it would look like for the end-user.

So this is obviously a bigger project. I'm going to start tagging tickets with the keyword "toolbar" to keep track of the various use-cases as I see them.

comment:4 Changed 6 years ago by ejucovy

  • Milestone set to 0.97
Note: See TracTickets for help on using tickets.