thunderbird in German?

Ralf Mardorf ralf.mardorf at
Mon Aug 5 09:17:15 UTC 2019


it's too funny that a thread about enabling translations for a Mozilla
MUA excesses to a general discussion about development nowadays and
it's even more funny that this kind of discussion happens on a lot of
mailing lists (for example [1]).

Off-list a subscriber asked why GTK and Qt do look ugly. The problem is
that a lot of people who maintained good themes discontinued those
themes, since they can't spend the time to rework the complete theme
with each micro update of Qt and GTK. I found a theme for GTK2 and GTK3
that is comparable to the old Adwaita GTK2 theme, so all GTK apps look
more or less like GTK2 apps, while the new Adwaita theme makes all GTK
apps look like GTK3 apps, even faking the look of GTK3 widget options
GTK2 doesn't have. The theme I found is called arc-theme, but I still
had to edit the theme, for my taste it's not good by default, but at
least most of the work already is done by the maintainer of the theme.

I don't use a desktop environment, I'm just using a window manager and
I stay with X, while on Linux there are tendencies to migrate to

For Qt3, Qt4 and Qt5 different "Troll"tech configurations are required,
to go into details is off-topic and my time frame doesn't allow to do
so. Perhaps helpful, Qt5 requires a plugin:

If somebody should use GNOME apps,
might be helpful to keep some consistency with non-GNOME apps.

On Mon, 5 Aug 2019 06:47:03 +0200, Polytropon wrote:
>Alt+left click

A reason why I migrated from jwm to openbox. Actually I don't use it
very often, since I've written a script [2] that does move windows that
hide the title bar under the top panel, which was most of the times the
reason to move windows by Alt+left_mouse_button for me.

On Mon, 5 Aug 2019 06:47:03 +0200, Polytropon wrote:
>tiling window manager

as well as some desktop environments could become a PITA, if a parent
window opens a child window, so the "are you sure to continue request"
window could be invisible, since they don't follow some freedesktop or
whatsoever else rules.

>On Sun, 04 Aug 2019 02:07:00 +0200, hw wrote:
>> So I don't understand how anyone can put up with the useless crap you
>> have to tap on while you can't see anything and achieve nothing.

I'm using an iPad Pro 12.9" 3rd gen with an Apple Pencil 2nd gen. What
graphic tablet with or without build-in monitor for FreeBSD, Linux or
any other desktop PC can hold a candle on the desktop, let alone when
drawing in nature? I'm doing almost everything with a desktop PC, but
even for music productions I'm doing most of the work on the iPad
nowadays. My impression is that the community of computer users who
prefer desktop PCs for almost everything, but migrating for graphic and
music to iPads (for good reasons not migrating to Android or other
tablets) is increasing rapidly.

On Mon, 5 Aug 2019 07:11:20 +0200, Polytropon wrote:
>That is an important thought!
>As Gtk2 probably will EOL just like Gtk (1) did, newer toolkit
>versions _might_ tie much stronger into Linux infrastructures
>than the current version does, and porting them to FreeBSD might
>cause trouble because of missing kernel interfaces or library

Let alone that they already cause issues on Linux machines, especially
apps that started the migration from GTK2 to GTK3, the reason why the
GTK3 port of Claws is unusable. (To the subscriber who replied
off-list:  Claws GTK2 is not experimental, its GTK3 port is

FWIW non-GUI apps are not necessarily better than some silly burger
menu GNOME apps:

On Wed, 31 Jul 2019 12:12:26 +0200, an Ubuntu users mailing list
subscriber wrote:
>To quote an anonymous wit:
>Hey, don't dismiss Vim. I've been using Vim for about 3 years now.
>Mostly because I can't figure out how to exit...


The attitude that failure isn't the fault of the developers of
brand-new software, but the fault of all the developers of apps that
are used since decades, if they don't rewrite their apps to fit to the
brand-new software:

"We" change the underlying infrastructure, so "we" are breaking
everything good and stable (but actually it anyway isn't "good" in the
first place) and we do not care. It's the duty of other to fix the
issues "we" cause. Wayland is not the first change by people with this
attitude, within the last decade it happened several times and some
things were never fixed, even not after ten years.

[rocketmouse at archlinux ~]$ cat /usr/local/bin/window2unhide 

# window2unhide 2017-08-25 Ralf Mardorf

# To configure window2unhide you could use
/etc/profile.d/ #
# values of the wanted x and y position of the window
# export WINDOW2UNHIDE_X_POS=hold
# export WINDOW2UNHIDE_Y_POS=141
# delay required to ensure that a launched application's window is
active # export WINDOW2UNHIDE_SLEEP=1
# values to eliminate x and y drift of the window
#   this fix is needed for all windows
# offset required to eliminate x and y drift of the window if x and/or
y do/does not change #   this offset is needed for windows that open
under the top panel #     but its unfavorable for windows that don't
open under the top panel # export WINDOW2UNHIDE_X_OFF=1

unhide_window ()
  # values of the wanted x and y position of the window

  # value to eliminate x drift of the window

  # calculate value for x position of the window...
    $X) # ...if the x position doesn't change subtract the value to
  eliminate x drift and add an offset case $WINDOW2UNHIDE_X_OFF in
    *) # ...if the x position does change subtract the value to
  eliminate x drift X_POS=$(expr $WINDOW2UNHIDE_X_POS -

  # value to eliminate y drift of the window

  # calculate value for y position of the window...
    $Y) # ...if the y position doesn't change subtract the value to
  eliminate y drift and add an offset case $WINDOW2UNHIDE_Y_OFF in
    *) # ...if the x position does change subtract the value to
  eliminate x drift Y_POS=$(expr $WINDOW2UNHIDE_Y_POS -

  # move the window to new position
  wmctrl -i -r $WINDOW -b remove,maximized_vert,maximized_horz
  wmctrl -i -r $WINDOW -e "0,$X_POS,$Y_POS,$WIDTH,$HEIGHT"

case $1 in
  "") # unhide active window
    eval $(xdotool getwindowgeometry --shell $(xdotool getactivewindow))
  *)  # launch an application and unhide its window
    $@ &
    sleep $WINDOW2UNHIDE_SLEEP # ensure that the window of the launched
application... eval $(xdotool getwindowgeometry --shell $(xdotool
getactivewindow)) wmctrl -l | grep $(printf '%x\n' $WINDOW) | grep -qi
$1 # the active window case $? in

More information about the freebsd-questions mailing list