[Feature Request] Ubuntu integration: Application Indicator, Messaging menu, Launcher shortcuts #135

New Issue

Closed

opened 2013-05-06 22:31:57 +02:00 by omyno · 26 comments

omyno commented 2013-05-06 22:31:57 +02:00 (Migrated from github.com)

Copy Link

• Application Indicator
  This provides access to key features of Bitmessage.
  • mono icon (compare /usr/share/icons/ubuntu-mono-dark/status/24)
• Messaging menu
  The entry could look like this:
  • Pybitmessage
    • New message
    • Contacts
    • 1 new message (from John Doe)
• Launcher shortcut
  This is very easy to implement when the application supports command line options.
• Notify OSD
  This informs the user about new messages and connection loss.
• Most importantly, Ubuntu users have no easy way to install Pybitmessage. Even though it may be too early to get Pybitmessage into the Debian repositories, there are several options to make it more convenient to install this application:
  • Provide a single official .deb file
  • Provide a portable statically linked executable
  • Provide a PPA

- [x] [Application Indicator](http://unity.ubuntu.com/projects/appindicators/) This provides access to key features of Bitmessage. - [x] mono icon (compare _/usr/share/icons/ubuntu-mono-dark/status/24_) - [x] [Messaging menu](http://developer.ubuntu.com/resources/technologies/messaging-menu/) The entry could look like this: - Pybitmessage - New message - Contacts - _**1 new message** (from John Doe)_ - [x] [Launcher shortcut](https://help.ubuntu.com/community/UnityLaunchersAndDesktopFiles#Adding_shortcuts_to_a_launcher) This is very easy to implement when the application supports command line options. - [x] [Notify OSD](http://developer.ubuntu.com/resources/technologies/notification/) This informs the user about new messages and connection loss. - [x] Most importantly, Ubuntu users have no easy way to install Pybitmessage. Even though it may be too early to get Pybitmessage into the Debian repositories, there are several options to make it more convenient to install this application: - Provide a single official .deb file - Provide a portable statically linked executable - Provide a PPA

ghost commented 2013-05-06 22:42:44 +02:00 (Migrated from github.com)

Copy Link

Creating a Debian package is simple. There's a script called debian.sh which can be run. If someone nominates a location to upload to I can create a deb if necessary.

On PPAs I think this requires a project in Launchpad, but that wouldn't be a problem because you can set Launchpad projects to automatically import code from Github.

The "executable" exists in the current Debian packaging. It's called "pybm" and gets installed to /usr/bin. Appropriate menu items/icons also get installed.

I think the Ubuntu integration is a good idea, and I might also have a go at making a KDE Bitmessage widget.

Creating a Debian package is simple. There's a script called debian.sh which can be run. If someone nominates a location to upload to I can create a deb if necessary. On PPAs I think this requires a project in Launchpad, but that wouldn't be a problem because you can set Launchpad projects to automatically import code from Github. The "executable" exists in the current Debian packaging. It's called "pybm" and gets installed to /usr/bin. Appropriate menu items/icons also get installed. I think the Ubuntu integration is a good idea, and I might also have a go at making a KDE Bitmessage widget.

omyno commented 2013-05-06 23:05:56 +02:00 (Migrated from github.com)

Copy Link

Thanks for your comment. All these issues combined may even justify creating a new client/interface for Bitmessage as I don't know if Atheros has any interest in adding these features.

IMHO naming the executable "pybitmessage" instead of "pybm" would be more intuitive.

On PPAs I think this requires a project in Launchpad,

No. A PPA does not necessarily need a project, just a registered launchpad user who signed the Ubuntu code of conduct.

The current .deb packaging instructions in debian/rules are not good yet as they copy all .py, .ui and image files into /usr/share/applications. This directory is reserved for .desktop files.

Thanks for your comment. All these issues combined may even justify creating a new client/interface for Bitmessage as I don't know if Atheros has any interest in adding these features. IMHO naming the executable "pybitmessage" instead of "pybm" would be more intuitive. > On PPAs I think this requires a project in Launchpad, No. A PPA does [not necessarily](https://help.launchpad.net/Packaging) need a project, just a registered launchpad user who signed the Ubuntu code of conduct. The current .deb packaging instructions in debian/rules are not good yet as they copy all .py, .ui and image files into /usr/share/applications. This directory is reserved for .desktop files.

ghost commented 2013-05-06 23:26:36 +02:00 (Migrated from github.com)

Copy Link

I could rename it to pybitmessage. My thinking was that if you're going to be launching it from the console then to keep the typing to a minimum.

I am a registered Launchpad user who has accepted the CoC, so I could probably set up a PPA if nobody else does.

Could you advise on where the standard location for installed applications is in Ubuntu (I assumed it was applications).

I could rename it to pybitmessage. My thinking was that if you're going to be launching it from the console then to keep the typing to a minimum. I am a registered Launchpad user who has accepted the CoC, so I could probably set up a PPA if nobody else does. Could you advise on where the standard location for installed applications is in Ubuntu (I assumed it was applications).

ghost commented 2013-05-06 23:27:44 +02:00 (Migrated from github.com)

Copy Link

To be Debian compliant I should also create a manpage, although that could be quite minimal and maybe just point to the wiki.

To be Debian compliant I should also create a manpage, although that could be quite minimal and maybe just point to the wiki.

omyno commented 2013-05-07 00:31:29 +02:00 (Migrated from github.com)

Copy Link

Thanks for your effort! I would suggest /usr/share/pybitmessage for those files.

I noticed that /usr/bin/pybm currently is just a two-liner bash script. I don't know the best practice for python applications, but /usr/bin/pyrenamer could serve as a better template for /usr/bin/pybitmessage.

Thanks for your effort! I would suggest _/usr/share/pybitmessage_ for those files. I noticed that /usr/bin/pybm currently is just a two-liner bash script. I don't know the best practice for python applications, but [_/usr/bin/pyrenamer_](http://svn.infinicode.org/pyrenamer/trunk/pyrenamer/src/pyrenamer) could serve as a better template for _/usr/bin/pybitmessage_.

ghost commented 2013-05-07 11:04:37 +02:00 (Migrated from github.com)

Copy Link

59211053dc

https://github.com/fuzzgun/PyBitmessage/commit/59211053dc8a3f2241e168be19520efac83ed159

ghost commented 2013-05-07 12:25:03 +02:00 (Migrated from github.com)

Copy Link

If there is to be an application indicator then what should be on it?

Maybe send message, add address, block address, subscribe to broadcast.

Possibly the indicator icon could change colour depending upon the network status.

If there is to be an application indicator then what should be on it? Maybe send message, add address, block address, subscribe to broadcast. Possibly the indicator icon could change colour depending upon the network status.

omyno commented 2013-05-07 14:04:42 +02:00 (Migrated from github.com)

Copy Link

I don't know if we want redundancy for the app indicator vs. messaging menu (see entries below that are prefixed with #). So the main purpose of the app indicator will be to be able to show/hide Pybitmessage so it does not sit in the launcher the whole time (see screenshots below).

1. Unclickable entry that shows information about connectivity. Most users won't care about the number of connections, they just want to know if the program works or not, so i suggest showing "Connected", "Connected (behind Firewall), "Not connected".
   Here we can also show the status of the current message(s) being sent: Sending message ...
2. Show Bitmessage (This entry only makes sense when closing the Pybitmessage window hides it into tray/indicator which does not seem to be implemented for Linux yet)

3. Send message

4. Subscribe to broadcast

5. Address book (instead of "add address")

6. Quit

I hope "block address" won't be needed as often so i wouldn't include it here.

I don't know if we want redundancy for the app indicator vs. messaging menu (see entries below that are prefixed with #). So the main purpose of the app indicator will be to be able to show/hide Pybitmessage so it does not sit in the launcher the whole time (see screenshots below).   1. Unclickable entry that shows information about connectivity. Most users won't care about the number of connections, they just want to know if the program works or not, so i suggest showing "Connected", "Connected (behind Firewall), "Not connected". Here we can also show the status of the current message(s) being sent: _Sending message ..._ 2. _Show Bitmessage_ (This entry only makes sense when closing the Pybitmessage window hides it into tray/indicator which does not seem to be implemented for Linux yet) 3. # _Send message_ 4. # _Subscribe to broadcast_ 5. # _Address book_ (instead of "add address") 6. _Quit_ I hope "block address" won't be needed as often so i wouldn't include it here.

ghost commented 2013-05-07 14:22:00 +02:00 (Migrated from github.com)

Copy Link

That sounds ok. I think that the recent PyBitmessage-Daemon could be modified such that it uses the API to update the indicator. That would mean that the indicator stuff could be separate from the main program. If the API wasn't configured then either some defaults could be created automatically by the indicator, or upon install it would prompt the user to enter an API password.

That sounds ok. I think that the recent PyBitmessage-Daemon could be modified such that it uses the API to update the indicator. That would mean that the indicator stuff could be separate from the main program. If the API wasn't configured then either some defaults could be created automatically by the indicator, or upon install it would prompt the user to enter an API password.

omyno commented 2013-05-07 14:36:44 +02:00 (Migrated from github.com)

Copy Link

It looks like all that is needed is to create a QSystemTrayIcon. sni-qt will then automatically "render that tray icon as a KDE Status Notifier Item, which the Application Indicator service will pick up and show in the Ubuntu menu bar." (source)

It looks like all that is needed is to [create a QSystemTrayIcon](http://askubuntu.com/a/61084/2906). sni-qt will then automatically "render that tray icon as a KDE Status Notifier Item, which the Application Indicator service will pick up and show in the Ubuntu menu bar." ([source](http://askubuntu.com/a/159232/2906))

ghost commented 2013-05-07 14:45:38 +02:00 (Migrated from github.com)

Copy Link

Ok, since that's just Qt then no separate program or API calls would be needed.

Ok, since that's just Qt then no separate program or API calls would be needed.

ghost commented 2013-05-08 00:15:28 +02:00 (Migrated from github.com)

Copy Link

Application indicator is now operational in pull request #133

The way that the connection status is indicated could be changed. Currently it's just text. Another way to do it might be to have red, yellow and green versions of the bitmessage icon and switch between them. What would the Ubuntu "designers" do? Ideally the appearance and functionality should be as slick as possible so that using encrypted mail becomes a no-brainer.

Moving along to the messaging menu this looks fairly Unity specific. Is there a Qt way of accessing this?

Application indicator is now operational in pull request #133 The way that the connection status is indicated could be changed. Currently it's just text. Another way to do it might be to have red, yellow and green versions of the bitmessage icon and switch between them. What would the Ubuntu "designers" do? Ideally the appearance and functionality should be as slick as possible so that using encrypted mail becomes a no-brainer. Moving along to the messaging menu this looks fairly Unity specific. Is there a Qt way of accessing this?

omyno commented 2013-05-08 16:24:15 +02:00 (Migrated from github.com)

Copy Link

• The app indicator works for me. Great work! In the future, the first entry could also show when a message is being sent. Ideally, the entry "Connection ..." would also be non-clickable, but I don't know if sni-qt supports this (or if there's a bug ...).
  EDIT:

  What would the Ubuntu "designers" do?

  The Wiki states that dynamic objects should have icons, so the traffic light symbol would be fine.

• Regarding the messaging menu:

  • Python API documentation is here.

  • First we can just create the file $HOME/.config/indicators/messages/applications/pybitmessage which contains nothing but the path to the .desktop file in it:
    /usr/share/applications/pybitmessage.desktop

  • Ideally we want the user to be able to disable the messaging menu entry in the pybitmessage settings.

  • Qt way: I found a launchpad project that provides Qt bindings for the new messaging menu. It wraps the libmessaging-menu API into the Qt object system. I hope this will help you somehow. We can bundle the package in the PPA. Here's how to get it:

    sudo apt-get install libmessaging-menu-dev
    bzr branch lp:messaging-menu-qt && cd messaging-menu-qt
    cmake .
    make
    sudo make install
    

  __EDIT__: messaging-menu-qt is [being used](https://github.com/euroelessar/qutim/tree/master/plugins/indicator/src) in Qutim.

* One last note: The directory /usr/share/applications/pybitmessage isn't needed anymore. Here's a [patch for Makefile](http://sebsauvage.net/paste/?2f1e6072f163c8ae#dJZjgqCWLL1T930kXD9tIgZFdDnuS3evtuGGtsBsIew=).

- The app indicator works for me. Great work! In the future, the first entry could also show when a message is being sent. Ideally, the entry "Connection ..." would also be non-clickable, but I don't know if sni-qt supports this (or if there's a [bug](https://bugreports.qt-project.org/browse/QTBUG-19499) ...). **EDIT**: > What would the Ubuntu "designers" do? The [Wiki](https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines#Icons_in_menu_items) states that dynamic objects should have icons, so the traffic light symbol would be fine. - Regarding the messaging menu: - Python API documentation is [here](http://developer.ubuntu.com/api/ubuntu-12.10/python/MessagingMenu-1.0.html). - First we can just create the file _$HOME/.config/indicators/messages/applications/pybitmessage_ which contains nothing but the path to the .desktop file in it: `/usr/share/applications/pybitmessage.desktop` - Ideally we want the user to [be able to disable](https://wiki.ubuntu.com/MessagingMenu#API) the messaging menu entry in the pybitmessage settings. - Qt way: I found a launchpad project that provides [Qt bindings](https://launchpad.net/messaging-menu-qt) for the new messaging menu. It wraps the libmessaging-menu API into the Qt object system. I hope this will help you somehow. We can bundle the package in the PPA. Here's how to get it: ``` sudo apt-get install libmessaging-menu-dev bzr branch lp:messaging-menu-qt && cd messaging-menu-qt cmake . make sudo make install ``` ``` __EDIT__: messaging-menu-qt is [being used](https://github.com/euroelessar/qutim/tree/master/plugins/indicator/src) in Qutim. * One last note: The directory /usr/share/applications/pybitmessage isn't needed anymore. Here's a [patch for Makefile](http://sebsauvage.net/paste/?2f1e6072f163c8ae#dJZjgqCWLL1T930kXD9tIgZFdDnuS3evtuGGtsBsIew=). ```

ghost commented 2013-05-09 23:41:29 +02:00 (Migrated from github.com)

Copy Link

It looks like libmessaging-menu-dev is Ubuntu specific and so would cause problems for anyone trying to install the package on a Debian system.

It looks like libmessaging-menu-dev is Ubuntu specific and so would cause problems for anyone trying to install the package on a Debian system.

omyno commented 2013-05-10 00:29:41 +02:00 (Migrated from github.com)

Copy Link

True, it's just relevant to Ubuntu (and elementary OS ...) . This means the PPA will need a different dependency list and include messaging-menu-qt.

True, it's just relevant to Ubuntu (and elementary OS ...) . This means the PPA will need a different dependency list and include messaging-menu-qt.

ghost commented 2013-05-10 10:47:00 +02:00 (Migrated from github.com)

Copy Link

I wonder if there's a way that I could have the packaging detect the operating system and include the appropriate dependencies. It might be possible with some editing of debian.sh

I wonder if there's a way that I could have the packaging detect the operating system and include the appropriate dependencies. It might be possible with some editing of debian.sh

ghost commented 2013-05-10 16:42:14 +02:00 (Migrated from github.com)

Copy Link

After making enquiries in Ubuntuland it seems that the Python code examples are out of date and no longer work. The True workings of the messaging menu are currently known only to the Inner Circle and I'll have to wait for the wiki to be updated.

https://bugs.launchpad.net/ubuntudeveloperportal/+bug/1178700

After making enquiries in Ubuntuland it seems that the Python code examples are out of date and no longer work. The True workings of the messaging menu are currently known only to the Inner Circle and I'll have to wait for the wiki to be updated. https://bugs.launchpad.net/ubuntudeveloperportal/+bug/1178700

ghost commented 2013-05-11 18:56:48 +02:00 (Migrated from github.com)

Copy Link

So despite non-existent or very poor documentation I've managed to implement most of this. Unfortunately the links provided in this issue were referring to out of date information which the Ubuntumeisters havn't gotten around to updating (despite it being core API information for their flagship product), so I ended up chasing shadows for a while. This suggests to me that almost nobody outside of Canonical's internal development team is really doing anything at all with the messaging menu in Ubuntu.

There is an issue with the possibility of opening multiple instances of the application from the messaging menu, but I've created a separate issue for that. It needs something like a mutex or single instance application.

So despite non-existent or very poor documentation I've managed to implement most of this. Unfortunately the links provided in this issue were referring to out of date information which the Ubuntumeisters havn't gotten around to updating (despite it being core API information for their flagship product), so I ended up chasing shadows for a while. This suggests to me that almost nobody outside of Canonical's internal development team is really doing anything at all with the messaging menu in Ubuntu. There is an issue with the possibility of opening multiple instances of the application from the messaging menu, but I've created a separate issue for that. It needs something like a mutex or single instance application.

ghost commented 2013-05-11 19:54:18 +02:00 (Migrated from github.com)

Copy Link

On the launcher shortcut should the actions be the same as those on the application indicator?

On the launcher shortcut should the actions be the same as those on the application indicator?

omyno commented 2013-05-12 02:04:27 +02:00 (Migrated from github.com)

Copy Link

Thanks for pointing these problems out. I had no idea those code examples were outdated and had expected Canonical to put more effort into encouraging developers to easily integrate their apps in Ubuntu. Sorry that I didn't provide you with some more valuable information.

You are right, there are not so many applications which use the messaging menu. I know of Gajim, Thunderbird, Evolution, Pidgin, XChat, Skype, Smuxi and some other mail programs to have messaging menu integration. Not all of them transitioned to the new API since quantal though.

Just tested your messaging menu integration and it works like a charm (aside from opening multiple instances as you already mentioned)! I think you also did a great job on adding the unobtrusive color to the indicator icon. Hopefully you don't mind me nit-picking and I don't even know if that's possible without much more work: Clicking on an unread message in the messaging menu should directly select the unread message in PyBitmesage itself, so the body of the message will be shown. For me it only opened the tab.

As for the launcher shortcut: I had a look into what some other applications offer here. If you don't see any better options I'm fine with the same as those in the app indicator.

Thanks for pointing these problems out. I had no idea those code examples were outdated and had expected Canonical to put more effort into encouraging developers to easily integrate their apps in Ubuntu. Sorry that I didn't provide you with some more valuable information. You are right, there are not so many applications which use the messaging menu. I know of Gajim, Thunderbird, Evolution, Pidgin, XChat, Skype, Smuxi and some other mail programs to have messaging menu integration. Not all of them transitioned to the new API since quantal though. Just tested your messaging menu integration and it works like a charm (aside from opening multiple instances as you already mentioned)! I think you also did a great job on adding the unobtrusive color to the indicator icon. Hopefully you don't mind me nit-picking and I don't even know if that's possible without much more work: Clicking on an unread message in the messaging menu should directly select the unread message in PyBitmesage itself, so the body of the message will be shown. For me it only opened the tab. As for the launcher shortcut: I had a look into what some other applications offer here. If you don't see any better options I'm fine with the same as those in the app indicator.

ghost commented 2013-05-12 10:37:13 +02:00 (Migrated from github.com)

Copy Link

According to the design guide the messaging menu should only contain mailboxes and on selecting an item direct you to that mailbox (and remove it from the messaging menu). Individual messages aren't intended to be shown in the messaging menu. The messaging menu should also only show things which have changed rather than general status information.

I know that's somewhat non-intuitive, but that's what the guide says and was also confirmed by the Ubuntu desktop developers in IRC.

According to the design guide the messaging menu should only contain mailboxes and on selecting an item direct you to that mailbox (and remove it from the messaging menu). Individual messages aren't intended to be shown in the messaging menu. The messaging menu should also only show things which have changed rather than general status information. I know that's somewhat non-intuitive, but that's what the guide says and was also confirmed by the Ubuntu desktop developers in IRC.

ghost commented 2013-05-13 16:35:04 +02:00 (Migrated from github.com)

Copy Link

Unofficial PPA:

ppa:fuzzgun/pybitmessage

deb http://ppa.launchpad.net/fuzzgun/pybitmessage/ubuntu raring main
deb-src http://ppa.launchpad.net/fuzzgun/pybitmessage/ubuntu raring main

Unofficial PPA: ppa:fuzzgun/pybitmessage deb http://ppa.launchpad.net/fuzzgun/pybitmessage/ubuntu raring main deb-src http://ppa.launchpad.net/fuzzgun/pybitmessage/ubuntu raring main

omyno commented 2013-05-13 20:27:26 +02:00 (Migrated from github.com)

Copy Link

I tried the PPA and it works as expected. You are really driving Bitmessage's usability forward and open it to a much wider audience! I am really excited that you managed to solve all the issues in this bug report (and in just a few days!).

1. Individual messages aren't intended to be shown in the messaging menu.

   I guess i did not express myself well. What i meant to say was when the entry for an unread message in the messaging menu is clicked, pybitmessage opens and should there automatically select the unread mail so the user can see the content. That's also the way Thunderbird handles it.
   Currently PyBitmessage just opens the Inbox and I have to manually click on the new message in the client.

2. Another small detail: When Pybitmessage is open and a new message is clicked on, the unread entry in the messaging menu should disappear. That is also how it is done in Thunderbird and seems like intuitive behavior.

3. I created a first version of mono icons so the indicator icon fits the default theme Ambiance/"ubuntu-mono-dark". They would belong in /usr/share/icons/ubuntu-mono-dark/24 It's not perfect yet because they are just converted from an SVG file. I guess a good icon should be created directly as a bitmap graphics. So if anyone knows how to create a nice icon in Gimp ... (the color code is always dfd8c8ff)
   

EDIT: The SVG files are available here

I tried the PPA and it works as expected. You are really driving Bitmessage's usability forward and open it to a much wider audience! I am really excited that you managed to solve all the issues in this bug report (and in just a few days!). 1. > Individual messages aren't intended to be shown in the messaging menu. I guess i did not express myself well. What i meant to say was when the entry for an unread message in the messaging menu is clicked, pybitmessage opens and should _there_ automatically select the unread mail so the user can see the content. That's also the way Thunderbird handles it. Currently PyBitmessage just opens the Inbox and I have to manually click on the new message in the client. 2. Another small detail: When Pybitmessage is open and a new message is clicked on, the unread entry in the messaging menu should disappear. That is also how it is done in Thunderbird and seems like intuitive behavior. 3. I created a first version of mono icons so the indicator icon fits the default theme Ambiance/"ubuntu-mono-dark". They would belong in /usr/share/icons/ubuntu-mono-dark/24 It's not perfect yet because they are just converted from an SVG file. I guess a good icon should be created directly as a bitmap graphics. So if anyone knows how to create a nice icon in Gimp ... (the color code is always dfd8c8ff)     EDIT: The SVG files are available [here](http://ge.tt/api/1/files/4ivDgYg/0/blob?download)

ghost commented 2013-05-13 20:43:01 +02:00 (Migrated from github.com)

Copy Link

Ok that makes sense. Compared to the core protocols these are all "paper cuts", but I think that getting the Unity integration looking nice and behaving like other applications will certainly help adoption. The vanilla version of Ubuntu probably covers maybe 75% of the Linux user base.

Ok that makes sense. Compared to the core protocols these are all "paper cuts", but I think that getting the Unity integration looking nice and behaving like other applications will certainly help adoption. The vanilla version of Ubuntu probably covers maybe 75% of the Linux user base.

ghost commented 2013-05-13 20:56:10 +02:00 (Migrated from github.com)

Copy Link

There is also an inconsistency. On the application indicator it says "quit" but in the main application window file menu it says "exit". Both do the same thing. Is there any preferred term?

There is also an inconsistency. On the application indicator it says "quit" but in the main application window file menu it says "exit". Both do the same thing. Is there any preferred term?

omyno commented 2013-05-13 21:18:35 +02:00 (Migrated from github.com)

Copy Link

Yes, we should use "Quit". Most applications use it and for example the GNOME HIG recommends not to use "Exit". There's also no keyboard shortcut to quit Pybitmessage yet. This should be set to Ctrl+Q (Command+Q on OS X).

Yes, we should use "Quit". Most applications use it and for example the GNOME HIG [recommends](https://developer.gnome.org/hig-book/3.8/language-labels.html) not to use "Exit". There's also no keyboard shortcut to quit Pybitmessage yet. This should be set to Ctrl+Q (Command+Q on OS X).

This repo is archived. You cannot comment on issues.

No Branch/Tag Specified

Branches Tags

v0.6

gitea-122

gitea-118

kashikoibumi/py3qt

kashikoibumi/py3

gitea-112

gitea-111

kivy-fix

test3

anand-skss/test_case

test5

gitea-107

gitea-106

test

gitea-102

gitea-100

gitea-91

kashikoibumi/qt5-wip

kashikoibumi/strict-blob

kashikoibumi/binary

kashikoibumi/bytes-key

kashikoibumi/memoryview

kashikoibumi/literal

kashikoibumi/six

kashikoibumi/import-path

test4

test2

kashikoibumi/dark-theme

gitea-89

gitea-95

gitea-93

gitea-97

gitea-96

gitea-86

gitea-87

gitea-88

gitea-80

gitea-81

gitea-84

gitea-83

gitea-79

gitea-78

master

bootstrap

shportix/sql-refactoring

dependabot/pip/mistune-lt-2.0.6

shekhar-cis/test_sqlthread_refactor

sandakersmann/v0.6

osamacis/Kivy-baseclass-localization

osamacis/kivy-transifex-config

dependabot/pip/kivymd-1.1.1

teruteru128/refactor-swap64

813492291816/v0.6

akeelahmedqureshi/v0.6

dependabot/pip/docutils-lt-0.20.0

cis-muzahid/test_refactor_sqlthread

kdcis/mock-test

g1itch/qt5-wip

kdcis/v0.6-flatpak

g1itch/doc-python3

PeterSurda/cq101

navjotcis/telenium-test-cases

g1itch/knownnodes-opt

g1itch/ui-refactoring

g1itch/tests-screenshot

g1itch/refactoring-sql

navjotcis/bug-fixes18

g1itch/windows

kaue/patch-1

navjotcis/bug-fixes4

sgj3/issue1538

coolguy-cell/CQfixes11

python3

PeterSurda/w64fix

lakshyacis/graphicalqttest

sgj3/attachments

dimyme/cherry

dimyme/patch-3

python3android

Kleshni/POW

f97ada87/opmode-netcat-v2

kyucrane/mobileRecv

continuous

0.6.3.2

0.6.3.1

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.5.2

v0.4.5.1

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.5

Labels

Clear labels   

bug

Something isn't working as it's supposed to

  

build

Related to building or build system

  

dependencies

Pull requests that update a dependency file

  

developers

The issue is relevant mainly for developers rather than users

  

documentation

  

duplicate

  

enhancement

New feature

  

formatting

Code or UI text formatting

  

invalid

  

legal

  

mobile

Frontend for mobile devices (kivy)

  

obsolete

  

packaging

  

performance

  

protocol

Protocol change

  

question

  

refactoring

  

regression

Some issue, fixed in the past, appears again

  

security

  

test

  

translation

  

usability

  

wontfix

No Label

bug

build

dependencies

developers

documentation

duplicate

enhancement

formatting

invalid

legal

mobile

obsolete

packaging

performance

protocol

question

refactoring

regression

security

test

translation

usability

wontfix

Milestone

Clear milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

No Assignees

1 Participants

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-05#135

No description provided.