Qt UI

[ETZel]

I've revivied the Deluge QtUI project ( https://github.com/nnemkin/deluge_qt), that was abandoned a year ago. It was mentioned on the forum:  http://forum.deluge-torrent.org/viewtopic.php?f=8&t=29075.

Compared to gtkui, it's about 90% complete. (Past year changes haven't been ported yet.)

I'd like to ask Deluge devs, if if there's any interest in it being integrated into Deluge and what are the conditions for that.

[andar]

I'm a bit hesitant to include this with the main package for a few reasons:

• Maintenance - are you going to be maintaining the QtUI? Keeping up with development of other parts of Deluge? Fixing bugs? This is a lot of work.
• Code duplication - there is likely a lot of code duplication between the UIs and the better method would be to refactor a lot of the code to reduce this duplication. This is likely a very big task and would be pretty invasive for the current gtkui. This could be done in small pieces and it would likely be something we would need to take seriously if we want both UIs to be viable into the future.
• Value - what does the QT interface really bring to the table in terms of value? We already have a decent GTK interface that runs on all platforms, including KDE environments. Do we really need another gui to maintain/consider?
• Plugins - its yet another UI that plugin developers would need to develop an interface for. Many will likely not do so, which will diminish the use of the QT interface.

Now, I'm not totally against including the UI, I just think we really need to consider what impact it will have if we do include it and if our time and resources could be better spent improving the existing UIs. Bottom line, if we were to include this, we would need a commitment from you to keep up with the maintenance and new feature development.

We will not accept a code dump of this magnitude without someone willing to work on it and keep it fresh.

Maybe someone else could chime in with their thoughts? Anyone out there who would really like to see a QT interface and maybe explain why?

[ETZel]

Reasons for QtUI:

• It looks/integrates better with Windows (near-native), Mac (acceptable) and KDE (native). That's THE reason. Otherwise, GTK is fine indeed and runs everywhere.
• It's easier to deploy on Win and Mac (custom-built PyQt+Qt is basically one .pyd file).
• It's faster at loading large lists/trees. Although that's probably fixable in gtkui.
• (Subjective) QtUI is small, Qt API is great and it's easy to experiment and add new features.

Problems with QtUI:

• Plugins. Plugins that only need UI for configuration can be provided with some abstract API or even simply a template that demonstrates how implement common configuration primitives. For complex UI plugins (like Pieces) there is no solution short of rewriting them by myself.
  On the other hand, Deluge doesn't have a lot of external plugins, and in my opinion half of these plugins should really be converted to core UI features. I'm "inclusionist" so to speak.
  One of QtUI ideas was to (make it easy to) bring Deluge on par with uTorrent and further. If it's out of place and against the project spirit, then please ignore me and let QtUI rest in peace.
• Fraction of non-Gnome Deluge users is probably small. Then again, it may not be Deluge's goal to attract these users.
• Qt5 is a disaster and post-Qt4 future is uncertain at best.

Non-problems with QtUI:

• Maintenance. If it's included, I'm going to maintain it.
• Code duplication. First of all, both Qt and GTK UIs are pretty slim. Sure, they have the same overall structure (files/classes) and logic. But on the low level, most of their code is toolkit-specific glue. Refactoring out the logic would still require a similar amount of glue code, but would also create a monstrous abstraction that is "toolkit-agnostic Deluge UI". I suspect that code complexity and maintenance burden will be higher with this abstraction than without it.

(BTW I was thinking of making a CocoaUI after QtUI stabilizes.)

Some numbers to get the scope of this potential contribution:

• core+common: 7097 LOC in 38 files
• gtkui: 8694 LOC in 32 files + 13 UI files - it could be made leaner
• webui: 6113 JS LOC in 57 files + 1445 Python LOC
• qtui: 2880 LOC in 25 files + 15 UI files - missing the "Create Torrent" dialog
• console: 4469 LOC in 38 files
• bundled plugins: 5363 LOC in 88 files + 833 JS LOC

[andar]

After discussing with other team members, I think that we've decided against including the Qt ui. The primary reason being support and maintenance. We simply feel that the additional bug reports, support requests and packaging concerns will stretch our limited resources even thinner without a lot of perceived value.

Of course you should feel free to continue to develop the UI outside of the main project, but I would totally understand if you didn't want to do that.

Regardless, thanks for the effort :)

[Murz]

This issue will never fixed or may be reopened? In KDE there are only one QT native torrent interface (for remote torrent server) - transmission-qt, and it popularity is growing:  http://qa.debian.org/popcon-graph.php?packages=transmission-qt

So Deluge-QT interface will be very useful for all KDE users, even without full plugin support (for configure plugins they can use web interface).

[Murz]

A lot of discomfort in deluge-gtk version using in KDE is not-kde-native file select dialogs, but this is very often used function in torrent, so creating light qt interface (with only basic functions - add torrent, show status, pause-stop, etc, and without advanced configuration elements) will be great for KDE users.