Discusson about MacBook pro touch bar implementation

Comments

• hendrik

  October 2019

  Thanks for the post!

  Just for reference, here the ideas that I had in mind for that thing (although I don't have one, so it's purely hypothetical):

  1. By default, mirror the Toolbar on the Touchbar for quicker access. If pressing one of the toolbar buttons, try to display the popup's contents there (e.g. the formatting menu).
  2. If the editor has focus, display only the formatting menu with a shortcut back to the Toolbar, if needed (such as the X-circle shown in the images)
  3. If the file list has focus, display a "scrubber" (at least this is what I've seen in some implementations) to move horizontally to the file list
  4. If a file with Zettelkasten-IDs is opened, add a button to expand on all linked files to visit them with one Touch, or something like that.

  But these are, I suppose, only the most common and logical choices. I presume with the Touchbar, a lot more might be possible!
• Warpcut

  October 2019 edited October 2019

  I'll start working on the first two points, but I have two main questions:

  @hendrik said:
  1. By default, mirror the Toolbar on the Touchbar for quicker access. If pressing one of the toolbar buttons, try to display the popup's contents there (e.g. the formatting menu).

  Where I can find the function to call from the formatting part?

  2. If the editor has focus, display only the formatting menu with a shortcut back to the Toolbar, if needed (such as the X-circle shown in the images)

  Here how can I check if the focus mode is on, are there any APIs already available?

  Another thing, do you already have a set of icons to use? Or we have to found a new one?
• hendrik

  October 2019

  There's currently no internal API (at least not structured, see below for a list of what might be considered an API), so what you'd need to do now is provide "mockups" for all different Touchbar-settings you'd like to introduce and call "fake-functions" that return some demonstration data. After the demo-implementation is ready, we can have a look at the necessary API-calls your provider would need to perform, see if we can optimise them and then actually implement them.

  For your purposes, if you'd like to start doing it, I've prepared a bootstrapping for a service provider:

  /**
   * @ignore
   * BEGIN HEADER
   *
   * Contains:        TouchbarProvider class
   * CVM-Role:        Service Provider
   * Maintainer:      <NAME>
   * License:         GNU GPL v3
   *
   * Description:     Controls the macOS TouchBar on those models that support it.
   *
   * END HEADER
   */
  
  /**
   * Add a description of what this provider is capable of
   */
  class TouchbarProvider {
    /**
     * Create the instance on program start and initially load the settings.
     */
    constructor () {
      // Initiate variables, etc.
  
      // Use this to check for darwin (e.g. macOS)
      if (process.platform === 'darwin') {}
    }
  
    /**
     * Shuts down the provider
     * @return {Boolean} Either True or false to indicate successful/non-successful shutdown
     */
    shutdown () {
      // Perform any necessary shutdown tasks
      return true
    }
  }
  
  module.exports = new TouchbarProvider()
  
  

  To load it correctly, simply add the provider here:

  https://github.com/Zettlr/Zettlr/blob/master/source/main/zettlr.js#L203

  It's best to add it to the end of the providers list, especially because at the beginning some providers need to be present rather soon

  Of course, you can steal some functional parts from the other controllers depending on what you want.

  Many providers and other classes register some functions to the global namespace, so if you want to see what's possible, simply do a console.log(global) for testing to see all. I just did a dump.

  I think this comes closest to what an internal API would be

    config: {
      get: [Function: get],
      set: [Function: set],
      bulkSet: [Function: bulkSet],
      on: [Function: on],
      off: [Function: off],
      save: [Function: save],
      addPath: [Function: addPath],
      removePath: [Function: removePath]
    },
    watchdog: {
      addPath: [Function: addPath],
      ignoreNext: [Function: ignoreNext],
      stop: [Function: stop],
      on: [Function: on],
      off: [Function: off]
    },
    citeproc: {
      getIDs: [Function: getIDs],
      getCitation: [Function: getCitation],
      updateItems: [Function: updateItems],
      makeBibliography: [Function: makeBibliography]
    },
    dict: {
      on: [Function: on],
      off: [Function: off],
      getUserDictionary: [Function: getUserDictionary],
      setUserDictionary: [Function: setUserDictionary]
    },
    recentDocs: {
      add: [Function: add],
      clear: [Function: clear],
      get: [Function: get],
      hasDocs: [Function: hasDocs]
    },
    tags: {
      report: [Function: report],
      remove: [Function: remove],
      getTagDatabase: [Function: getTagDatabase],
      getSpecialTags: [Function: getSpecialTags],
      update: [Function: update]
    },
    css: {
      get: [Function: get],
      getPath: [Function: getPath],
      set: [Function: set]
    },
    translations: {
      getAvailableLanguages: [Function: getAvailableLanguages],
      requestLanguage: [Function: requestLanguage]
    },
    ipc: {
      send: [Function: send],
      notify: [Function: notify],
      notifyError: [Function: notifyError] /* The same as notify, but it displays a dialog with more information */
    },
    application: {
      isBooting: [Function: isBooting],
      fileUpdate: [Function: fileUpdate],
      dirUpdate: [Function: dirUpdate],
      notifyChange: [Function: notifyChange],
      findFile: [Function: findFile],
      findDir: [Function: findDir]
    },
    targets: {
      set: [Function: set],
      get: [Function: get],
      remove: [Function: remove],
      on: [Function: on],
      off: [Function: off]
    },
    refreshMenu: [Function]
  
  

  Hope that helps
• hendrik

  October 2019

  Another thing, do you already have a set of icons to use? Or we have to found a new one?

  Concerning this, btw: We'll eventually switch to our own, but until now there's a font in one of the assets folder: WebHostingHub Glyphs. Have a look here: https://www.webhostinghub.com/glyphs/

  This is the one Zettlr uses now and will be for the time being
• Warpcut

  October 2019

  Actually i tried to implement it already, you can try it on my fork, right now i putted it i to the main folder as Zettlr-touchbar.js.
  Why you think it should go under service provider? What will be the main difference?
  I have found a main problem right now and i think is related to electron imolementation itself. With more elements that can actually be displayed for space there is no overflow feature, it Just display the one that can fin into the touchbar without the possibility of scrolling. I asked the electron team if they can provide me the docs of electron 7/8 to see if the problem will be resolved in the next versions.
  Otherwise we will have to find a workaround, maybe putting Just the most used tools in the touchbar.
• hendrik

  October 2019

  Actually i tried to implement it already, you can try it on my fork, right now i putted it i to the main folder as Zettlr-touchbar.js.
  Why you think it should go under service provider? What will be the main difference?

  I originally started everything out as Zettlr-<something>.js in the source/main-folder, but I switched to a more sophisticated system over the past year, because it makes more sense. The "big" classes prefixed with Zettlr- are more or less "deprecated", because from a developer's perspective, this makes more sense:

  • Zettlr-prefixed classes: Base-classes that have to be kept in memory indefinitely but that are accessed asynchronously and perform interfacing functions between the deeper logic and the Electron framework.
  • Service-providers: Are called providers because they provide a service to the whole of the app — for instance the appearance-provider has to run continuously to announce changes in the theme, the config-provider provides on-demand-access to configuration variables and the tag-provider provides useful functions pertaining to tagging.
  • Commands: Very simple modules that are executed once a respective command is received and executed in the main Zettlr-object. They can call additional modules or simply execute a short sequence of functions to achieve a result.
  • Modules: Just created that folder today, I think what will be in there are pieces of code that will be called and also instantiated only when needes, for instance the exporter — we don't need to fill up the RAM unnecessarily if you don't export in a session. (Providers, on the other hand, need to be kept instantiated at all times)

  So the "main" classes are basically classes that don't fit someplace else right now But with the Touchbar it's pretty obvious: It provides an interface to the Touchbar that can be updated on-demand, so it needs to be present at all times

  … does this make sense?

  N.B.: This is not meant to be the final truth for the app, I think depending on how it goes we'll need different or more categorisations, but I tend to keep it fluid for the classes I'm not sure where to put otherwise
• hendrik

  October 2019

  Oh and concerning the Electron-issue: Didn't surprise me, they have a faible for bugs and errors in the last months Nevertheless, the feature can take time, as it doesn't affect that many people and better have something good than quick!
• Warpcut

  December 2019

  Any news on the api? I'm still not able to use the function of the menu and to get tomato information and stuff...
  Or at least where should them be located? I can try to implement them myself.
• hendrik

  December 2019

  Huh, what API do you mean? Sorry, I've been out of this discussion for some time!