Mogan v1.1.2 Roadmap

#1

Plan

Tasks Breakdown

  • Community
    • Issue and Pull Request template
    • Official Static Site https://mogan.app
      • [DONE] setup DNS by @darcy
      • [DONE] static site generator by @pikachuhy
      • [DONE] Github Action to publish
    • Developers’ Guide
      • [DONE] developers’ guide using xmake on GNU/Linux by @darcy
      • [DONE] developers’ guide using xmake on macOS by @darcy
      • [DONE] developers’ guide using xmake on Windows
    • [DONE] Install Guide by @darcy and many contributors
    • [TODO] Plugins Update (for macOS M1 homebrew)
  • Migrate from CMake to xmake
    • [DONE] xmake build definition and Github Action CI on Ubuntu by @jingkaimori
    • [DONE] xmake build definition and Github Action CI on Windows by @jingkaimori
    • [DONE] xmake build definition and Github Action CI on macOS by @darcy
    • [DONE] xmake Github CI Cache by @darcy
    • [DONE] xmake packager for Windows @jingkaimori
    • [DONE] xmake packager for GNU/Linux
    • [DONE] xmake packager for macOS by @darcy
  • [DONE] Support macOS M1
  • Support brew install mogan
  • Support Ubuntu ppa
  • [DONE] Support Noto CJK fonts
  • Experimental WASM Support
    • [DONE] Initial adaption based on @mgubi 's work by @yufens
    • [WIP] xmake build definition by @darcy
  • Bug fixes
8 Likes
Happy Spring Festival! And plans about Mogan v1.1.2
Mogan Editor v1.1.2: add macOS arm and Ubuntu support
#2

I presume that’s a typo? Should be 2023 instead of 2022.

1 Like
#3

I hope to have a format pane in addition to the toolbars for easier formatting.

1 Like
#4

Is markdown support still a planned feature ?
Editing documents with Texmacs with the ability to later use the markdown documents with quarto could be awesome.

#5

@fbob, I can understand the “appeal” of using a polished system, but this goes again in the direction of unnecessary complexity. TeXmacs can already produce HTML and PDF without quarto. Admittedly the HTML from Quarto is “nicer” but instead of spending energy to try to couple TeXmacs with another software, I guess we should spend (less) energy to be able to drive the production of more versatile output from TeXmacs itself. So I would instead propose to create stylesheets and macros which (maybe using ideas and templates from Quarto or whatever) produce nice HTML/PDF/whatever.

2 Likes
#6

Just to explain better my point: what you are proposing is that content should go through: TeXmacs -> markdown -> pandoc -> LaTeX -> PDF (if you want PDF). So ugly, repetitive, complex, full of compromises. I just tried the Quarto HTML presentations and they are amazing, we should aim to produce presentations in the same HTML format directly from TeXmacs, cutting away all that complexity. Maybe export to pandoc just to support Word and other minor formats, but then we can just target the pandoc format itself, which is the common ground for all pandoc conversions.

1 Like
#7

We will release Mogan Mark for Markdown documents.

2 Likes
#8

@mgubi thank you for sharing your points with which I mostly agree, in particular :

Just to clarify, I don’t think using markdown to generate pdf is interesting, Texmacs already does that very well. The idea is not to use a crazy and unproductive workflow.

An export to a “gateway”/generic format is reassuring for new users, powerful for confirmed ones. Pandoc seems to be one of the best placed candidates indeed.

Where I may have been wrong is how much energy and willpower Texmacs developers could devote to developing Quarto equivalent features in Texmacs. This is why a quality export to markdown seemed relevant to me.

The idea of supporting an export to a “gateway” format is also to avoid having to reinvent everything, but I understand very well the idea of wanting to do it in Texmacs, it is indeed strategically the best way to attract the most people.

#9

Thanks @darcy for the feedback
Does it mean that “Mogan Mark” will have its own development i.e somehow independent of Mogan ?

1 Like
#10

Yes. Besides Mogan Mark, we will release:

  • Mogan Code
  • Mogan Beamer
  • Mogan Draw
  • Mogan Lab
#11

May I ask you the ideas behind this branch, it sounds very exciting.

#12

Mogan Mark/Code/Beamer/Draw/Lab shares the GNU TeXmacs kernel.

The only difference is the UI:

  • Keyboard Bindings
  • Menu
  • Toolbar
  • …

For the implementation, we need:

  • xxx-menu.scm
  • init-mogan-xyz.scm
  • init-mogan-xyz-buffer.scm
  • …
#13

OK got it, thanks @darcy :+1:
Sorry, I’m not a developer, but it means that the GUI will be easier to maintain and develop if those are separates app than switching the GUI on the fly according to the document type ?

#14

Mogan Mark, just like other Markdown Editor, it is focused on Markdown Editing. It can only be used to edit *.md files.

#15

To clarify, it is a long-term plan.

#16

Why do you want to make separate programs for code, beamer, etc.? Menu’s, toolbars and keyboard binding are already context-dependent.

1 Like
#17

One project we would like to explore as an spin-off is to have a lightweight version of TeXmacs which compiles to webasm and does not use Qt but draws everything in the browser with javascript/HTML/canvas. We would need only binding to S7 and maybe freetype and explore some more fancy UI which are possible by coding directly the javascript/HTML. Put the typesetting engine in a separate thread for more responsivity. I’m in if somebody wants to join.

2 Likes
#18

I’ve explained to you why we need Mogan and Mogan Beamer.

Let me explain why we need Mogan Code. Because I need Mogan Code. That’s the most important reason. Not all people like the big app which have multiple functionalities.

In China, WeChat is blamed for its’ extra functionality. We could pay and shop on WeChat. Some people blame it, while others love it. There are different tastes indeed. I want to attract more people.

#19

I’m interested in this as well, not sure how hard it would be though. I’ve heard that WebAssembly is slow when manipulating the DOM, so maybe we still need Qt to render the canvas? Happy to hear your thoughts!

Right now, I’m testing to upload local file to WebAssembly, it would be the first step :slight_smile:

3 Likes
#20

I am not sure whether it is blamed purely out of extra functionalities, its cumbersomeness due to that, or the monopoly out of that. The last is similar to Microsoft including Internet Explorer in Windows, which might lead to a company controlling everything of its users, including (abuse) of privacy. There is the KISS principle in the Unix world, but general users do not seem to care about that.

Emacs has many functionalities but it seems to be less blamed for that.

2 Likes