nc_834v5010generator - project status - November
2015-11-04
Refactoring and bugfixing CDK_Textfield::injectCDKTextfield(chtype input). Currently working on the key handling (massive switch/case) section.
2015-11-07
Okay. Started the full-blown major refactoring of CDK_Textfield today. Removed the includes for CDK_Mentry. CDK_Textfield refactoring goal will be to make it a 1st class object, not a wrapper of cdk_mentry, and the refactored object will use minimal "pure C" ncurses and minimal "pure C" CDK API calls.
2015-11-08
CDK_Textfield now refactored as a 1st class CDK object. All references to cdk_mentry have been removed. Now there is CDKTEXTFIELD to use when working with the CDK API calls. Source code updated to website.
Next round of refactoring will be to code up placeholder methods, and debug in DDD sessions.
2015-11-14
Added exception handling to CDK_Textfield. Created CDK_bad_alloc exception to be thrown when calls to cdk's newCDKObject(...) return 0. Updated makefile. Uploaded code to the website.
Need to finish coding up CDK_Textfield::initialize(CDKTEXTFIELD * pCdkTextfield).
2015-11-15
Okay. I am actually a bit angry at the designers of the CDK (Curses Development Kit) API. This will be a full-blown rant.
I am creating my own C++ CDK widget, CDK_Textfield, because the CDK widget set available from Debian Stable does not have one.
I assumed, and I think my assumption is, and should be valid in the open source world, that Open Source developers would want to extend an existing API, or create their own custom widgets, and that the API would be designed to support such efforts.
As of the is writing, CDK is designed to lock-in the use of only widgets that are part of CDK. It actively inspects widget's in a list, and blocks use of some API calls if a 'valid' widget was not on the list.
The only recourse someone like myself has, is to:
1. Design a new widget fully with the CDK API,
and get the maintainer to accept the code updates
2. Try to fake out the validator checks
3. Write their own local version of one of the CDK libraries, cdkscreen.h/cdkscreen.c
Here is the offending code, in cdkscreen.c,
*snip*
/*
* $Author: tom $
* $Date: 2008/11/01 14:27:23 $
* $Revision: 1.88 $
*/
*snip*
static boolean validObjType (CDKOBJS *obj, EObjectType type)
{
bool valid = FALSE;
if (obj != 0 && ObjTypeOf (obj) == type)
{
switch (type)
{
case vALPHALIST:
case vBUTTON:
case vBUTTONBOX:
*snip*
case vMENTRY:
case vMENU:
case vRADIO:
case vSCALE:
case vSCROLL:
case vSELECTION:
case vSLIDER:
case vSWINDOW:
case vTEMPLATE:
case vUSCALE:
case vUSLIDER:
case vVIEWER:
valid = TRUE;
break;
case vTRAVERSE: /* not really an object */
case vNULL:
break;
}
}
return valid;
}
I would like to see the CDK API get re-factored. It should, instead of listing each widget to be 'allowed', that an Open Source developer creating their own widgets, have a vVALIDCDKOBJECT they can use.
The idea that CDK wants to be open source, and used, yet not allow people to create their own custom widgets, as a supported default in the API, just seems wrong.
Lastly, I am going to put my Big Boy Pants on, and actually contact tom, with the proposal to update cdkscreen.c to have a vVALIDCDKOBJECT (or some equivalent), to support programmers like me, that want to use the CDK API to make our own custom GUI widgets. (Email sent!)
2015-11-15a
Created rxl_cdkscreen.h and rxl_cdkscreen.cpp, updated makefile. Any functions, enumerations, or such that I need to create custom copies of, I preface with RXL or rxl_, so they will not collide with the original CDK API. Updated source code to website. Making progress. Feeling happy.
2015-11-26
Starting to adjust CDK_Textfield. Need to see how the CDK populates all the CDKMENTRY* pointers that are used as function callbacks, and are populated via newCDKMEntry(...). Doing so by running DDD debugging sessions.
Setting breakpoint in Ncurses834v5010view::displayFileInfoGUI(...), line 783. As I start to see what I will need for CDK_Textfield, then I can make informed adjustments to the structure of CDK_Textfield's my_funcs, as well as rxl_cdkscreen.h and rxl_cdkscreen.cpp