STR #3449

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

STR #3449

Application:FLTK Library
Status:3 - Active
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:FL_Window - New SKIP_TASKBAR Flag and Patch
Created By:dylanetaft
Assigned To:AlbrechtS
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 dylanetaft
19:58 Jan 08, 2018
#2 dylanetaft
21:23 Jan 08, 2018
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 dylanetaft
19:58 Jan 08, 2018
On Linux\X11, the current behavior forces borderless windows to hide from the taskbar.

This is not always desired - think Winamp, Beep, XMMS, GKRELLM, or other apps that show in the taskbar but don't have window decorations

The attached patch will not change behavior, but adds support for a developer to call void Fl_Window::skip_taskbar(int), identical to the Fl_Window::clear_border(int) function

This was partially vetted out over the group!topic/fltkcoredev/DQ-VXk9mPoM

I've attempted to follow the coding style guide, and tested lightly on both Linux and Windows drivers.

The only remote concern I have - WS_EX_APPWINDOW extended window style will now be set on most normal windows.  Researching, this appears to be fine.  Alternatively that code can be moved to the if branch for checking if there is a border....but then the override will not always work as intended for all types of windows.

// Forces a top-level window onto the taskbar when the window is visible
    if (!w->skip_taskbar()) {
      styleEx |= WS_EX_APPWINDOW;
#2 greg.ercolano
20:31 Jan 08, 2018
Nice -- patch looks simple and clean. Our devs familiar
with this part of the code should check it out and reply.

I have access to all platforms, so I can test which ever platforms
the other devs can't test.

Some items:

    1) Which SVN version of FLTK is this patch for?
       (Note: when you generate patches with 'svn diff', it will
       includes the rev#s in the patch, which is helpful)

    2) One thing that might help this get approved quickly
       is a separate small test program that demonstrates the
       feature. (e.g. some buttons that enable/disable the
       feature so we can test across platforms)
#3 dylanetaft
21:24 Jan 08, 2018
See newly attached fltk_borderless_demo.cpp file
I am compiling it with this oneliner, works in MSYS2(Windows) and on Ubuntu

g++ fltk_borderless_demo.cpp -o fltk_borderless_demo -lfltk -I/usr/local/include -L/usr/local/lib
#4 dylanetaft
21:27 Jan 08, 2018
SVN version:
I cloned svn co fltk-1.4 around noon eastern time, 1/8/2017, and finished patching later that day.  I don't actually know svn at all, so I ended up converting it to a git repo for personal use, pushed to my own github account as a fork, and deleted my local SVN repo, so I can't get the exact SVN commit we are on, sorry!
#5 dylanetaft
21:36 Jan 08, 2018
If I submit patches in the future, I'll try to keep the work in an SVN repository.  I need to do some reading on it.  
#6 AlbrechtS
04:41 Jan 09, 2018
Assigning STR to myself, setting status "Active".

Thanks for the patch, looks good. I'll do some tests and check if I can find any unwanted side effects.

Note to myself and other devs: One side effect /would/ be that we change the ABI by setting an additional flag in well-known methods, for instance in clear_border(). This would imply that executables compiled with and linked to an older *shared* library would not work correctly with a new shared library. This is negligible here since 1.4.0 defines a new ABI, but it definitely precludes using this patch with 1.3.x.

@Dylan: if you want to use git for future patch proposals you can clone our git mirror at GitHub ( directly and put this clone on GitHub. You should be aware that this FLTK repository may be replaced by a new one [1] once we officially move to git, but you can use it for patches. You can see the svn revision number in every git log message. We don't accept pull requests yet since we can't use them directly with our git repo - we must use patches for svn that will then be transferred to our git mirror.

[1] The new git repository will likely have different hashes and may differ elsewhere so you may have to recreate work based on it by using patches or whatever.
#7 djcj
02:31 Feb 06, 2018
I'm always doing it this way:

bool window_taskbar, window_decoration;

void set_taskbar(Fl_Double_Window *o) {
  if (!window_taskbar) {

void set_undecorated(Fl_Double_Window *o) {
  if (window_decoration) {
  } else {


window_taskbar = true;
window_decoration = false;


This way you can whether to display the taskbar entry, the window decoration, both or none.
It works reliable but felt always a bit like a hack.
#8 dylanetaft
21:53 Nov 12, 2018
This ever get considered for inclusion?  
#9 AlbrechtS
09:39 Jul 12, 2020
Sorry for the late response.

The answer is: yes, very likely. I'm working on it, but there's more stuff to do.

Current status: I updated your patch and created a branch in my FLTK fork on GitHub. You can follow my activities there:

I'm not sure if everything works in this state, needs testing.

Note: I did not yet create a Pull Request (PR) because I have some thoughts to improve the API.

I'll follow-up later when time permits.
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.