Follow

I'm so fed up with all those web apps & browser tabs, I wrote my own Mastodon client in Go & QML 😊

I know that's quite the tease, but soon enough I'll release this publicly - and if you're really curious, with a bit of digging around you can actually already find it online. You know, just in case you want to join in and help me develop this thing 😆

@fribbledom Another client that I can test against my project uguuu

@fribbledom Found it. Probably gonna try it out when I get home. :)

@fribbledom I would suggest a different name than Chirp as that's more bird-like than Mastodon like.

Maybe Trumpet?

@brandon

Admittedly it also supports Twitter, even though I essentially gave up on that, since their API is really useless these days.

I wouldn't mind another name, but its accounts are pluggable, so it may support more than just one service eventually.

Personally, I really badly want it to support GitHub notifications as well.

Just some food for thought when it comes to naming discussions.

@fribbledom Do you plan on supporting standard oauth so users don't need to grab api keys?

@fribbledom
Sweet, are you accepting/wanting pull requests? Or would you rather people wait until you have everything laid out?

@deidyomega

Always open for contributors! I just have a bunch of commits piled up, almost ready to push. I'd rather not waste anyone's time checking out the current state of the GitHub repository just yet... but you can find it there, should you really fancy taking a look.

@fribbledom
Okay cool, I'll pull this weekend and check it out. :)

@aCuteLittleBox

It's a user interface markup language. Basically the way I write the UI.

See: en.wikipedia.org/wiki/QML

@fribbledom great job! Now we have one more nice client for mastodon/pleroma, but now written with QML 😋️

This seems pretty nice in fact, have you used some visual library toolkit? Vanilla QML does not have that nice styles, as far as I know...

@alexcleac

That's just the standard QML Material style. But you can pick any other QML style as well, of course.

@fribbledom oh, I was thinking, why it feels so familliar. I used to love Material Design for some time ago :)

@desitively

Let me first push a bunch of things before I'll post the URL here directly.

I'm a bit afraid people may already jump at it, when the current state of git master really isn't quite there yet.

You can find it on my GitHub profile though, should you really fancy taking a look 😉

@fribbledom Nice. I was looking at Go+QML for something for work but quickly discarded the idea as it seemed quite complex and getting even just examples to run wasn't easy. Admittedly, I'm bad at Go and totally clueless about GOPATH. (The Go Qt library didn't work with Go modules when I tried)

@fribbledom "Don't try to to bypass GOPATH" is not what I wanted to hear :D

Nice videos regardless. I learned about context and autocert (though I'd probably not use latter)

@minus

It's the best advice, though. You can point your GOPATH anywhere you want, but don't try to fight the directory structure & conventions within it.

The import system was designed to work with how we develop software these days in mind. Don't use relative paths, but always specify a full canonical import path.

You'll realize all the benefits that come along with that in no time, promised.

@Wolf480pl

GOPATH is the root of your workspace. Within it you'll find a directory structure that resembles something like this:

src/github.com/username/project

This helps Go to (automatically) resolve imports with full canonical paths. For example you can do

import "github.com/foo/bar"

in your code. Go would import that package (and potentially git clone from GitHub first) from $GOPATH/src/github.com/foo/bar

@minus

@fribbledom @minus
hm... ok, so instead of

src/main/java/com.github.username.project

and doing CLASSPATH="src/main/java:$CLASSPATH"

you do

src/main/go/github.com/username/project

and then GOPATH="src/main/go:$GOPATH"
?

@fribbledom @minus
(except in Java you wouldn't keep your .class files in source dir, so you'd put the binary dir in CLASSPATH not the source dir, but that's a minor detail)

@fribbledom @minus
wait but you can't do it since the package name would become

github.com/username/project/src/main/go/github.com/username/project

wtf... why does GOPATH need to point outside of your git repo?

@Wolf480pl

The GOPATH env-var is a build-time setting. It tells Go where to find (and store) your imports. It has no effect at runtime. So it's more like the -I and -L parameters for gcc than a Java CLASSPATH.

@minus

@fribbledom @minus yeah, I get that part.

But I just realized that Go doesn't allow multiple projects to share namespace, because the git URL of the project is part of its namespace.

This not only forces you to point your GOPATH 3 directories above your git clone, and to maintain a directory

@Wolf480pl

Actually it kind of does: each package is restricted to exactly one directory.

In other words:

github.com/foo/bar is an entirely different package than github.com/foo/bar/abc (abc is not included by its parent).

Yes, this is convention: Your GOPATH will contain your project(s) in the directory structure I laid out in the previous toot.

@minus

@fribbledom @minus
Is this just a convention, or is it enforced by the buildsystem?
i.e. if I want to have two repositories: repoA and repoB, and packages foo/bar and foo baz, like this:

repoA/foo/bar
reboB/foo/bar
repoB/foo/baz

is it possible?

@Wolf480pl

An import "repoA/foo/bar" will be searched for in $GOPATH/src/repoA/foo/bar - So the "src" part is enforced when using GOPATH.

Other than that: yes, absolutely common and valid layout.

Unless you meant to mix or combine package bar together from two different directories? That doesn't work. You can have and use two "bar" packages, but they would live independently from each other.

@minus

@Wolf480pl

No, you're overthinking this. It really doesn't work like the Java CLASSPATH: it merely defines your import search path for the compiler at build-time.

@minus

@fribbledom @minus gopath is like, the worst thing about go

I like most other things about it

@Wolf480pl

I'd say it looks Material, but yeah, it's using QML for the UI part.

@Wolf480pl @fribbledom qt widgets system is not cute but qml is :) QML is like the web we would like to have instead one we have

@alexcleac @fribbledom
tbh I haven't really coded anything in Qt, but it looks way better than GTK3's ugly client-side decorations, and I've also heard Qt/KDE developers are more app-developer-friendly than GTK3/GNOME devs, who assume "gtk3 will only be used by gnome apps which will follow gnome design guidelines, so no, we won't let you rebind ctrl+tab"

@Wolf480pl @fribbledom truth, Qt is easier for developer to use at least because they have an IDE called Qt Creator and one of the best documentation I ever known.

I really can't understand, why GTK is that popular among people, but I like what people do with it today. It is easier to write lighter application using GTK than using Qt.

@alexcleac

Actually, I even like Qt's widgets. I'm quite probably a bit biased after more than 15 years of experience with Qt, but I've also worked with a fair share of other toolkits & widget systems. I don't think anything felt quite as polished, maintained and well documented as Qt's API.

@Wolf480pl

@donavyn

Always! Stay tuned, I'll post a release in the next few days.

@fribbledom
Looks good. Looking forward to trying. It out after I am done testing hyperspace.

@fribbledom
Funny... swapping html+js with qml... no one sees the irony?

@fribbledom
Only the amount of Javascript you tend to need when wiring up QML

@katana_steel

I strictly separate UI and the backend. There's probably about 15 lines of JavaScript in my QML, and all it does is toggle the state/label of buttons.

Everything else is written in Go.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!