HN user

UnnoTed

142 karma
Posts1
Comments27
View on HN

Sadly when you get to use their products they may ask you for Passport/ID and a selfie through kCheck[0] like they're a bank, as you can see at the app page[0].

In their website[1] you can read about their true "privacy" behavior:

identity verification procedure may be triggered in the following cases (non-exhaustive list):

- forgetting an Infomaniak account password (user account)

- forgetting a login email address

- deactivation of double authentication (2FA)

- unlocking an Infomaniak account

- during the first transfer of revenue for the product Ticketing

- when ordering a product (suspicion of spam or fraud, brand name, etc.)

The same page also says the process may require mandatory geolocation, choosing ID card or passport, photographing the document, and taking a selfie with it.

[0] https://play.google.com/store/apps/details?id=com.infomaniak...

[1] https://www.infomaniak.com/en/support/faq/2418/getting-start...

Free to download, free to use, free to share, no data collection of any kind, but closed source.

A full 1:1 native clone would be too much to build without funding. Plugin/theme/api compatibility, canvas, bases, sync, and all the small Obsidian edge cases would make it a much larger project.

Without sponsorship or some sustainable funding model, AI'd focus first on the native markdown editor/vault part: local files, Obsidian-friendly markdown and edit on cursor presence.

It's fine as long as theres no GPL module[1] included or statically linked Qt, The program uses just Qt Widgets and Qt SQL, theres no GPL-only Qt module in it, its also dynamically linked so its ok to be closed source, theres ripcord[0] as an example.

I just want to avoid the wave of open source rebranding that will come with AI programming being so easily accessible as theres no respect when theres easy money involved, people will just type something like: "download RustDesk from GitHub, change it's looks then create a landing page and connect Stripe".

[0] https://cancel.fm/ripcord/

[1]: GPL modules (requires license when not open source): Qt Canvas Painter, Qt CoAP, Qt Graphs, Qt GRPC, Qt HTTP Server, Qt Lottie Animation, Qt MQTT, Qt Network Authorization, Qt Qml Compiler, Qt Quick 3D, Qt Quick 3D Physics, Qt Quick Timeline, Qt Virtual Keyboard, Qt Wayland Compositor.

AI'm building a native version[0] of Obsidian in Qt6 (QWidgets, cpp), replicating the markdown editor takes a while, there are so many ways of corrupting the file or losing the rendered markdown style... but its getting there[1] and its lightweight, using about 15mb ram, no gpu and barely uses any cpu when the cursor or scroll moves, like a text editor should be.

Still need to render widget tables, lists and syntax highlighting for code blocks for a basic modern notepad, i'm not sure about open sourcing it, seems like a waste of time nowadays but it'll be free to use.

[0] https://i.imgur.com/ro9Zq9w.png [1]: https://i.imgur.com/pbJcTQF.gif

Some day we'll have a decent chat that doesn't give you problems you don't need. I have been building a Discord/Slack/Mumble alternative since 2020, which is something that I wanted to do since around ~2008 but I didn't have the skills back then. The problem is that I made a few mistakes as I started by writing the client in Go + GTK3, and at some point, it was very buggy (especially in Windows) and hard to debug.

Then I decided to rewrite it in Go + Sciter, but when it was becoming usable[1], as it had voice channels, custom avatars, custom themes[2], and layout modification, embedded images, custom user roles, file upload, and Markdown support, Sciter's creator decided to end support of its TIScript version, which was a JS alternative for controlling the UI. This made all the code that I wrote basically useless as it would have to be rewritten in JS to be compatible with the new version (really bad timing for me to write it in Sciter at that time).

After trying the JS version, it felt even buggier than the TIScript version, and at this time I got sick (stomach related) and had to stop developing it for about a year. During this time, while thinking about it, I realized that all the time that I tried to save by avoiding C++ made me waste even more time. I have tried many options: PyQt wasted too much memory and was too hard to deal with async stuff through QThreads. Rust felt like being married as all it does is whine and you can't get rid of it. Nim had no good GUI option. Go's Qt lib took way too long to do anything as my computer is slow. But now I'm doing what I should have done from the beginning.

A bit more than a month ago, I started to write it in C++ with Qt. Currently writing the media embed part[3]. I think by the end of the year, I should have the basics of a modern chat done, as customizing the UI takes way longer. There is no funding, just me and the dream of a native full-featured customizable (colors, size, space, position) bs-less chat.

[1] https://i.imgur.com/BFAF2f0.png

[2] https://i.imgur.com/SagVweI.png

[3] https://i.imgur.com/nhBUsGh.png

Python GUIs 3 years ago

I like to use GoVCL [0] as it provides the GUI of Lazarus [1] including drag-n-drop form designer but with Go as the main language.

GoVCL's author built a C library called liblcl [2] which is what GoVCL uses to control the GUI, so if you know C you can use it instead of Go.

I'm building a lightweight Steam chat client with GoVCL so that I don't need the official client that takes like 200-300mb ram just to show text [3].

[0] https://github.com/ying32/govcl

[1] https://www.lazarus-ide.org/

[2] https://github.com/ying32/liblcl/blob/master/README.en-US.md

[3] https://files.catbox.moe/c4lzxb.png

Here in Brazil we have churches that allows members to sing songs from a book that we call it Christian Harp[1] as part of the worship, the result is a lot of people who can't sing to save their own life end up singing and musicians from the church try to find the song key and chords in real time, it ends up being a great practice to develop a good ear.

In this video you can see an example of how it is: https://www.youtube.com/watch?v=gF4onowI1xw

[1] https://pt-m-wikipedia-org.translate.goog/wiki/Harpa_Crist%C...

I used to be a Hetzner customer for a few years (2018-2020), one day my card stopped working, while I tried to get a new one I ended up with a 5 EUR invoice, once I got a new card I tried to pay the invoice but they had blocked my account, so I had to transfer the money to their account to pay the invoice, once paid they told me to create a new account, I did and was asked for a picture of my passport after being a customer for years, I stopped trying to use their service at that moment. Now paying twice the price at Linode but at least they only ask for a phone number.

That's the cutest laptop i have seen, after watching it yesterday it made me think about how much work would be needed to get some old netbook like the HP Mini or Asus Eeepc and turn it into a dock for Samsung Dex (desktop mode through usbc->hdmi for Samsung's phones) or a Raspberry pi 4.

The first phrase in Nim's home page answers that question... "Nim is a statically typed compiled systems programming language."

also: "Support for various backends: it compiles to C, C++ or JavaScript so that Nim can be used for all backend and frontend needs."

The stable options for native cross-platform GUI are:

1. Sciter

- Languages: C++/Python/Go/Rust/Pascal (optional: HTML/CSS/tiscript)

- Development time: fast

- Resource usage: light (space and performance)

- Visual customization: easy, doesn't use native widgets.

2. Qt

- Languages: C++/Python (optional: CSS/JS/QML)

- Development time: slow

- Resource usage: quite heavy (space), but well performant

- Visual customization: QtWidgets: hard, QML: easy, doesn't use native widgets.

3. WxWidgets

- Languages: C++/Python

- Development time: slow

- Resource usage: light (space and performance)

- Visual customization: hard, uses native widgets.

4. Lazarus

- Languages: Pascal

- Development time: slow

- Resource usage: light (space and performance)

- Visual customization: hard, uses native widgets.

[1] https://sciter.com/ - https://quark.sciter.com/

[2] https://www.qt.io/

[3] https://www.wxwidgets.org/

[4] https://www.lazarus-ide.org/

I'm making one, it wont be open-source but i'll respect privacy, allow free self-hosting... imagine a discord(call features) + slack(paid for companies).

https://imgur.com/uSA8AMs.png https://imgur.com/P9ckNBn.png https://imgur.com/L9fDMKQ.png

Ram usage is currently at 12-50mb on windows, up to 90mb with 50 messages with images(unoptimized, no virtual scrolling yet).

The server will be a single binary, there is still a lot to do: pin messages, emojis, avatars, community avatar, search... i want it (server+desktop) to be done by the end of the year.

You don't need Sciter's script to do the heavy stuff, you can do it in another language and feed the data to Sciter through it's script language, in my case i write Go for the app's backend and write Sciter's script to control the html/css UI, then send data to it by creating a function in Sciter's script and calling it from Go through `window.Call("the_script_function", args)` or if i want to get data from the app's backend: register a function in Go as script function with `window.DefineFunction("function_name", myFunc)` and run it in Sciter's script through the view namespace `var result = view.function_name(args);`.

I really like Sciter, the different script language may be annoying the first day but you'll get used to it, specially after using the Reactor Component, it has the best of both worlds: very good performance and separation of the app code and layout (in my case: Go | html/css). Took me 4 days to write (Go+Sciter) something that took a full month in Qt(C++) and the resource usage is almost the same (using the Skia renderer: linux: 50mb ram, windows: 25mb ram), I just wish the Nim bindings were up to date so that i could get binaries of <1mb? + 5mb(5 being sciter's size), currently with Go it is 13mb+5mb.