We switched to a manual approval system for registration on this forum, as this makes it easier to keep bots out of the forum. We'll approve everybody who doesn't look like a bot!
Discusson about MacBook pro touch bar implementation
Hi, i've started working on the implementation of the touchbar for Zettlr.
I think it might be a really nice and usefull feature for who has it.
As @hendrik suggested me i'me writing this post to collect some ideas and discuss about how it should look and what it should implement.
I think that a great implementation would be to have a first menù with formatting, toc, and pomodoro buttons, and on the complete right the actual pomodoro timer view.
These two images attached are not intended to be the actual implementation or style it's Just a test to make myself clearer.
Thanks, Marco.
Tagged:
Comments
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):
But these are, I suppose, only the most common and logical choices. I presume with the Touchbar, a lot more might be possible!
I'll start working on the first two points, but I have two main questions:
Where I can find the function to call from the formatting part?
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?
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:
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
Hope that helps
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
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.
I originally started everything out as
Zettlr-<something>.js
in thesource/main
-folder, but I switched to a more sophisticated system over the past year, because it makes more sense. The "big" classes prefixed withZettlr-
are more or less "deprecated", because from a developer's perspective, this makes more sense: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
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!
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.
Huh, what API do you mean? Sorry, I've been out of this discussion for some time!