mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,5 Tsd.
aktive Profile

#gobject

0 Beiträge0 Beteiligte0 Beiträge heute
Fortgeführter Thread

So the conclusion is: If I want to improve what I'm using, I need to get my hands dirty and learn to write and fix that kind of software written in #GObject #C.

I'm happy there is @objfw as well which makes facing C less of a pain.

#ObjGTK probably will never be "finished", but it already helps using #GTK without me needing to learn #Rust, which I won't be able to achieve in my spare hours.

It's not that I'm a great fan of the #GObject type system and its way to build object-oriented code in C. I know some of the maintainers aren't as well, which I don't consider a surprise given the age and origin of that GObject ecosystem. So I absolutely understand #Canonical considered switching to #Qt for #Unity8, now #Lomiri.

But that's only one part of the story. The other part is I'm now using #GTK based desktop environments almost full time (only some occasions I turn on my old Mac).

Guten Morgen Pinguine! Eine kleine Info / Status update \o/

Ein erster Meilenstein ist erreicht! Ich habe heute einen ersten tag (0.0.1) für libcxmpp erstellt. Es ist nicht viel, aber ein Anfang.

#libcxmpp besteht aus einer kleinen Menge von #GObject types. Diese sollen eine einfach zu verwendete Schnittstelle für Funktionen rundum #XMPP bereitstellen. Aktuell ist es möglich, dass sich ein Client mit einem XMPP Server verbindet, eine presence schickt. Den roster abfragt und einfach Nachrichten (type chat) senden und empfangen kann.

Hierfür habe ich eine Demo Implementierung im Projekt angelegt. Dies sieht dann wie folgt aus.

Loading Client Manager...
XMPP> connect
XMPP Connect - JID> demo@domain.tld
XMPP Connect - PWD> 123456
XMPP> Client has been connected with XMPP Server

XMPP> presence
XMPP> message
XMPP Message - JID> stefan@domain.tld
XMPP Message - Text> Hallo! Das ist ein Test :)
XMPP> Message from stefan@domain.tld/Coffein: Hallo. Die Nachricht ist angekommen.
Anwendungsdesign muss ich mir noch mal genauer überlegen. Der ersten Entwurf beinhaltet einen CM (Connection Manager). Der Connection Manager soll alle Accounts und Connections verwalten. Die Connection ist eine funktionale Sicht auf die XMPP Verbindung, währen der XMPP Wrapper die technische Implementierung via #libstrophe bereitstellt.

Der Client kann sich mit Signalen verbinden - #signal :-x

g_signal_connect_object(connection, "connected",
G_CALLBACK(cxmpp_connected), connection,
G_CONNECT_SWAPPED);

g_signal_connect_object(connection, "new-contact",
G_CALLBACK(new_contact), connection,
G_CONNECT_SWAPPED);

g_signal_connect_object(connection, "new-chat-message",
G_CALLBACK(new_chat_message), connection,
G_CONNECT_SWAPPED);
Ausblick für den nächsten Meilenstein

Als Backend solle eine #sqlite Datenbank verwendet werden. Verschlüsselung im ersten Schritt mit #OpenPGP #OX via #GnuPG. Ziel ist es, dass ich im ersten Schritt die Implementierung von #xmppc (ein XMPP command line client) auf #libcxmpp umstellen kann.

Code ist auf #Codeberg https://codeberg.org/devLUG/libcxmpp

Happy chatting!

#Messenger #Debian #GNU #Linux #Jabber
Codeberg.orglibcxmppA XMPP library
Hat jemand eine Idee was ich falsch mache?

Ich habe ein Signal registriert:

g_signal_new("xmpp-new-contact", G_TYPE_FROM_CLASS(klass), G_SIGNAL_RUN_LAST, 0, NULL, NULL, NULL, G_TYPE_POINTER, 1, G_TYPE_POINTER);

Ich habe es jetzt so geworfen:

g_signal_emit_by_name(userdata, "xmpp-new-contact", 1, buddy);

Ich möchte gerne einen Parameter ( struct buddy_t ) an das Signal übergeben.

static void xmpp_new_contact(XmppConnection *self, int n, ... ) {
va_list args;
va_start(args, n);
for (int i = 0; i < n; i++) {
buddy_t* buddy = va_arg(args, buddy_t* );
g_log(G_LOG_DOMAIN, G_LOG_LEVEL_MESSAGE, "Contact: %s", buddy->jid);
}
va_end(args);
}
Das ist aber wohl nicht ganz richtig,....

#gtk #GObject

okay, i think i don't entirely understand when i should claim a reference using g_object_ref and when i shouldn't #GLib #GObject

question 1: should a function that returns a pointer to an object g_object_ref it for the caller's sake?

I have not blogged or talked about the follow-up work to my "GType Next" blog post that I've been doing in my spare time, mainly because it is happening *in my spare time*, and I don't want to give false impressions to people; the other reason is that the time consuming bit is not writing a bunch of code, but it's planning ahead, because the goal is to avoid breaking stuff at all costs…

i still dislike the way you have to write a lot of boilerplate code every time you want to write a new class in #GObject, but given that it's basically an OOP framework bolted on top of C, i understand why

i tried using #Vala to solve the problem, but encountered different, less solvable problems there

either way, things go on, now i'm trying to figure out how signals work

#RayLib + #Vala bindings + #OOP #GObject wrapper library written in #Vala = the *best* #gamedev experience of all time!!??
Well, we are working on it! :D At least @halfmexican is one of them!
Check out the vapi and WIP wrapper library, for example look at this beautiful `RaylibOOP.Color` class: github.com/Charadon/raylib-vap
Also this library can of course be used by *all* other GObject language bindings.
And this sample is just the first, more are coming! For direct updates join our discord server!

Write your own Wayland Desktop!
The "Astal" framework, which is written in Vala, makes it super-simple! (you can use it with any gobject-introspection language though)
aylur.github.io/astal/
Here a WIP project from our community. So far a custom status bar, quick settings, MPRIS, etc. Together with the Hyprland window manager. Built with #GTK4, #Blueprint, #Libadwaita and of course #Vala!
github.com/ARKye03/morghulis