search dialog: fix 10px-tall extension input field (#568) - #569

…on Linux

Follow-up to #569. The extension field there was pinned to
wxSize(40, 10) which collapsed it to a 10-pixel sliver on
wxGTK 3.2 / GTK3. The same row also has three wxSpinCtrls --
Min Size, Max Size, Availability -- pinned to wxSize(60, -1)
or wxSize(45, -1). On GTK those numeric widths aren't wide
enough to fit the stacked up/down arrow buttons plus the
digit display, so the value column gets clipped behind the
spin arrows.

Drop the hard-coded widths to wxDefaultSize and let the layout
engine choose. macOS / Windows render side-by-side spin
buttons that fit comfortably in the wider default; GTK gets
the larger geometry it needs for stacked arrows.

Reported by @danim7 on the #569 thread, confirmed by
@mifritscher2. Symptom and fix are mechanically identical to
#569's, just on the row below and on the spin-control widths
instead of the textctrl height.

…ject#737)

Six SpinCtrls in the Preferences dialog were pinned to widths
that fall below GtkSpinButton's intrinsic minimum on wxGTK 3.2 /
GTK3:

  IDC_TOOLTIPDELAY    wxSize(40, -1)    General tab
  IDC_SERVERRETRIES   wxSize(40, -1)    Server tab
  IDC_OSUPDATE        wxSize(60, -1)    Online Signature tab
  IDC_MAXDOWN         wxSize(140, -1)   Connection tab (Bandwidth limits)
  IDC_MAXUP           wxSize(140, -1)   Connection tab (Bandwidth limits)
  IDC_SLOTALLOC       wxSize(140, -1)   Connection tab (Bandwidth limits)

GTK3's GtkSpinButton is a composite widget (entry + stacked up/down
arrows). The internal box gadget needs ~80 px just to fit the entry
+ arrow column at the default theme; combined with the surrounding
wxFlexGridSizer / wxBoxSizer's tight allocation, forcing a smaller
or even an explicit "we know what we want" wx-side hint shoves the
entry's allocation below zero, which triggers

    Gtk-CRITICAL: gtk_box_gadget_distribute:
        assertion 'size >= 0' failed in GtkSpinButton

every time the panel is laid out (open Preferences, switch tabs,
expose). The 140 px hint on the bandwidth caps was originally widened
from 100 px in amule-project#463 to fit million-kB/s values; the new width itself
isn't too narrow, but combining an explicit wxSize with the column's
sizer constraints still leaves GTK's internal layout pass unhappy.
Same family as amule-project#569 / 82626f2 on the search dialog, just on the
Preferences side.

Fix: drop the explicit width to wxDefaultSize on all six and let
the layout engine pick. macOS / Windows already render side-by-side
spin buttons that fit comfortably in the default; GTK gets the
larger geometry it needs for stacked arrows. The label / unit text
on either side of each spin keeps its own sizer flags, so the row
overall still flows the same.

Reported in amule-project#737 (Diego Heras), verified on amule-dev-vm with the
fixed AppImage — no more Gtk-CRITICAL SpinButton warnings on
Preferences open or tab switch.

The Gtk-CRITICAL GtkScrollbar variant @ngosang also reported is a
separate widget family (likely a wxScrolledWindow / wxListBox
sub-widget), tracking that independently of this PR.

Six SpinCtrls in the Preferences dialog were pinned to widths
that fall below GtkSpinButton's intrinsic minimum on wxGTK 3.2 /
GTK3:

  IDC_TOOLTIPDELAY    wxSize(40, -1)    General tab
  IDC_SERVERRETRIES   wxSize(40, -1)    Server tab
  IDC_OSUPDATE        wxSize(60, -1)    Online Signature tab
  IDC_MAXDOWN         wxSize(140, -1)   Connection tab (Bandwidth limits)
  IDC_MAXUP           wxSize(140, -1)   Connection tab (Bandwidth limits)
  IDC_SLOTALLOC       wxSize(140, -1)   Connection tab (Bandwidth limits)

GTK3's GtkSpinButton is a composite widget (entry + stacked up/down
arrows). The internal box gadget needs ~80 px just to fit the entry
+ arrow column at the default theme; combined with the surrounding
wxFlexGridSizer / wxBoxSizer's tight allocation, forcing a smaller
or even an explicit "we know what we want" wx-side hint shoves the
entry's allocation below zero, which triggers

    Gtk-CRITICAL: gtk_box_gadget_distribute:
        assertion 'size >= 0' failed in GtkSpinButton

every time the panel is laid out (open Preferences, switch tabs,
expose). The 140 px hint on the bandwidth caps was originally widened
from 100 px in #463 to fit million-kB/s values; the new width itself
isn't too narrow, but combining an explicit wxSize with the column's
sizer constraints still leaves GTK's internal layout pass unhappy.
Same family as #569 / 82626f2 on the search dialog, just on the
Preferences side.

Fix: drop the explicit width to wxDefaultSize on all six and let
the layout engine pick. macOS / Windows already render side-by-side
spin buttons that fit comfortably in the default; GTK gets the
larger geometry it needs for stacked arrows. The label / unit text
on either side of each spin keeps its own sizer flags, so the row
overall still flows the same.

Reported in #737 (Diego Heras), verified on amule-dev-vm with the
fixed AppImage — no more Gtk-CRITICAL SpinButton warnings on
Preferences open or tab switch.

The Gtk-CRITICAL GtkScrollbar variant @ngosang also reported is a
separate widget family (likely a wxScrolledWindow / wxListBox
sub-widget), tracking that independently of this PR.

…mule-project#570)

The log views migrated to wxStyledTextCtrl (Scintilla) in amule-project#548 paint
their colours from the system theme once, in the constructor. The native
wxTextCtrl they replaced followed the platform appearance automatically;
Scintilla does not, so a live light/dark switch left the three log panes
(aMule Log, aMuleGUI Log, Server Info) stuck in the previous theme's
colours while the rest of the UI re-themed. Re-apply the styles on
wxEVT_SYS_COLOUR_CHANGED so the panes track the appearance.

Also guard against a foreground/background that resolve with too little
contrast to read: on macOS the window/text system colours are
appearance-aware and, on some wx builds, come back near-identical, which
paints the whole log invisible (amule-project#569). When the pair is unreadable, keep
the theme's background and force a legible foreground from its
brightness. Windows/GTK return static, well-contrasted colours and are
unaffected.