Tiny Core Linux

General TC => Programming & Scripting - Unofficial => Topic started by: MikeLockmoore on September 13, 2009, 09:39:25 PM

Title: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 13, 2009, 09:39:25 PM
I've been working on modifying flwm to display window titlebars in a more conventional "topside" location.  The version I have is starting to work, but is still very crude and not ready for public use yet.  But here is a sneak peek at what my work-in-progress.  ;)
--
Mike Lockmoore
Title: Re: "Topside" titlebar version of flwm
Post by: roberts on September 13, 2009, 10:11:24 PM
Looking real good!
Title: Re: "Topside" titlebar version of flwm
Post by: jls on September 14, 2009, 03:24:44 PM
1
I think it's faster (don't know why) to reach the title of a window if this is on the side, but it's true is more difficult to read.
2 the title with the focus is white while the others are light gray, not so much different, what about black and white 4 example
3 any substitute for alt+enter?
4any possibility 4 shortcuts 4 resizing a window?
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 15, 2009, 06:10:33 AM
jls_legalize: Addressing your questions:
1) Maybe left-side bar is easier for you, but I think this will vary a lot between people.  I generally keep my mouse toward the right side of the screen, because many apps now put the scrollbar there (unlike many early X-Windows apps), so for me, the top is usually closer.  As we say here in the USA, "Your milage may vary".

2) I agree that there is lack of contrast between the active window title and the others.  I have already experimented a bit with the color, and will probably try to make the colors somewhat more distinct.  Also, I know some people really like to tinker with the look of their system, so I may experiment with using optional environment variable to define colors for title text and bar background, but have some defaults that provide at least a little more contrast than flwm currently does.

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?

4) Maybe we can have a set of keybindings to resize (and maybe move?) the windows, but my initial goal is to just re-orient the look of the window titlebars.

Also, in general, keep in mind a big goal for roberts is to keep the default WM small and fast, so each proposed new feature will need to be carefully considered, and we may try to simplify and streamline the WM by removing or revising some current features.
Title: Re: "Topside" titlebar version of flwm
Post by: jls on September 15, 2009, 06:48:06 AM
......
Also, in general, keep in mind a big goal for roberts is to keep the default WM small and fast, so each proposed new feature will need to be carefully considered, and we may try to simplify and streamline the WM by removing or revising some current features.
I use win 95 on a laptop with 16 MB ram and is fast and it has all the key bindings
Title: Re: "Topside" titlebar version of flwm
Post by: bigpcman on September 15, 2009, 08:24:13 AM
I've been working on modifying flwm to display window titlebars in a more conventional "topside" location.  The version I have is starting to work, but is still very crude and not ready for public use yet.  But here is a sneak peek at what my work-in-progress.  ;)
--
Mike Lockmoore

Looks good to me. I look forward to being able to use this.
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 15, 2009, 08:51:56 PM
Quote
I use win 95 on a laptop with 16 MB ram and is fast and it has all the key bindings

jls_legalize: Sure, new keybindings for the WM or any one app don't require a lot of code compared to an entire operating system, but I think most of us really like TC because its small size provides many benefits.

At some point, I may experiment with some extra keybindings and see what the codesize impact is.  Then the TC core team can decide whether it is a good trade-off for the base system.  I'm sure you know that other WMs are available with more features, and perhaps I will offer an optional "deluxe" build of flwm as a TC extension with a few of the niceties that we are discussing here and in other threads.
--
Mike L.


--
ML
Title: Re: "Topside" titlebar version of flwm
Post by: fladd on September 16, 2009, 01:04:57 AM
Talking about keybindings: The simple addition of moving a window with ALT and draging anywhere would be a very nice one!

fladd
Title: Re: "Topside" titlebar version of flwm
Post by: roberts on September 16, 2009, 12:04:08 PM
FWIW
Left click on left border allows dragging
Left click on right border resizes
Title: Re: "Topside" titlebar version of flwm
Post by: jls on September 16, 2009, 04:43:26 PM
some windows are movable also dragging from certain point inside the window.
Try xchat (the gtk 1 version)
Title: Re: "Topside" titlebar version of flwm
Post by: fladd on September 17, 2009, 11:48:01 AM
Well, I haven't seen one that is movable without touching the left bar. So I guess those that can be moved otherwise (like Xchat) seem to be a minority.
Moving windows with Alt+drag is very common across window managers (except the one underlying windows). It is also a very convenient way to move windows since you can do it from every mouse position.

fladd
Title: Re: "Topside" titlebar version of flwm
Post by: roberts on September 17, 2009, 02:09:42 PM
Left click and drag on title area is by far easier than using holding down a key and dragging.
Besides with smart window placement of flwm, I find that I rarely need to  move overlapping windows as in the other window managers. We don't need to emulate duplicate functions, especially those already involving the use of a mouse. You have many other choices of window mangers as well.
Title: Re: "Topside" titlebar version of flwm
Post by: thane on September 17, 2009, 04:33:25 PM
I'm supportive of the efforts to debug and improve flwm, and I'll use whatever results. But if the topside titlebar is more trouble than it's worth, maybe we could settle for a left titlebar like this?

t
i
n
y
c
o
r
e

Truncated as needed to avoid clobbering buttons?
Title: Re: "Topside" titlebar version of flwm
Post by: roberts on September 17, 2009, 05:58:07 PM
top side flwm is working great. It is in 2.4rc1 that is currently being alpha tested.
So, sooner than later, it will be available.

To print characters one per line does not allow much especially with a shorter vertical than horizontal. Besides which once truncated is even less useful.

I knew Mike was working on a top side flwm, in the meantime, I hacked out title text on the 'classic' flwm. There is no need for my hacked version since, via Mike's effort, top side has come to fruition so quickly.
Title: Re: "Topside" titlebar version of flwm
Post by: fladd on September 18, 2009, 05:17:53 AM
Left click and drag on title area is by far easier than using holding down a key and dragging.
Besides with smart window placement of flwm, I find that I rarely need to  move overlapping windows as in the other window managers. We don't need to emulate duplicate functions, especially those already involving the use of a mouse. You have many other choices of window mangers as well.

Well, I think we just have different opinions here :) I think having the ability to grab a window everywhere without needing to place the courser exactly into a verz small area is much easier.
Anyway, if it will not be in there it just won't.

Another question: Will the option to have the title bar on the left side remain? I think it is a great concept, especially since today most screens are widescreen and there it saves space of course. So it is perfect, since, in contrast to other WM it uses space where it is most available. And even on normal screens there is more width available then height.

fladd
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 18, 2009, 05:49:38 AM
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
Title: Re: "Topside" titlebar version of flwm
Post by: clach04 on September 18, 2009, 09:48:40 AM
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


Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 25, 2009, 07:20:41 PM
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.   :P
--
Mike L.

Title: Re: "Topside" titlebar version of flwm
Post by: curaga on September 26, 2009, 02:37:25 AM
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)
Title: Re: "Topside" titlebar version of flwm
Post by: Juanito on September 26, 2009, 03:03:23 AM
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.
Title: Re: "Topside" titlebar version of flwm
Post by: roberts on September 26, 2009, 05:53:44 AM
Quote
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.
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 26, 2009, 02:45:12 PM
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. 
Title: Re: "Topside" titlebar version of flwm
Post by: curaga on September 26, 2009, 02:57:28 PM
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.
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 26, 2009, 03:18:48 PM
curaga: PM me an email address?
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 26, 2009, 06:52:51 PM
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.
Title: Re: "Topside" titlebar version of flwm
Post by: roberts on September 26, 2009, 10:30:22 PM
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.
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on September 27, 2009, 08:40:14 AM
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
Title: Re: "Topside" titlebar version of flwm
Post by: Plume on October 15, 2009, 11:39:11 AM
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?
Title: Re: "Topside" titlebar version of flwm
Post by: MikeLockmoore on October 15, 2009, 02:36:18 PM
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.   :D  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 (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.