search

lektor / lektor

The lektor static file content management system
https://www.getlektor.com/
BSD 3-Clause "New" or "Revised" License
3.84k stars 309 forks source link

Create apps for all systems? #760

Open goanpeca opened 4 years ago

goanpeca commented 4 years ago

See: https://build-system.fman.io/

runfalk commented 4 years ago

I see, the things that are a bit questionable is the Licensing. Would that affect end users of our packaged product?

I guess you are suggesting that we use a Qt web view to show the admin? If so I guess it can constrain which web technologies we can use? (I don't know which capabilities that it has). The nice thing about Electron is that we know it supports whatever Chromium does.

goanpeca commented 4 years ago

Would that affect end users of our packaged product?

Not really because this is open source 🤷

If so I guess it can constrain which web technologies we can use?

It is chromium like

https://wiki.qt.io/QtWebEngine

andoresuperesu commented 4 years ago

I'm in on this if this is to create only a multiplatform desktop app. I'm an fman user and have had the desire to test the build system for a while. Qt is a robust and tested way to create desktop apps. However, Lektor's license is not stated as GPL, which exposes us to charges as I understand it. So licensing concerns seem genuine.

tino commented 4 years ago

How about using BeeWare's Briefcase?

nixjdm commented 4 years ago

This follows up on #420 where there was a little discussion on remaking the desktop app.

I may misunderstand, but I think if we use fman build system, we could only be constrained by LGPL if we choose the PySide2 option instead of PyQT. That's not as bad.

xlotlu commented 4 years ago

Not really because this is open source shrug

That's not entirely how this works. The project's front page also states "You can use fbs for free in open source projects that are licensed under the GPL" and that seems problematic, more on that below.

I may misunderstand, but I think if we use fman build system, we could only be constrained by LGPL if we choose the PySide2 option instead of PyQT. That's not as bad.

That same section also states, "When using fbs, there are two other projects whose licensing terms you need to obey". So this constraint is in addition to fbs's own licensing terms.

I am not a lawyer, but to me that statement on the front-page smells. It is probably not enforceable, given you can get the code straight from the repository, and that would be governed by the given license, which is pure GPLv3, but it still smells. (This is not legal advice etc.)

Now, if we choose to ignore that statement (or better yet, we get the project's author to rephrase that statement in a more open-source-friendly manner), there's still the implication of that GPL'ed code: whatever binary we produce using that code will be a derived work, hence it will be automatically licensed under the GPL. If that's a problem or not to us, that's to be discussed. As a side note, the PySide2 vs PyQT issue is irrelevant, since the binary will be GPL anyway.

My suggestion, if we choose to go for fbs, is to create the desktop app as a separate repository. Separate repos would keep us away somewhat at least from the cognitive dissonance of sporting a GPL payload from a BSD project in the core repo. This could be licensed as whatever, and the resulting binary will be GPL that uses BSD code, which is just fine, and there will still be the pip install method that brings in only BSD code.

xlotlu commented 4 years ago

P.S.: I'm personally not fond of electron, and if this is a more lightweight solution I like it already, but before we make a commitment I'd still like to see a debate about pros and cons of each approach. @yagebu maybe could chime in as well, since you're already experienced in this?

nixjdm commented 4 years ago

Ah yes, I misread. I got confused by the second paragraph there. You're right, that fbs itself is still GPL, and on my plain, possibly naive interpretation, the code that uses it at a minimum has to be GPL too, and probably the binary produced. That code could be a separator repo. I'm not positive that avoids legal issues, but it seems like it? As long as we're ok with a GPLed binary?

Beeware's tools have "is a work in progress" or "experimental" in many places on their docs. I could believe that despite the early stage of development, we wouldn't have a problem, because we don't need much. Or it could be unworkable. I feel like we'd just need to try it if we wanted to go that route, and abandon it if it doesn't work out. That's a risk of wasting time, for sure, but could work out fine.

Electron definitely seems heavy, and that's a very common sentiment. I'd prefer we didn't do that again if we can avoid it.

I haven't written a fresh desktop Python app/installer in a decade, and the one I did wasn't cross platform. If there are other people with more recent experience who'd like to share, I'm all ears. :)

nixjdm commented 4 years ago

To more strongly link to it: in an older, similar issue, @yagebu talked about how Fava worked with an Electron GUI https://github.com/lektor/lektor/issues/420#issuecomment-324588736

davidism commented 4 years ago

What about BeeWare Toga (BSD-3-Clause), or Kivy (MIT)?

goanpeca commented 4 years ago

@davidism

What about BeeWare Toga (BSD-3-Clause),

Not mature enough, more work on our side.

Kivy (MIT)?

That is more a mobile thing not a desktop thing, besides app do not look native.

yagebu commented 4 years ago

As described in https://github.com/lektor/lektor/issues/420#issuecomment-324588736, Fava created an Electron app with the following steps.

  1. We use Pyinstaller to compile Fava to a single executable (currently on Python 3.5).
  2. Use electron-builder to create an installer for the Electron GUI (dmg for MacOS, AppImage for Linux). [...]

Notice the past tense above, since I removed the GUI about two years ago. The whole process worked well enough, but of course there still was the occasional maintenance effort, and there just didn't seem to be a huge interest to warrant that. I also didn't really want to release distributions that I rarely used and tested.

I still think the approach of splitting it into two separate steps worked quite well. PyInstaller is mature and stable from my experience and took care of creating a portable distribution of the CLI and then the GUI part didn't have to worry about the intricacies of creating a distribution of a Python application.

In some sense, Lektor is in a similar spot to Fava. It had this Electron app that just broke over time (and there didn't seem to be any drive to keep it working). I'm not sure if a new app created with a new shiny toolkit would fare any better over time if it tries to do "freezing a Python app" and "creating a GUI" at once.

I'm also not sure whether there is a huge user base for a fully contained GUI app - someone who manages to set up a Lektor project can probably also do a pip install lektor and teach the potential user of Lektor how to open a terminal and type in a few letter to start Lektor (or provide a hosted install of Lektor for the user - for example that's what I do for my mum and some friends). These steps could of course still be simplified by a portable distribution and a supervisor GUI app - but IMHO the development effort would (for now) be better spent on improving the existing admin UI for all users (for example by making it mobile friendly).

testbird commented 4 years ago

Minimal native website folder manager GUI builds + opening the website folder in browsers?

not sure whether there is a huge user base for a fully contained GUI app

Ok, but a larger user base may be there if taking it a step further, than say publii...

... by making the editing of the final website as easy as opening a local self-contained website project folder (with its index.html) in the browser.

As your message seems to suggest, I think the crux of the matter might be, to go for a well separated-and-complementing combination of crucial features:

Implementation brainstorm:

Here are nice examples of in-context/on-page/in-line .html file editing in javascript (no .lr support yet): Have a look at the (simple) demo at https://sitecake.com/ or the (fully featured) neos.io Demo.

[ A much more narrow example, would be the completely self-contained javascript wiki Tiddlywiki (configured as a static site generator, or as a "digital garden" ) ]

I guess there may exist even further nice "no backend" / "in-line" / "frontend" / "in-context" editors available, in addition to sitecake/neos above, to get inspiration. Please add others if you know some (or a better name for this):

https://www.createjs.org stackoverflow // are-there-any-gui-wysiwyg-cms-editor-based-on-jekyll

testbird commented 4 years ago

I have polished and sorted my last post quite a bit.

I may be saying to only create very basic lektor setup-gui apps for the different operating systems, and using nice generic web techniques for the CMS and even most of a possible lektor project management UI that may be reused for limited online editing, e.g. with webdav access to the files.

Interested in how you think about such ubiquitously manageable and editable, portable website folders.

testbird commented 4 years ago

Did you already consider running python in the browser for the admin and cms GUI? Such solutions could make a lektor website-folder even directly portable across different operating systems:

(from https://www.goffi.org/b/kmebCba3m38dr9sgzgGrkp/progress-note)

Transcrypt is a Python to JavaScript transpiler, pretty similar to what was doing the transpiler of Pyjamas. It has the advantage of staying close to JavaScript, keeping its speed, and has a system to activate/deactivate Python compatibility features depending on the needs (better compatibility may mean lower performances).

Brython on the other hand is doing the transpilation in the browser, it is like having a Python interpreter in the browser. Its has some decisive (for us) advantages: full Python compatibility, and the possibility to dynamically convert Python to JS. The Python compatibility is essential to factorise the code with other frontends, and the ability to convert Python to JS open the way for future use (like sharing code during a chat, e.g. for a school or scientific use). I've been following the Brython community for years, it is really friendly and dynamic, and the few issues I've reported online were addressed quickly.

andrearicci commented 4 years ago

I'm that kind of user: I choose Lektor for its ability to edit from the browser, still being very flexible, but it still leaves a lot to the command line. I'd love a self contained app. I tested Publii but it's too much blog-oriented, Lektor is much more flexible. My "clients" (my wife, some artist friend that just want to pulish a portfolio, difficult to build in Publii) are people who wants to update their contents but are not able to start the server to edit then go trough the build and publish (ftp) process, so maybe adding the ability to do it in the browser admin module itself could be enough. (Just encrypt the ftp password somehow, don't let it seat in clear in the project file).