"Topside" titlebar version of flwm

[MikeLockmoore]

fladd:

I like the option of Alt key + left-click and drag to reposition a window, as found in some other WMs, which is very useful if your window somehow gets placed where the title bar is not on-screen.  However, I don't know how easy it would be to implement in flwm.  Normally, if you click over the content part of an application, the event is sent to the content window's event handler, and I'm not sure the flwm window frame's event handler gets a chance to hook it.  I will probably try to implement it, and if it is doable, I will at least make it a compile-time option.  The core team may decide not to include it in the base version, however.  And I may not be able to figure out how to do it anyway. My knowlege of the underlying TinyX and X-Windows is pretty limited.    We'll see.

As for the titlebar location (left or top), the modified flwm must be compiled for one or the other, but not both, so you would not be able to simply make a configuration change somewhere and restart.  This was to keep the base version of flwm as small as possible.

However, I think the core team will make a left-side version available as an extension, so if you really prefer it like that, you simply need to install the left-side version of flwm and reboot.  This left-side version will still have some of the other changes roberts and I made to better integrate with TC.
--
Mike

[clach04]

3) Sorry, I don't recall what alt+enter does in the standard flwm.  I guess I don't use that right now.  What is it used for and what kind of substitute would be useful?

alt+enter is Minimize window. flwm is quite aggressive in how it grabs alt-enter though, for instance if using  rdesktop in fullscreen mode (rdesktop -f) one is supposed to use ctrl+alt+enter to exit out of full screen mode.  flwm (in TC 2.3) seems to ignore the ctrl and try to minimize which fails, leaving rdesktop in full screen mode. I've had to use ctrl+alt+baskspace to "quit" out ;-) NOTE -K flag to rdesktop can help here.

Back to the question, I think different modifiers would be better to avoid collisions with regular applications, E.g. maybe use the "Windows" key (Super_R)? Now I happen to be using  a laptop with out a Windows key but I'm OK with using xmodmap to remap one of my Alt keys (I don't need an AltGr key). CrunchBang linux uses the Windows key for most of the shortcuts it uses and I think it works well.

Chris

[MikeLockmoore]

clach04: It seems that fltk does not recognize the "Windows" key, at least not as compiled in TC, so no use for that.  

I've been making good progress on flwm behind the scenes.  I've implemented some Ctrl + Alt + (key) combos to move and resize the screen in various ways, hopefully intuitive:

Ctrl + Alt + (arrow) : Move window a bit (at least 4 pixels, or 1/20th of the "open" space)

Ctrl + Alt + '=/+': Make window larger by 32 pixels in each direction

Ctrl + Alt + '-': Make window smaller by 32 pixels in each direction

Ctrl + Alt + ',/<' : Make window narrower by 32 pixels

Ctrl + Alt + './>' : Make window wider by 32 pixels

Ctrl + Alt + PageUp or 't': Make window taller by 32 pixels

Ctrl + Alt + PageDn or 's': Make window shorter by 32 pixels

I've also implemented better support for colored window titles and title text color.  (See attached image).  This requires -fg (color) and -bg (color) options to be added to the .xsession file:

Code: [Select]

Xvesa -br -screen 1024x768x32 -shadow -mouse /dev/input/mice,5 -nolisten tcp -I 2>&1 > /dev/null &
waitforX
"$DESKTOP" -fg white -bg darkblue 2>/tmp/wm_errors &
export WM_PID=$!
[ -n "$THEME" ] && cp /opt/jwmThemes/"$THEME" .jwmrc-theme
if [ -n "$BACKGROUND" ]; then
  setbackground image /opt/backgrounds/"$BACKGROUND"
else
  [ -x ./.setbackground ] && ./.setbackground
fi
[ "$ICONS" == "wbar" ] && /usr/bin/wbar.sh
[ -x ./.mouse_config ] && ./.mouse_config &
[ "$DESKTOP" == "flwm" ] && flit &

Now I see a vast array of flwm themes coming.  
--
Mike L.

[curaga]

Mike, I recently thought to make the fltk-xft extension as it has not yet been made. Built libfltk with --enable-xft --enable-threads with  CXXFLAGS="-Os -s -march=i486 -mtune=i686 -pipe -fomit-frame-pointer -fno-rtti -fno-exceptions".

Everything else works, but flwm segfaults when clicking on anything in the menu (until that point things work out fine, flwm using antialiased fonts as well). All other fltk apps in the base run fine.

This is with the flwm in 2.3.1, so might be related to the left-side bar. Or might be a general bug in flwm. Could you check? If you wish to use the extension I built, I'll PM you a copy.


BTW: what is the button with nothing in it, in the latest screenshot? If it is a minimize button, why not put an underscore in it?

Edited to remove typo (s/no-extensions/no-exceptions/g)

[Juanito]

99% sure it's nothing to do with this, but I've stopped using "-fno-rtti -fno-extensions" after it caused problems with other stuff.

[roberts]

BTW: what is the button with nothing in it, in the latest screenshot? If it is a minimize button, why not put an underscore in it?

It is the standard flwm button to iconize the window. The underscore is used for window-shading, i.e., show title bar only, which is currently not deployed.

[MikeLockmoore]

curaga: The build script for flwm is (provided by roberts):

Code: [Select]

#!/bin/sh
g++ -Os -fno-exceptions -fno-rtti -fpic -c main.C
g++ -Os -fno-exceptions -fno-rtti -fpic -c Frame.C
g++ -Os -fno-exceptions -fno-rtti -fpic -c Rotated.C
g++ -Os -fno-exceptions -fno-rtti -fpic -c Menu.C
g++ -Os -fno-exceptions -fno-rtti -fpic -c FrameWindow.C
g++ -Os -fno-exceptions -fno-rtti -fpic -c Desktop.C
g++ -Os -fno-exceptions -fno-rtti -fpic -c Hotkeys.C
g++ -lfltk -lfltk_images -lfltk_forms -lpng -o flwm main.o Frame.o Rotated.o Menu.o FrameWindow.o Desktop.o Hotkeys.o
strip flwm

So I have been using the options "-fno-rtti -fno-extensions" but not some of that other stuff.  I don't know if the options in this build script would work well for rebuilding the fltk libs themselves, but perhaps you can try it like that.

By the way, I've wanted to make a version of fltk with xft (font smoothing) ever since I started working with TC.  I know it takes a bit more memory and CPU, but I have enough of each to spare (even with a 5 year-old laptop), and it makes the text much more pleasant to read.  To me at least.    I hope you are successful in building an enhanced fltk lib and share it with us!

Also, roberts answered your direct question.  I'm going to try to make the buttons a bit more visible when darker colors are used.  That empty iconize/hide button is a bit hard to see with a dark color as the titlebar background.
--
Mike L. 

[curaga]

I can try to get a backtrace for where flwm crashes with the xft-fltk lib. Would you send me a debug version of the latest flwm code?

Don't strip it, and replace -Os with -ggdb.

[MikeLockmoore]

curaga: PM me an email address?

[MikeLockmoore]

I have changed the window-painting code again to be based on the FLTK color "FL_BACKGROUND2_COLOR", which is normally used to color the background of text input fields and other GUI elements (usually lighter in color than the normal window background).  This keeps the color customization in flwm contained to just the window frame.  I also removed the need to specify a foreground color for the title text, by letting FLTK pick a text color based on the darkness or lightness of the background2 color.  So the .xsession could now be something like this:

Code: [Select]

Xvesa -br -screen 1024x768x32 -shadow -mouse /dev/input/mice,5 -nolisten tcp -I 2>&1 > /dev/null &
waitforX
"$DESKTOP" -fg white -bg darkblue 2>/tmp/wm_errors &
export WM_PID=$!
[ -n "$THEME" ] && cp /opt/jwmThemes/"$THEME" .jwmrc-theme
if [ -n "$BACKGROUND" ]; then
  setbackground image /opt/backgrounds/"$BACKGROUND"
else
  [ -x ./.setbackground ] && ./.setbackground
fi
[ "$ICONS" == "wbar" ] && /usr/bin/wbar.sh
[ -x ./.mouse_config ] && ./.mouse_config &
[ "$DESKTOP" == "flwm" ] && flit &
I have also improved the button highlighting to be a bit more visible when the darker titlebar colors are used.  EDIT: see attached screenshot.
--
Mike L.

[roberts]

Having options in .xsession DESKTOP statement will break the automatic use of alternate window managers, as they do not expect such command line options to be present.
To prevent such a wrapper script could be used. It would then be desireable to have in both path and backup.

FWIW, I don't see a -bg2 in the updated ,xsession.

[MikeLockmoore]

Ok, maybe this -bg2 idea isn't so good.  I'm going to try to implement an evironment variable method of overriding the titlebar color.  Back soon (I hope).

EDIT: It wasn't real quick, but it is working now and a copy has been passed to the TC core team.  With this change, you won't pass any -fg or -bg2 arguments to flwm, so the normal .xsession script can be used.  But you can pass a hex-encoded color specification to flwm via an environment variable.  You would be able to define the color in your .profile script in your home directory by inserting a line like this:

export FLWM_TITLEBAR_COLOR='10:2F:6A'

where 0x10 is the level of red (16 out of 255), green is 0x2F (47), and blue is 0x6A (106)... so this is a muted dark blue with a bit of green.

The title text color is selected automatically for good contrast.  I think you can still force a text color with the -fg command-line option as long as it has good contrast, but the standard .xsession provided in TC base will not have any such options so that different WMs (openbox, jwm, etc.) can be used with no changes.  So if you change your .xession like I showed above, you would need to change it back if you ever switched to a different WM.  Perhaps the text color can be also specified by an environment variable in a future version.

I hope this titlebar color-enabled version of flwm is included in the next release candidate for TC 2.4 so people can experiment with it.

NOTE: The new titlebar coloring feature currently does not work if you define the "plastic" scheme (AKA theme/style) in your .Xdefaults file.  With FLTK, the plastic scheme paints the GUI controls and windows backgrounds in a manner similar to the early iMac Mac OS style.  The gtk+ scheme works fine in the updated flwm for colored titles.  Perhaps the plastic scheme can be supported in a future release.
--
ML

[Plume]

I agree with fladd: a leftside titlebar suits better to the screen form factor, especially for 16:9 screens. Although for my own I would prefer a rightside titlebar... Any hope to have a user parameter to control that?
Of course a topside titlebar looks more familiar but has Tinycore to look familiar?

[MikeLockmoore]

I think you can simply install the traditional left-side title version of flwm using AppBrowser, which will supercede the built-in version, if you prefer that.

No, I don't have any plans to make a right-side version.   Sheesh.  Next people will want a diagonal version.    Seriously, I plan to work on some other projects before spending a lot more time on window managers.  If you saw my post in another subforum [http://forum.tinycorelinux.net/index.php?topic=3408.0], you know I have some interest in quite radical user-interfaces.  But I don't plan to work on new WM features in the next few months.
--
Mike L.