Custom Query (2447 matches)

Description

Because of the width of the last column in any table is not fixed but varies from minimum (set by user) to maximum (set by the width of the window) following happens:

When a row is being added to table (torrent list, file list, peer list) so that this table has to be scrolled up-down, the width of the last column in the table stays the same, though the width of the widget decreases by the width of the scrollbar. And horizontal scrollbar appears

But if the last column was wider than it is needed to show all its content that horizontal scrollbar is unnecessary.

Steps to reproduce

1. Tune the torrent list so that it wouldn't have any scrollbars
   
2. Increase window width by 40-50px (see attached "Screenshot 1.png")
   
3. Increase the height of the torrent properties section so that torrent list had to get vertical scrollbar (see attached "Screenshot 2.png")

Expected behavior

Only vertical scrollbar appears

Actual behavior

Both horizontal and vertical scrollbars appear. And to illustrate it is just because of the added width of vertical scrollbar you can decrease the height of torrents properties section, and both scrollbars will disappear

This bug applies not only to torrent list as in the example above, but also to file list and peer list in torrent properties tabs.

System information

Deluge Core version: 1.3.1
libtorrent version: 0.14.10.0
Debian Sid, 2.6.37 kernel

These files probably should not be included in the Windows installation of Deluge:

• POWRPROF.dll and MSIMG32.DLL are parts of Windows
• win32ui.pyd module and it's dependency mfc90.dll are not used (and never should be)
• freetype6.dll, libexpat-1.dll, libpng14-14.dll are parts of Windows Gtk+ runtime (without "Compatibility libs" option)

Currently each startup script handles its own options processing, and the 6 or so standard options code (-l -L -c -q -r) is c&p into each.

This results for example in differences between option handling such as regarding config file loading in ui.py and main.py:start_ui not to mention it is just bad form.

This patch subclasses OptionParser and handles the default options in a central place. It is mostly just moving code around.

There are possibly better ways to handle this, maybe create a class of StartupTarget of which StartUI, StartDaemon and _UI are subclasses of and handle options there, but this way has the smallest affect on the existing code.