Developing native applications for the GNOME platform using .NET has become significantly easier. I’m excited to introduce TenderOwl.GirCoreTemplate.CSharp, a project template that automates creating applications using Gir.Core bindings, the modern Blueprint interface markup language, and Flatpak packaging.

My journey with C# began back in 2003, and when the Gir.Core project emerged—a binding generator for GTK4 and GObject-based libraries—I couldn’t resist getting involved. Over time, I developed the idea to create a template that would streamline getting started with these technologies while enabling the use of familiar tools like GNOME Builder. This template is the result of that work.

Prerequisites

Before getting started, ensure you have the following software installed:

• .NET SDK 9.0 or newer
• Blueprint Compiler
• Flatpak with GNOME runtime (for building and testing)
• GNOME Builder (recommended for development)

Template Installation and Project Creation

Installing the Template

The template is available via NuGet and can be installed with a single command:

dotnet new install TenderOwl.GirCoreTemplate.CSharp

Creating a New Project

Create a project from the template by specifying a unique application ID (replace YOUR_APP_ID with your identifier, such as io.github.yourname.MyApp):

dotnet new gnome-gircore --app-id YOUR_APP_ID -n MyGnomeApp -o MyGnomeApp

Important: The application ID must be unique and follow the Reverse DNS standard.

Project Structure

After creating the project, you’ll see the following file structure:

your-application/
├── MyApp/
│   ├── Program.cs                     # Application entry point
│   ├── Constants.cs                   # Constants including application ID
│   └── ui/                            # User interface classes
│       └── MainWindow.cs              # Main application window
├── data/                              # Data and resource files
│   ├── icons/                         # Application icons
│   ├── ui/                            # Blueprint files
│   │   └── MainWindow.blp             # Main window layout
│   ├── __APP_ID__.desktop             # Desktop integration file
│   ├── __APP_ID__.appdata.xml         # Application metadata
│   ├── __APP_ID__.gresource.xml       # Resource definition file
│   └── __APP_ID__.gschema.xml         # GSettings schema definition
├── build-aux/                         # Build auxiliary files
│   ├── __APP_ID__.yaml                # Flatpak manifest
│   └── nuget-sources.json             # NuGet sources configuration
└── build/                             # Generated files (created during build)

Key Project Files

• Constants.cs — Contains application constants including APP_ID. When changing the ID, update it in all files using __APP_ID__.
• build-aux/__APP_ID__.yaml — Flatpak manifest defining dependencies, permissions, and build stages.
• data/ui/MainWindow.blp and ui/MainWindow.cs — UI layout and application logic pairing.
• __APP_ID__.appdata.xml — Metadata for GNOME Software Center.
• __APP_ID__.gschema.xml — Application settings schema.
• __APP_ID__.gresource.xml — Application resource definition.

Building and Running

Development with GNOME Builder (Recommended)

1. Open the project folder in GNOME Builder
2. The IDE will automatically recognize the project
3. Click “Run” to build and launch the application in the required environment

Building with flatpak-builder

To build and install the application manually, run these commands from the project root directory (replacing __APP_ID__ with your identifier):

flatpak-builder --user --install build-dir build-aux/__APP_ID__.yaml --force-clean

After installation, the application will appear in your menu and can be launched with:

flatpak run YOUR_APP_ID

Important: Running via dotnet run won’t work as the application depends on GNOME-specific features (desktop files, GSettings, resources, etc.).

Build Process

The build process is detailed in the application’s Flatpak manifest (build-aux/__APP_ID__.yaml):

1. Blueprint Compiler installation
2. .NET SDK and runtime setup
3. Application build including:
   • C# code compilation
   • Blueprint file compilation into UI resources
   • Resource compilation using gnome-compile-resources
   • Application metadata copying
   • GSettings schema compilation

Note: Any additional files required for your application must be manually added to the Flatpak manifest.

Working with Blueprint Files

Blueprint is a modern replacement for traditional XML/.ui files for describing interfaces in GNOME. When working with them:

• Files must be located in the data/ui/ directory
• Use the .blp extension—files with other extensions are ignored by the build system
• For example, MainWindow.blp will be processed, while MainWindow.foo will be ignored

Next Steps

After creating your project, you can:

1. Modify the interface — Edit files in the data/ui/ directory. Find official Blueprint documentation on the project website.
2. Add logic — Work with code in the ui/ directory. Study the Gir.Core documentation to understand available GTK APIs.
3. Configure the manifest — Open build-aux/__APP_ID__.yaml to add your application’s dependencies (e.g., for network or database functionality).
4. Add icons — Place your icons in the data/icons/ directory in appropriate sizes.

Conclusion

The TenderOwl.GirCoreTemplate.CSharp template significantly simplifies starting .NET application development for GNOME by handling all the complexity of initial build and deployment configuration. It allows you to focus on creating application functionality rather than tool configuration.

If you have questions or suggestions for improving the template, I’d be happy to discuss them in the corresponding issue of the Gir.Core repository.

Happy coding!

For more than a year now, I have been periodically returning to trying to rethink my note-taking application, Norka, to update the interface, add modern features, and finally add synchronization with the cloud.

I’ve had several attempts to use Rust to add speed and reliability to the application. I use C# (Gir.Core) for the same reasons and because I love this language. But unfortunately, in the end I returned to Python, because it and PyGObject provide the necessary development speed and support a lot of libraries that I need for my work. The Python development ecosystem for GTK looks the most mature and complete.

So, after a year of experimentation and prototyping, studying analogs and my application requirements, I started another attempt to implement Norka 2.

Inspiration

I have been working with macOS for more than 10 years and I believe that it is for this OS that the most beautiful and user-friendly applications have been created from the point of view of UX. Let’s leave beauty out of the box, as it’s a matter of taste, and turn to user experience.

I have tried working with many applications, especially considering those that have received awards for their design - Craft, Ulysses, Bear, Evernote, IA Writer, etc. I also looked at various online services such as Microsoft Loop, Confluence (and why not?) and others . At some point in time, I caught myself thinking that 2 services had become the most convenient for me: craft.do as a desktop application and web service, and Microsoft Loop as a web service. It was decided to assemble the functionality of the new version of Norka from them, namely:

• Workspaces
• A tree structure where each page can have nested pages.
• Customization of the design of pages and spaces: icons and covers help with work and just make work more fun.
• Instead of Markdown, use rich formatting in the document itself, like office software.
• The ability to publish pages, share them with other users, or make them publicly available to everyone.
• Sync with the cloud.
• Encryption of spaces and pages with password access for published pages.
• Integration with LLM both locally and externally (whether Ollama or OpenAI)
• The ability to create tasks, as implemented in Craft.
• Advanced search capabilities, calendar linking, etc.

Of course, this is not the final list, and it will be updated. However, it’s a great set to start with :)

By the way, you can follow the updates on my Twitter or on the project’s Github.

Workspaces

The first thing to do was to sort out the workspaces. The task they are designed to solve is to group pages by topic, project, or otherwise. The user can decide for himself, the main thing is to give him the opportunity. And at the same time, make it possible to add an icon, cover, and control functionality. So we get something like this:

The user can select an emoji icon and a cover from the preset images. However, in the future I plan to add integration with online services such as Pexels or Unsplash.

Workspaces contain pages that are deleted when the space is deleted. So be careful 🙂

Pages

If workspaces are complementary functionality, then creating and editing text is the main one. Therefore, it will require the most work on itself, but let’s see what has already been implemented.

Editing

Surprisingly, the fact is that pages can already be created and their contents edited. At the same time, syntax highlighting is now being used, which migrated from the first version of Norka - Markdown markup. In addition to this, I started implementing work with formatting tags, without having to use a markup language. My experience suggests that this is a more convenient option, especially if you combine it with Markdown - use markup during typing as shortcuts for tags. For example, if a user types

# The Awesome Title

, then this text will be automatically converted to a title, and the # sign at the beginning of the line will be removed like this:

The Awesome Title

This should work for titles, links, images, and other markup elements.

And if the ability to insert tags was not particularly difficult, then the issue of saving and loading required analysis and study, since the standard functionality of Gtk libraries allows you to save text, but there is no formatting in it. After trying out various data serialization options, I came to the decision not to mix content and formatting, and these two parts of the same whole should be stored separately from each other. This is about how documents are stored .docx and .odt.

Nesting

You can also nest pages inside each other and move them between workspaces. This can be done either by simply dragging the mouse or using the context menu.

The nesting is not limited, but in the future this parameter may be revised after analyzing the work on large volumes and deep nesting of pages.

To be continued

A start has been made, but there is still a lot of work ahead, both in adding new functionality and debugging interfaces and performance. It’s too early to talk about release plans, those who suffer can download the source codes and build the application themselves, everything is available on GitHub.

See you!

Laska is under active development and is not supposed to be used in production. API may change dramatically in future versions.

Intro

It’s not a secret that Dart’s popularity comes from the Flutter framework and its acceptance by the community. I love Flutter as well, but what I miss is server-side. How cool it could be to be a full-stack developer by using only Dart language?

There was a time, I want to start a new project and have to choose what technologies to use for the frontend and backend parts as well. Research gets me to Aqueduct and Shelf, both of them weren’t looking actively developing and supported and that leads me to the idea to make my own small micro-framework like Echo for Golang or Bottle for Python. And it was easy to decide: I’ve had time and motivation :)

And before we get started, I’d like to answer some questions that will definitely come up: why do we need one more framework, and what’s the problem your framework resolves? The first one is easy: ask JavaScript developers! But OK, the real answer is competition: the more frameworks we have, the more we learn from each other and, eventually, we build better apps. The second answer: it was designed and built for micro-services and small applications. Sure, there is a way to extend it with middleware and extensions that come later, but as I said I treat it as a Dart alternative to Bottle or Echo. And when I say built I mean will be built 😄

Architecture

Laska - that’s how the project is named - is a micro-framework, it’s not aimed to be a full-featured app like Django. Therefore the architecture is quite simple: every request is processed by the same process while performance is based on leveraging the async nature of Dart.

Let’s briefly review how it works.

As we can see on the diagram, asynchronous server processing works like a charm :)

I did experiment with Isolates and multiprocessing, but finally, I decided it would require the developers to work with additional limitations. It is not the way I want to use any kind of software, so why does anyone should do it? Programming should be easy and fun therefore there is no kind of parallelism in Laska.

Let’s build something

There is a trivial way to present programming languages and frameworks called ‘Hello world’. Let’s be trivial!

import 'package:laska/laska.dart';

void main() async {
  final laska = Laska();

  laska.GET('/hello/:name',
      (context) async => await context.Text("Hello ${context.param('name')}!"));

  await run(laska);
}

It’s easy to understand what’s going on here:

• initialize a Laska object
• add a handler for GET requests at the route ‘/hello/:name’, where name is a placeholder for context parameters
• code a handler that returns a string with a parameter given in the path
• and run the server

That’s it, an asynchronous server is up and running on http://localhost:3789.

More realistic example

Surely, ‘Hello world’ is not a kind of real-world application someone will deploy to production. The more realistic would be to build a server that logs user requests to the stdout and has routes that require authorization.

import 'package:laska/laska.dart';

// Custom middleware that checks user access.
class Acl implements Middleware {
  final allowedRoles;

  Acl(this.allowedRoles);

  @override
  Future<Function> execute(Function next, Context context) async {
    return (Context c) {
      // In this case it's simple check:
      // Does the request contains `role` header with `admin` value.
      final role = context.request.headers.value('role');

      // If the header's `role` is not in `allowedRoles`, reject the request.
      if (!allowedRoles.contains(role)) {
        context.Text('Role $role is not allowed.');
        return null;
      }
      print('Role $role is allowed.');

      // Don't forget to call the handler.
      return next(c);
    };
  }
}

// Custom middleware that prints request path and given prefix.
class Logger implements Middleware {
  String prefix;

  Logger(this.prefix);

  @override
  Future<Function> execute(Function next, Context context) async {
    return (Context c) {
      print('$prefix: Path: ${context.path}');

      // Don't forget to call the handler.
      return next(c);
    };
  }
}

void main() async {
  final laska = Laska();

  final acl_middleware = Acl(['admin']);

  // Add global middleware
  laska.Use(Logger('global'));

  // Create handler with per-route middlewares: logger and acl
  laska.GET('/secret', secretHandler,
      middlewares: {Logger('route'), acl_middleware});

  // Add route handler, only global middleware will apply
  laska.GET('/users', getUsers);

  // Add route with acl middleware, but only for the POST method.
  laska.POST('/users', getUsers, middlewares: {acl_middleware});

  await run(laska);
}

void secretHandler(Context context) async {
  await context.Text('You have access to secret path!');
}

void getUsers(Context context) async {
  await context.JSON([
    {'id': 1, 'name': 'Make something useful', 'status': 0},
    {'id': 2, 'name': 'Make new website', 'status': 1},
  ]);
}

I hope this code is self-explanatory but you can ask me any questions in comments :)

Roadmap

🅿️ - P is for planned.

• ✅ Dynamic routing with placeholders
• ✅ Middlewares
• ✅ JSON handling
• ✅ Form handling
• ✅ Null-Safety
• 🅿️ Logging
• 🅿️ Serve static files
• 🅿️ Template rendering?
• 🅿️ Extensions
• 🅿️ Health checks
• ❓ What’s more?

The end

I’d love to see more server-side Dart projects and hope you do too. If you think so it would be very encouraging if you star the project on GitHub and like it on Dev.to.

Nearly two years ago, Norka was born, a note-taking application made specifically for elementary OS and also distributed via Flathub. This version was far from version 1.0, its functionality was limited only to essential things: editing, searching, autosaving. Later, it introduced document search, export to various formats, spell checking, convenient keyboard shortcuts for editing, the ability to preview documents in HTML and statistics, etc. This was enough to start, but there was room for improvement. One possibility might be the ability to group notes in a folder and structure the user’s resources in a certain way. So what’s new comes in version 1.0?

Folders

The main and most important innovation is the ability to structure documents using folders. Folders can be created by clicking on a button in the header bar or by dragging documents onto each other. In this case, you will see a window displaying a suggestion for a folder name.

Folders can be moved from one to another. The level is not limited, but there is a limit on a path length, which, by the way, are found under the title of the window in the title. Also, some characters cannot be used in the names, we plan to fix this in the next releases.

The backup function also includes the structure of the library and exports documents by putting them in the right folders. This way you will get a complete copy of the library on disk.

New fonts and updated theme

We continue to work on using Norka not only in terms of functionality but also in terms of UI. Starting with version 1.0 Norka will use the iA Writer Duospace font. Thank you for sharing them with the community. The color scheme of the editor has also been updated.

Actions

In many desktop environments, it is possible to set up global hotkeys to trigger specific actions in applications. For example, take a screenshot or share a file. Now you can use the command to quickly take notes with Norka. This action can also be implemented as a command to call from hot corners in GNOME or elementary OS.

Specifying the language for spell checking

In one of the latest releases, we switched from GtkSpell to use GSpell, but at the same time, Norka lost the ability to specify which language to use for this check. And while this isn’t a problem if you’re writing in English, it creates problems for writers in other languages. This setting can now be changed in the application.

Import and formatting fixes

As with spell checking, one might not have noticed that for non-Latin languages, hotkeys are used to format text, leading to unexpected results. For example, when inserting a title, some of the text could be erased. Now we have fixed this problem, Norka correctly inserts formatting without text loss.

We also fixed auto-completion of lists: when pressing Enter, Norka will check if an item text has been entered, and if not, then inserting the list formatting ends.

For those who use drag-n-drop to import, the problem turned into the fact that when importing several files in sequence, the documents / those that were used the first time that time were re-imported instead of the last ones. We have fixed this issue, there is no more reason to worry about erroneous imports and prevent the deletion of redundant copies.

Conclusion

We keep improving Norka even further. We aimed to become the best writing app and note editor for Linux in the future, and possibly not only a Linux.

Thanks to everyone who uses Norka!

Intro

Almost two years ago I lost my iMac and it brought me an idea to see what’s changed in the Linux world for 10 years. Starting from Ubuntu and Fedora I finally came to the elementary OS project’s website. And it was quite astonishing. In comparison to the other distributions elementary had its view on how the operating system should view, how to make apps, its own design language and developers documentation. Thereby the decision to move to this OS was easy.

For now, it is almost two years since I moved from macOS to elementary OS as my daily driver. And, as I said earlier, I’m a developer. After looking for a native text editor I made myself think to make Norka. But, this article is about the distinct application. Actually, I’m not the author of it, the app is already a part of elementary itself - Contractor.

Contractor

The idea is very simple: users can write a contract - a file which instructs the Contractor how to call the command - and it comes available in any supported apps: Files, Photos, etc.

Action

I suppose you’re already got the idea of how the Contractor can help you in your daily work, but let’s make a contract that… well.. help you share any file via Telegram. What do we need for it?

• install Telegram
• get the command
• create a contract
• test it!

Because it differences in one case of installation on another I will write for the Flathub version.

Let’s dive in!

Install Telegram

As of elementary OS user, I can simply go to flathub.org and press the “Install” button. Sideload app do the job. But what about other distros? Well, the right way is completely covered on the Flathub site so we don’t wanna go through all steps :)

Get the right command

To write a good contract we need to find out what command does the job we need. In some cases, it could be easily extracted from --help info or man pages. Luckily Telegram command-line switches are fully described in the GitHub Wiki: https://github.com/telegramdesktop/tdesktop/wiki/Command-Line-Switches. -sendpath <file> - the desired switch.

One part is done, let’s figure out the second one. To run the application with a command-line switch installed via Flatpak we have to call flatpak run command. Thus our command will look like this:

flatpak run org.telegram.desktop -sendpath %f

This is already enough to make a contract!

Contract

Every contract should be placed inside ~/.local/share/contractor if we talking about a specific user or inside /usr/share/contractor for the system-wide availability.

Simple .contract file example:

[Contractor Entry]
Name=Mount
MimeType=application/x-cd-image;application/x-raw-disk-image
Exec=gnome-disk-image-mounter %f

This example shows how to make a command that will mount disk images to the filesystem. We need something different.

Create telegram-share.contract file and open it in Code or your text editor of choice. Change Name to Share via Telegram and Exec field to a command we discovered earlier. If English is not your primary language you can add localized Name by adding Name[language code] option. For example:

Name[ru]=Поделиться в Telegram

Last but not least we have to set what mime-types has to activate the Share command. Of course, it doesn’t mean to be only disk images and here is the special type - !inode - which means any file you select no matter archive it or pdf.

Let’s see what we’ve got!

[Contractor Entry]
Name=Share via Telegram
Name[ru]=Поделиться в Telegram
Icon=telegram
MimeType=!inode;
Exec=flatpak run org.telegram.desktop -sendpath %f

Now save your contract and test it by clicking on any file in Files and pressing the “Share via Telegram” option.

More examples listed in the Contractor repository.

Bonus

Notification

Sometimes you wanna indicate to yourself when the contract will be completed. To make it happen it’s not enough to call just one command, you need to send a notification somehow. Again, elementary already has an application for it named notify-send, and all we need is to combine all the commands into one with help of sh. As you may see in the Tips section it is easy enough:

Exec=sh -c "flatpak run org.telegram.desktop -sendpath %f && notify-send 'File sent' '%f successfully sent via Telegram'"

Final version:

[Contractor Entry]
Name=Share via Telegram
Name[ru]=Поделиться в Telegram
Icon=telegram
MimeType=!inode;
Exec=sh -c "flatpak run org.telegram.desktop -sendpath %f && notify-send 'File sent' '%f successfully sent via Telegram'"

Install .deb packages

[Contractor Entry]
Name=Install app
Name[ru]=Установить приложение
MimeType=application/vnd.debian.binary-package
Description=Quickly install .deb package
Exec=sh -c "pkexec apt install %u && notify-send 'the App installed' -a Apt"

Tips:

• Use pkexec to ask for root permissions. Example:

  Exec=pkexec chmod +x %U
  

• To call multiple commands at once try to use sh:

  Exec=sh -c "echo 'step 1' && notify-send 'Done' && echo 'step 2'"
  

In this current case we will be using these technologies:

• Python
• GTK+
• Libsoup
• Websocket messaging

If you’re wondering how to build a native GTK+ chat app, let’s dive with me!

Theory

WebSockets is a protocol designed to provide a consistent connection between the client and a server where both can send data to each other. It’s like a wire over the Internet or a tube, distinct of regular HTTP, where the client only can send data to the server and it gets a response immediately.

Benefits of this approach are quite obvious: the server can push the data to the client when it comes to server from another client or generated somewhere on the backend. And the client doesn’t need to refresh the page or do something to fetch new data, it just comes to the client by itself.

More information about WebSockets you can find on the websocket.org.

What I want to show you in this article it is how to connect to a WebSocket server and send or receive data from it in a native GTK+ application.

I will code my app in elementary OS using GNOME Builder, but the same logic should work anywhere where GTK+ and libsoup are available and all code could be easily adapted even for macOS.

UI

The app logic is quite simple yet representative. The UI will consist of two screens (Gtk.Grid) placed in Gtk.Stack. The first screen contains widgets required to connect to the server such as Gtk.Entry for server address, button to initiate a connection and a spinner to show the state.

The second screen is more complex. Purpose of this is to enter the message, send it to the server and show the server’s response in Gtk.TextView. Thus we need Gtk.Grid to place widgets. Gtk.Entry and Gtk.Button the same way we did it on the first page. And to display log we need Gtk.TextView placed within Gtk.ScrolledWindow in case there will be much more logs than the window can contain and the scrolling will be as much useful feature as it could :)

Connection page

Let’s start building! Create a new project in Builder, as the language, we will use Python 3.6+.

IDE will generate a base app structure with all we need, and all we need is just two files: window.ui and window.py.

Firstly, we need a correct UI for our app, so open window.ui. file and replace the “hello world” Label with Gtk.Stack. We will need two pages.

Name the first screen “connection”, and place onto it Gtk.Grid with 3 rows and columns. In the central cell place Gtk.Box with 4 rows:

1. Gtk.Label with text “Connection”
2. Gtk.Entry. Set its id to “host_entry”
3. Gtk.Button with id “connect_btn”
4. Gtk.Spinner. Call it whatever you like, mine is just a “spinner” :)

That’s enough for the “Connection” page.

Chat page

Moving further. The second screen is a bit more complex. Again, we need Gtk.Grid to put all the widgets we need. But for now, it will be a grid with just 2 rows and 2 columns.

First row with two widgets in its own cells:

• Gtk.Entry with id “message_entry”
• Gtk.Button with id “send_btn”

On the second row place Gtk.ScrolledWindow, no id required because we don’t need to call its method. Inside this ScrolledWindow put a new Gtk.TextView widget. Set its id to “log_view”.

To make it looks more convenient, set width = 2 in the container’s props inside attribute editor for ScrolledWindow.

Logic

Ok, out UI is ready enough to build some logic for it, finally :)

Open window.py and add class vars to connect with widgets from the .ui file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# Stack with pages
screens = Gtk.Template.Child()

# Connection page widgets
host_entry = Gtk.Template.Child()
connect_btn = Gtk.Template.Child()
disconnect_btn = Gtk.Template.Child()
spinner = Gtk.Template.Child()

# Chat page widgets
send_btn = Gtk.Template.Child()
message_entry = Gtk.Template.Child()
log_view = Gtk.Template.Child()

# Declare some class-vars
self.session = None
self.connection = None

Well, now we are able to call methods of these widgets. But also, we have to handle its signals. Let’s connect “connect_btn”:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

def __init__(self, **kwargs):
    # Some app logic

    self.connect_btn.connect('clicked', self.on_connect_clicked)

def on_connect_clicked(self, widget):
    # Check if there is a text inside the host_entry
    # and grab focus if its empty
    if not self.host_entry.get_text():
        self.host_entry.grab_focus()
        return

    # Show user we are trying to connect
    self.spinner.start()

    # Init libsoup Session, create message and start connection
    self.session = Soup.Session()
    msg = Soup.Message.new("GET", self.host_entry.get_text())
    self.session.websocket_connect_async(msg, None, None, None, self.on_connection)

The code above is quite straightforward:

• Get the server address
• Create new Session
• Init the connection with websocket_connect_async

As a callback for connection function, we put on_connection method, which takes the result of this operation and finish the process.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

def on_connection(self, session, result):
    try:
        # Finish connection process
        self.connection = session.websocket_connect_finish(result)
        
        # If we here, the connection went correctly
        # Connect `message` handler to the connection
        self.connection.connect('message', self.on_message)
        
        # Show to user all is OK and switch to the Chat page
        self.screens.set_visible_child_name('chat')
        self.disconnect_btn.set_visible(True)
    
    except Exception as e:
        # In case something goes wrong just print an exception
        print(e)
        self.session = None
    
    finally:
        # Don't forget to show a user that process is finished.
        self.spinner.stop()

We are almost done! All we need to do more is to handle click event from the “send_btn” and display messages in the “log_view”.

1
2
3
4
5

def on_message(self, connection, msg_type, message):
    msg = f'<b>RECEIVED:</b> {message.get_data().decode()}\n'
    self.buffer.insert_markup(self.buffer.get_start_iter(),
                              msg,
                              len(msg))

Could it be more simple than that? :wink: Just to display a message in a more readable way we add some Pango markup and use insert_markup method of Gtk.TextBuffer to… insert markup!

Last, but not least required thing is a handler for “send_btn” signal.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

def on_send_clicked(self, widget):
    # Get the message from the Entry
    msg = self.message_entry.get_text()

    # If there is no message - grab focus.
    if not msg:
        self.message_entry.grab_focus()
        return

    # Send a text to the server.
    self.connection.send_text(msg)

For our simple case, all we need is just the send_text method. But libsoup could do a lot of different stuff, such as send_binary or emit a signal if something goes wrong.

Conclusion

Simple yet descriptive example of how to start building your GTK+ app with WebSockets inside. Maybe you will create a new chat app?

Stay tuned if you want to read more! Or go to the docs from the Links section.

Anyway, good luck!

Links

Source code: https://github.com/amka/pygobject-gtk-websocket-app

Docs:

• https://websocket.org/
• https://lazka.github.io/pgi-docs/#Gtk-3.0
• https://lazka.github.io/pgi-docs/#Soup-2.4

Features

• Dynamic routing with placeholders and wildcards
• Concurrency via Isolates
• Extensible Middleware support
• Template rendering
• Logging

How to use it

import 'dart:io';

import 'package:laska/laska.dart';

void main() async {
  // Create new Laska object with 2 [Isolate]
  final laska = Laska(isolateCount: 2);

  // Set global BasicAuth middleware 
  laska.Use(BasicAuth('laska', 'ermine', realm: 'Access to private zone'));

  laska.GET('/users/:userId', getUserById);
  laska.POST('/users/', createUser);

  // Start server
  await run(laska);
}

void getUserById(Context context) async {
  await context.HTML('User: <b>${context.params['userId']}</b>');
}

void createUser(Context context) async {
  await context.JSON({'status': 'created'}, statusCode: HttpStatus.created);
}

Extract Text From Any source

Quickly extract non-selectable text from anywhere: videos, PDFs, screencasts, webpages, photos, etc. It’s so simple and easy as taking a screenshot with a built-in snipping tool for Mac..

See it in action

Get Frog

If you feel enough power to contribute or fork feel free to do it. Source code Available on GitHub