Gajim 1.5.0 and 1.5.1 come with a significant performance boost. Pinned chats can be ordered via drag and drop, message corrections have been improved, and many bugs have been fixed.

What’s New

For many years, Gajim’s internal handling of how a chat is loaded and displayed hasn’t changed. Each chat would create a new Control , which would hold the chat banner (name, chat state, etc.), the conversation view (messages), and a message input, including actions and menus. This approach does not scale well, since Gajim’s resource usage would increase with every new chat. With Gajim 1.4, we introduced a new conversation view, which increases the overall number of elements being displayed at the same time. Multiply this by the number of open chats, and you’ll get a lot more elements, which have to be rendered all at once. Due to some GTK theming issues (looking at you, backdrop animation), every focus/defocus of Gajim would lead to a spike in CPU usage.

To overcome these limitations, we changed Gajim’s fundamentals. The whole chat window with all its elements is now created only once, and then shared between all chats. Gajim just switches each element’s state when switching chats. Due to a drastically reduced amount of elements being loaded, this change alone reduces Gajim’s RAM usage by 20 %. With less elements being rendered at once, the delay ‘from click to action’ is also significantly reduced. In other words: Using Gajim feels more snappy.

More Changes

New

• Drag and drop for ordering pinned chats
• Use Ctrl+Number to switch between workspaces
• The chat list can now be toggled using a button or Ctrl+R

Changes

• Chat command system has been reworked
• Message corrections are now available from the message menu
• Windows: Overall text size has been increased
• Ctrl+F replaces Ctrl+H for opening the search bar
• Advanced Configuration Editor (ACE): non-default settings are highlighted
• Syntax highlighting for the XML console’s input
• IPython support has been removed

Fixes

Over 40 issues have been fixed in this release.

Due to a bug found shortly after releasing Gajim 1.5.0, it was necessary to release Gajim 1.5.1.

Have a look at the changelog for the complete list.

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab .

Gajim 1.5.0 and 1.5.1 come with a significant performance boost. Pinned chats can be ordered via drag and drop, message corrections have been improved, and many bugs have been fixed.

What’s New

For many years, Gajim’s internal handling of how a chat is loaded and displayed hasn’t changed. Each chat would create a new Control , which would hold the chat banner (name, chat state, etc.), the conversation view (messages), and a message input, including actions and menus. This approach does not scale well, since Gajim’s resource usage would increase with every new chat. With Gajim 1.4, we introduced a new conversation view, which increases the overall number of elements being displayed at the same time. Multiply this by the number of open chats, and you’ll get a lot more elements, which have to be rendered all at once. Due to some GTK theming issues (looking at you, backdrop animation), every focus/defocus of Gajim would lead to a spike in CPU usage.

To overcome these limitations, we changed Gajim’s fundamentals. The whole chat window with all its elements is now created only once, and then shared between all chats. Gajim just switches each element’s state when switching chats. Due to a drastically reduced amount of elements being loaded, this change alone reduces Gajim’s RAM usage by 20 %. With less elements being rendered at once, the delay ‘from click to action’ is also significantly reduced. In other words: Using Gajim feels more snappy.

More Changes

New

• Drag and drop for ordering pinned chats
• Use Ctrl+Number to switch between workspaces
• The chat list can now be toggled using a button or Ctrl+R

Changes

• Chat command system has been reworked
• Message corrections are now available from the message menu
• Windows: Overall text size has been increased
• Ctrl+F replaces Ctrl+H for opening the search bar
• Advanced Configuration Editor (ACE): non-default settings are highlighted
• Syntax highlighting for the XML console’s input
• IPython support has been removed

Fixes

Over 40 issues have been fixed in this release.

Due to a bug found shortly after releasing Gajim 1.5.0, it was necessary to release Gajim 1.5.1.

Have a look at the changelog for the complete list.

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab .

Gajim 1.5.0 and 1.5.1 come with a significant performance boost. Pinned chats can be ordered via drag and drop, message corrections have been improved, and many bugs have been fixed.

What’s New

For many years, Gajim’s internal handling of how a chat is loaded and displayed hasn’t changed. Each chat would create a new Control , which would hold the chat banner (name, chat state, etc.), the conversation view (messages), and a message input, including actions and menus. This approach does not scale well, since Gajim’s resource usage would increase with every new chat. With Gajim 1.4, we introduced a new conversation view, which increases the overall number of elements being displayed at the same time. Multiply this by the number of open chats, and you’ll get a lot more elements, which have to be rendered all at once. Due to some GTK theming issues (looking at you, backdrop animation), every focus/defocus of Gajim would lead to a spike in CPU usage.

To overcome these limitations, we changed Gajim’s fundamentals. The whole chat window with all its elements is now created only once, and then shared between all chats. Gajim just switches each element’s state when switching chats. Due to a drastically reduced amount of elements being loaded, this change alone reduces Gajim’s RAM usage by 20 %. With less elements being rendered at once, the delay ‘from click to action’ is also significantly reduced. In other words: Using Gajim feels more snappy.

More Changes

New

• Drag and drop for ordering pinned chats
• Use Ctrl+Number to switch between workspaces
• The chat list can now be toggled using a button or Ctrl+R

Changes

• Chat command system has been reworked
• Message corrections are now available from the message menu
• Windows: Overall text size has been increased
• Ctrl+F replaces Ctrl+H for opening the search bar
• Advanced Configuration Editor (ACE): non-default settings are highlighted
• Syntax highlighting for the XML console’s input
• IPython support has been removed

Fixes

Over 40 issues have been fixed in this release.

Due to a bug found shortly after releasing Gajim 1.5.0, it was necessary to release Gajim 1.5.1.

Have a look at the changelog for the complete list.

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab .

The Ignite Realtime Community is pleased to announce the 1.0.0 release of the Push Server plugin for Openfire. This plugin is developed by the company Busoft Teknoloji A.Ş. It is inspired by Conversations Push Proxy and developed for Openfire.

Your instance of Openfire should automatically display the availability of the new plugin in the next few hours. Alternatively, you can download the the plugin directly from the Push Server plugin archive page .

Stop by our support groupchat to get in touch, or leave a message on our community site .

For other release announcements and news follow us on Twitter

What is this plugin for

Due to the restrictions in push services (FCM or APNS), only the developer can create push notifications for their apps. For this reason a user’s server wouldn’t be able to wake up a user’s device directly but has to proxy that wake up signal through the infrastructure of the app developer.

Push Server Plugin is an XEP-0357: Push Notifications app server that relays push messages between the user’s server and FCM (Firebase Cloud Messaging) or APNS (Apple Push Notification Service).

Here is a quick description of how this relationship is set up.

XMPP Client sends to the app server

- Device Token
- Device Id

App Server generates

- Node Id
- Secret

App Server stores

- Device Token
- Device Id
- Node
- Secret

App Server returns to XMPP Client

- Node Id

XMPP Client sends to the user's server

- Node ID
- The jid of the app server (push.example.com)

The user’s server sends to the app server

(Achived by Openfire Push Notification plugin)

When a push is required the user’s server will send the node id to the app server. The user’s server can also add additonal information like number of messages pending, the sender jid of the last message and even the body of the last message.

An example of that communication can be found in XEP-0357 Section 7 .

9 posts - 3 participants

Read full topic

The Ignite Realtime Community is pleased to announce the 1.0.0 release of the Push Server plugin for Openfire. This plugin is developed by the company Busoft Teknoloji A.Ş. It is inspired by Conversations Push Proxy and developed for Openfire.

Your instance of Openfire should automatically display the availability of the new plugin in the next few hours. Alternatively, you can download the the plugin directly from the Push Server plugin archive page .

Stop by our support groupchat to get in touch, or leave a message on our community site .

For other release announcements and news follow us on Twitter

What is this plugin for

Due to the restrictions in push services (FCM or APNS), only the developer can create push notifications for their apps. For this reason a user’s server wouldn’t be able to wake up a user’s device directly but has to proxy that wake up signal through the infrastructure of the app developer.

Push Server Plugin is an XEP-0357: Push Notifications app server that relays push messages between the user’s server and FCM (Firebase Cloud Messaging) or APNS (Apple Push Notification Service).

Here is a quick description of how this relationship is set up.

XMPP Client sends to the app server

- Device Token
- Device Id

App Server generates

- Node Id
- Secret

App Server stores

- Device Token
- Device Id
- Node
- Secret

App Server returns to XMPP Client

- Node Id

XMPP Client sends to the user's server

- Node ID
- The jid of the app server (push.example.com)

The user’s server sends to the app server

(Achived by Openfire Push Notification plugin)

When a push is required the user’s server will send the node id to the app server. The user’s server can also add additonal information like number of messages pending, the sender jid of the last message and even the body of the last message.

An example of that communication can be found in XEP-0357 Section 7 .

9 posts - 3 participants

Read full topic

The Ignite Realtime Community is pleased to announce the 1.0.0 release of the Push Server plugin for Openfire. This plugin is developed by the company Busoft Teknoloji A.Ş. It is inspired by Conversations Push Proxy and developed for Openfire.

Your instance of Openfire should automatically display the availability of the new plugin in the next few hours. Alternatively, you can download the the plugin directly from the Push Server plugin archive page .

Stop by our support groupchat to get in touch, or leave a message on our community site .

For other release announcements and news follow us on Twitter

What is this plugin for

Due to the restrictions in push services (FCM or APNS), only the developer can create push notifications for their apps. For this reason a user’s server wouldn’t be able to wake up a user’s device directly but has to proxy that wake up signal through the infrastructure of the app developer.

Push Server Plugin is an XEP-0357: Push Notifications app server that relays push messages between the user’s server and FCM (Firebase Cloud Messaging) or APNS (Apple Push Notification Service).

Here is a quick description of how this relationship is set up.

XMPP Client sends to the app server

- Device Token
- Device Id

App Server generates

- Node Id
- Secret

App Server stores

- Device Token
- Device Id
- Node
- Secret

App Server returns to XMPP Client

- Node Id

XMPP Client sends to the user's server

- Node ID
- The jid of the app server (push.example.com)

The user’s server sends to the app server

(Achived by Openfire Push Notification plugin)

When a push is required the user’s server will send the node id to the app server. The user’s server can also add additonal information like number of messages pending, the sender jid of the last message and even the body of the last message.

An example of that communication can be found in XEP-0357 Section 7 .

9 posts - 3 participants

Read full topic

I finally took time to setup a forge and some old drafts turned up. I am publishing one of them today as is even though it’s 4 years old (2018-08-07T13:27:43+01:00). I’m not as grumpy as I was at the time but I still think this applies.

Today I am grumpy at people’s expectation of a free software project, about versioning and releases. I am mostly concerned about applications rather than libraries in this article but I am sure some of this would apply to libraries as well.

Today we were discussing about versioning and releases in the poezio chatroom.

Poezio is a console application, a small project maintained by a handful of contributors to which I am grateful. I also have a few contributions myself. The application is far from perfect but what software is anyway.

The last release – as of writing – for the project is 0.11 , published on Jan 31, 2017. A bit over 1.5 years ago. Yes, the project is still being actively maintained, but no release is being made for the moment.

No , not every project releases with the same regularity. No , not every project has the same understanding of what a release is. Most projects don’t have the same constraints.

For some projects releases are sacred and I am happy for them. Maintained for X months or even years to which will only be applied security fixes or critical bug fixes (crashes and the like).

For others, releases are only checkpoints. A way of saying that features are being added, bugs are being fixed, and have people talk about it.

There is no global definition of what a release is supposed to be. It is up to project maintainers to decide what they want to see in it. They could very well make a release every other commit and be happy with it if they wanted to be silly. They would still be semver compliant – one of the various versioning scheme defined out there.

Nothing also mandates they have to backport bug fixes to the current or previous releases, and some projects actually cannot afford such a luxury. All of this takes time and that is a really expensive resource in a project.

Update from the present:

I think the issue I tried to convey in this article isn’t that we don’t have time, or that there’s no definition of a release, it’s that I’m tired of being imposed a vision of the world I don’t agree with. What’s more, people having these expectations often don’t even take part in the process of making the project or the in community around it, at any level.

I finally took time to setup a forge and some old drafts turned up. I am publishing one of them today as is even though it’s 4 years old (2018-08-07T13:27:43+01:00). I’m not as grumpy as I was at the time but I still think this applies.

Today I am grumpy at people’s expectation of a free software project, about versioning and releases. I am mostly concerned about applications rather than libraries in this article but I am sure some of this would apply to libraries as well.

Today we were discussing about versioning and releases in the poezio chatroom.

Poezio is a console application, a small project maintained by a handful of contributors to which I am grateful. I also have a few contributions myself. The application is far from perfect but what software is anyway.

The last release – as of writing – for the project is 0.11 , published on Jan 31, 2017. A bit over 1.5 years ago. Yes, the project is still being actively maintained, but no release is being made for the moment.

No , not every project releases with the same regularity. No , not every project has the same understanding of what a release is. Most projects don’t have the same constraints.

For some projects releases are sacred and I am happy for them. Maintained for X months or even years to which will only be applied security fixes or critical bug fixes (crashes and the like).

For others, releases are only checkpoints. A way of saying that features are being added, bugs are being fixed, and have people talk about it.

There is no global definition of what a release is supposed to be. It is up to project maintainers to decide what they want to see in it. They could very well make a release every other commit and be happy with it if they wanted to be silly. They would still be semver compliant – one of the various versioning scheme defined out there.

Nothing also mandates they have to backport bug fixes to the current or previous releases, and some projects actually cannot afford such a luxury. All of this takes time and that is a really expensive resource in a project.

Update from the present:

I think the issue I tried to convey in this article isn’t that we don’t have time, or that there’s no definition of a release, it’s that I’m tired of being imposed a vision of the world I don’t agree with. What’s more, people having these expectations often don’t even take part in the process of making the project or the in community around it, at any level.

I finally took time to setup a forge and some old drafts turned up. I am publishing one of them today as is even though it’s 4 years old (2018-08-07T13:27:43+01:00). I’m not as grumpy as I was at the time but I still think this applies.

Today I am grumpy at people’s expectation of a free software project, about versioning and releases. I am mostly concerned about applications rather than libraries in this article but I am sure some of this would apply to libraries as well.

Today we were discussing about versioning and releases in the poezio chatroom.

Poezio is a console application, a small project maintained by a handful of contributors to which I am grateful. I also have a few contributions myself. The application is far from perfect but what software is anyway.

The last release – as of writing – for the project is 0.11 , published on Jan 31, 2017. A bit over 1.5 years ago. Yes, the project is still being actively maintained, but no release is being made for the moment.

No , not every project releases with the same regularity. No , not every project has the same understanding of what a release is. Most projects don’t have the same constraints.

For some projects releases are sacred and I am happy for them. Maintained for X months or even years to which will only be applied security fixes or critical bug fixes (crashes and the like).

For others, releases are only checkpoints. A way of saying that features are being added, bugs are being fixed, and have people talk about it.

There is no global definition of what a release is supposed to be. It is up to project maintainers to decide what they want to see in it. They could very well make a release every other commit and be happy with it if they wanted to be silly. They would still be semver compliant – one of the various versioning scheme defined out there.

Nothing also mandates they have to backport bug fixes to the current or previous releases, and some projects actually cannot afford such a luxury. All of this takes time and that is a really expensive resource in a project.

Update from the present:

I think the issue I tried to convey in this article isn’t that we don’t have time, or that there’s no definition of a release, it’s that I’m tired of being imposed a vision of the world I don’t agree with. What’s more, people having these expectations often don’t even take part in the process of making the project or the in community around it, at any level.