STR #2022: Improve deriving from Fl_Chart - Fast Light Toolkit (FLTK)

STR #2022

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:	Improve deriving from Fl_Chart
Version:	1.4-feature
Created By:	alvin
Assigned To:	AlbrechtS
Fix Version:	1.4.0
Fix Commit:	dde2d21b5d2f066c616593dc8d51c89eba239b3d
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	alvin 07:40 Sep 22, 2008

str2022-v2.patch
3k

#2	alvin 07:50 Oct 14, 2008

str2022-v3.patch
3k

Trouble Report Comments:

#1	alvin 04:53 Aug 15, 2008

Hello, As written, it is not very easy (if at all possible) to derive a widget from Fl_Chart. All members (variables and functions) of Fl_Chart are either designated as private or appear statically in Fl_Chart.cxx. I propose that some very slight modifications be made to Fl_Chart. These are: 1. The protected designation be moved to the top of the Fl_Chart class specification in Fl_Chart.H 2. The static draw_xxxx() functions in Fl_Chart.cxx be made static members of Fl_Chart. I believe with those two changes, it would be possible to derive new charting widgets from Fl_Chart. I will submit a patch shortly.

#2	alvin 07:40 Sep 22, 2008

Oops, it appears I forgot to upload the patch! I have posted a patch that applies cleanly to 1.1.x-r6305.

#3	alvin 07:51 Oct 14, 2008

I have updated the patch (str2022-v3.patch) to apply cleanly against 1.3 r6427.

#4	fabien 08:17 Oct 14, 2008

Hi Alvin, Well it is not a slight modification at all :-) As an example, you would like get/set attribute protected instead of private, but you have the corresponding methods to use those attributes from derived classes so it is useless and will shows more internals for nothing ... I would like to help, but need to know what exactly is your need. As for now there is too much modifications IHMO. Private attributes are important as they allow more flexibility without putting in danger the backward compatibility issues when improving the current impl., generally it is a good practice to use them for hiding Abstract Data Types impl. choices that may change in future (i.e: you use a static table in version 1, in version 2 you replace it by a list, but you don't expose these internals to your users so that they don't rely on them ... Fabien

#5	alvin 18:59 Oct 14, 2008

The idea behind the patch is to make it possible to derive from Fl_Chart. When I was looking for a simple charting widget, I came across Fl_Chart. I like Fl_Chart and just wanted to draw a combination of bars and lines, draw the parts on the right side, etc. I see now that there are indeed public methods for accessing each private member of Fl_Chart. So, that part of the patch needs to be removed. However, if you look at Fl_Chart.cxx, all the actual drawing functions are static function in the .cxx file. This makes it impossible for derived classes of Fl_Chart to reuse those methods. For example, say I wanted to create a bar graph with the bars extending downward from the top of the widget. With Fl_Chart.cxx as is, I would have to copy the methods into my files or reimplement them. This is a bad example, I know. Another example, would be of a chart widget that displays several data sets at the same time: bars for one set, a line for the 2nd set, etc. The second part of the patch moves those static function from the scope of the .cxx file into the Fl_Chart as protected static methods. Basically, the functions themselves are untouched, only their scope is changed.

#6	AlbrechtS 14:59 Jan 15, 2023

Fixed in Git repository. Sorry, it took a while ;-) ... but now it has been committed to the Git repository in commit dde2d21b5d2f066c616593dc8d51c89eba239b3d. This commit makes the local, static functions static methods of class Fl_Chart as requested but I'm still investigating some changes before FLTK 1.4.0 gets released. For my plans please read the git commit log (partly copied here for reference): Todo: - investigate whether these drawing methods wouldn't better be member functions and "convert" them if applicable - investigate whether the internal struct FL_CHART_ENTRY could become a local part of the Fl_Chart class, maybe Fl_Chart::Entry. - rename private member variables with trailing underscore (see CMP) I'm closing this STR now. If there are questions or if I missed something, please ask in fltk.coredev so I can either reopen the STR or we can discuss how to proceed.