161–170 of 276 posts
It's not "lite", it just lacks the basic functionality of an editor.
PS - It is either impossible or difficult to write a new file. An irrelevant endeavor, don't waste your time on it.
PS 2 - It is difficult or impossible to write a new file rather than open one. And I could go on.
It seems a lot faster than most. But what it still doesn’t replace is my favorite editor EmEditor [0] (Windows only). Like every alternative I’ve checked out, Lite blocks for a long time when opening a multi-gb file. They aren’t FOSS and probably more expensive than any other text editor, but I’d love to know what they do to have such superior large file performance (the free version is fast, the paid version even su…
I would really like something as simple as windows notepad which syncs to my devices, where the app is equally simple. A no frills fulltext search feature would be nice too. I currently use Google Keep, which is incredibly slow
This is a very nice piece of work, and I think very important: it shows that it's very much possible to make slick interfaces without using javascript/web technologies. It's also just as hackable as something like vscode or vim. I hope there's a shift back to native or semi-native applications as opposed to web-based stuff. It's certainly not perfect yet (it has some scaling/rendering issues and is slow to open large…
It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.
Earlier quoted context omitted.
There’s way less abstraction going on in Lua app that has a hand-rolled GUI versus an app built on top of a web browser like Electron. Hand rolling you’re own UI doesn’t make it less native — is Ableton Live not-native? Or are you drawing the line because Lua is a scripting language?
You seem to be the one drawing the line saying Electron isn’t vs something like this is. Is a WASM app that renders to WebGL native? I guess the point is native should probably mean “using the toolkit the OS provides” and we should just use “performant” in most cases.
e.g. compare Telegram made in Qt Widgets with Signal made with Electron - the latter is incredibly slow to come up (and has broken text rendering) while the former is more or less instant on my machine (which is an overpowered i7...): https://streamable.com/m48hg7
fun fact: approaches such as Qt or also Flutter from what I could see can be more performant than some of the OS-provided UIs of some platforms - in particular Android is a pretty slow mess while Qt has seen a lot of work poured into running on <1Ghz devices.
This is a very nice piece of work, and I think very important: it shows that it's very much possible to make slick interfaces without using javascript/web technologies. It's also just as hackable as something like vscode or vim. I hope there's a shift back to native or semi-native applications as opposed to web-based stuff. It's certainly not perfect yet (it has some scaling/rendering issues and is slow to open large…
It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.
It is not running on a web browser shaped to act like a text editor instead.
Typing latency as measured by typometer is quite high on kwin (no compositing). Both kate and Howl do much better. And pycharm. Great start, but it's not defeating vscode in the one aspect I care about: typing latency. Kate is a surprisingly good/fast editor nowadays.
Earlier quoted context omitted.
Yes, the rendering implementation uses gray-scale antialiasing. But system uses ClearType - compare rendering in window caption (rendered by Windows) and the text inside client area. Gray-scale may work on high-DPI monitors, but on typical monitors it will be blurry. But Apple and Microsoft still use ClearType even on high-dpi monitors. For that matter, Sublime Text, that uses similar architecture (but Python instead…
Apple removed all subpixel antialiasing on Mojave [1] and on Windows it isn't used for any 'modern' app using UWP onwards afaik [1] https://arstechnica.com/features/2018/09/macos-10-14-mojave-...
This is a very nice piece of work, and I think very important: it shows that it's very much possible to make slick interfaces without using javascript/web technologies. It's also just as hackable as something like vscode or vim. I hope there's a shift back to native or semi-native applications as opposed to web-based stuff. It's certainly not perfect yet (it has some scaling/rendering issues and is slow to open large…
It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.
It's more "native" because the stack is much shorter, much more direct. If it was more common to have plain JS interacting directly with input APIs and plain canvas, the argument for parity would be stronger. But it's just very rarely the case.
Earlier quoted context omitted.
Not even that: SDL just provides a pixel buffer, the application draws everything itself per-pixel. Lite uses a technique I refer to as "cached software rendering" which allows the application code to be written as if it's doing a fullscreen-redrawn when it wants to update, the renderer cache (rencache.c) then works out which regions actually need to be redrawn at the end of the frame and redraws only those. You can…
FWIW this is basically "dirty rectangles" which was a very common technique for avoiding full screen updates in games back when the hardware wasn't fast enough to do that.
(Dirty rectangles are still perfectly common in desktop apps for when you e.g. drag a window back on screen after overlapping the edge, or if you scroll a window.)