FLTK logo

STR #3122

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 | Roadmap 1.3 | SVN ⇄ GIT ]

STR #3122

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:1 - Request for Enhancement, e.g. asking for a feature
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Add support for directly toggling the INACTIVE flag in a widget
Version:1.3-feature
Created By:cand
Assigned To:cand
Fix Version:1.3-current (SVN: v10289)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 cand
03:24 Aug 30, 2014
fltk-inactive.patch
1k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#1 cand
03:24 Aug 30, 2014
I'd like to be able to set the INACTIVE flag in a
widget directly, without sending any events no matter what the previous
state was (both activate() and deactivate() send events, call
fl_fix_focus(), etc).

WebkitFLTK needs to be able to change the draw state of dummy widgets
to grayed out and back. Having events sent or focus messed with at that
point is unnecessary, but also causes asserts inside webkit (no events
should happen during painting).

Many of the other flags have set() and clear() functions. Adding such
for inactive would be ABI-safe, and if surrounded by /* for internal
use only */ comments like some other Fl_Widget public functions,
shouldn't confuse users.
 
 
#2 AlbrechtS
03:24 Aug 31, 2014
-1 on the given patch.

I'm clearly against adding methods that have such "consistent"/"obvious" names but do something that should not be done in normal programming. There is always the possibility that someone uses them w/o looking at the docs at all, just because they have the "usual" names.

I would like not to add such functions at all, but with names like (now exaggerating)

  void Fl_Widget::setup_active_dont_use_at_runtime (int active)

where the argument (active) would set (1) /or/ clear (0) the active state my objections would be much smaller.

Reasoning:

(1) there's only /one/ method with a /non-standard/ name so that people wouldn't use it by accident (and ask support questions why their programs behave bad)

(2) using "setup" or "init" within the name would be appropriate. I could imagine to document this as an "allowed" way to set up widgets in their constructors, but not during runtime.

I have some more questions and thoughts about solving the underlying issue, and I'll post these in fltk.coredev (in thread "Ability for Fl_Widget to clear and set the INACTIVE flag directly?") later tonight or tomorrow.
 
 
#3 AlbrechtS
10:26 Sep 07, 2014
After discussions in fltk.coredev I withdraw my general objections, but I propose different method names, as I wrote in fltk.coredev:

"you proposed set_inactive() and clear_inactive(), which sounds somewhat like a double negation. Although the internal flag is called INACTIVE, I would propose to use the "positive" forms set_active() and clear_active() for the API."

My vote is now:

+1 for set_active() and clear_active()

Comments or votes anybody?
 
 
#4 AlbrechtS
10:29 Sep 07, 2014
One more note regarding the names:

set_active()   would be the alternate method of activate(),
clear_active() would be the alternate method of deactivate()
 
 
#5 cand
01:57 Sep 08, 2014
Earlier in the thread Greg and Ian were ok with the general premise, so I've gone ahead with the set_active and clear_active forms as requested by Albrecht.  
     

Return to Bugs & Features ]

 
 

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 'erco@seriss.com'.