Re: [fltk.development] RFC: Fl_Spinner API additions
I'd like to make a few additions to Fl_Spinner; comments? Fl_Spinner is a group with an Fl_Input and a few buttons; looks like this: _ | | ^ | | input area |---| |_|_v_| In my application, I need to change the color of the input area based on if the value is negative or positive, but it seems I can't because the input area is a private member of the Fl_Group. To do this, I could see a few approaches to modifying the widget: 1) Add a color() method to override the invisible Fl_Group::color(), and have it call the input's color() instead. 2) Make the input and buttons 'protected' instead of 'private' so that one can derive classes from it to access the members directly. 3) Do what other widgets do (like Fl_Scroll) and expose the internal widgets with methods, eg. myspinner-input() myspinner-up_button() myspinner-down_button() ..so that an app can access these directly without deriving a class. My thinking is all three should be done, though perhaps #3 is too much?. #2 breaks ABI, so that would have to be #ifdef'ed. Comments? #1 and #2 sound good (ABI issues aside) - not all that keen on #3, but then I'm not all that keen on it in Fl_Scroll either and it actually works ok... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Fl_Tooltip API additions
Curious if there's any objections to adding the following controls to the Fl_Tooltip API. Would like to be able to have more control over global tooltips: // Set/get the left/right and top/bottom margins for all tooltips // These allow the app to control the margin area around tooltips on X and Y. // Currently these are hard coded to 6 pixels on X and Y. // void Fl_Tooltip::margin_width(int val); int Fl_Tooltip::margin_width() const; void Fl_Tooltip::margin_height(int val); int Fl_Tooltip::margin_height() const; // Set/get the tooltip maximum width //Currently this is hardcoded in Fl_Tooltip to 400. // void Fl_Tooltip::max_width(int val); int Fl_Tooltip::max_width() const; Looking for +/-1 dev votes and/or comments, alternative names, etc. Yes, sure; +1 SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Fl_Spinner API additions
On 15.05.2012 11:53, MacArthur, Ian (SELEX GALILEO, UK) wrote: I'd like to make a few additions to Fl_Spinner; comments? Fl_Spinner is a group with an Fl_Input and a few buttons; looks like this: _ | | ^ | | input area |---| |_|_v_| In my application, I need to change the color of the input area based on if the value is negative or positive, but it seems I can't because the input area is a private member of the Fl_Group. To do this, I could see a few approaches to modifying the widget: 1) Add a color() method to override the invisible Fl_Group::color(), and have it call the input's color() instead. 2) Make the input and buttons 'protected' instead of 'private' so that one can derive classes from it to access the members directly. 3) Do what other widgets do (like Fl_Scroll) and expose the internal widgets with methods, eg. myspinner-input() myspinner-up_button() myspinner-down_button() ..so that an app can access these directly without deriving a class. My thinking is all three should be done, though perhaps #3 is too much?. #2 breaks ABI, so that would have to be #ifdef'ed. Comments? #1 and #2 sound good (ABI issues aside) - not all that keen on #3, but then I'm not all that keen on it in Fl_Scroll either and it actually works ok... Same here, I'd vote to do #1 and #2, but not #3. #3 would make sense if we could also replace the internal widgets with derived classes (as has been discussed recently for scrollbars in Fl_Scroll or similar widgets), but then we'd probably need some more virtual methods in these (base) classes. So I wouldn't do #3, because we can't take back later what we expose now. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] text caret control in Fl_Text_Display
Before I discuss caret behavior.
I have a further related issue (it's all bound up in the same widget).
The Fl_Double_Window does not get keyboard focus by default. You can =
achieve that by returning 1 for FL_FOCUS and FL_UNFOCUS events.
Fl_Input_ and derived widgets and Fl_Text_Display do that for you.=
Apologies and thanks to Matthias for FOCUS:UNFOCUS:return 1 advice.
I had been cutting and splicing and didnt realise its importance.
Nevertheless there is STILL a PROBLEM. Sorry but I have to show
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Text_Display.H
#define USING_CARET
class EventWindow : public Fl_Window
{
private:
Fl_Text_Buffer* mBuff;
Fl_Text_Display* mDisp;
bool mKeyPressed;
unsigned longmKey;
int handle_keydn(int event, int key, int state);
public:
EventWindow();
bool getKey(unsigned long pKey);
int handle(int pEvent);
#ifdef USING_CARET
void showCaret(int pPos);
#endif
};
EventWindow::EventWindow() : Fl_Window(640,480,Display)
{
mBuff = new Fl_Text_Buffer();
mDisp = new Fl_Text_Display(20,20,640-40,480-40);
mDisp-buffer(mBuff); add(*mDisp);
mBuff-text(line 0\nline 1\nline 2\nline 3\nline 4\nline 5\n);
mKeyPressed = false;
mKey = 0;
}
int EventWindow::handle(int pEvent)
{
switch (pEvent) {
case FL_FOCUS: case FL_UNFOCUS: case FL_KEYUP:
return 1;
case FL_KEYBOARD:
return handle_keydn(pEvent,Fl::event_key(),Fl::event_state());
default:
return Fl_Window::handle(pEvent);
};
}
int EventWindow::handle_keydn(int pEvent, int pKey,int pState)
{
printf(KeyDN Key = %d State = %d\n,pKey,pState);fflush(stdout);
mKey = (unsigned long)pState + (unsigned long)pKey;
mKeyPressed = true;
return 1;
}
bool EventWindow::getKey(unsigned long pKey)
{
bool lRet = false;
if (mKeyPressed)
{
switch (mKey)
{
default:
pKey = mKey;
lRet = true;
case 0xFFE3: // left ctrl
case 0xFFE4: // righ ctrl
case 0xFFE9: // left alt
case 0xFFEA: // left alt
case 0xFFE1: // left shift
case 0xFFE2: // righ shift
break;
}
mKeyPressed = false;
mKey = 0;
}
return lRet;
}
#ifdef USING_CARET
void EventWindow::showCaret(int pPos)
{
mDisp-show_cursor(); // ENABLE CURSOR
mDisp-cursor_color(0xFF00); // CURSOR RED
mDisp-cursor_style(Fl_Text_Display::HEAVY_CURSOR);
mDisp-insert_position(pPos); // POSITION
mDisp-take_focus(); // SHOW CARET ON STARTUP (EVEN IF NOT IN FOCUS)
}
#endif
int main()
{
EventWindow* win = new EventWindow();
win-show();
int lPos = 5;
#ifdef USING_CARET
win-showCaret(lPos);
#endif
int lRet = 0;
while (1)
{
lRet = Fl::wait();
unsigned long lKey = 0;
if (win-getKey(lKey))
{
++lPos;
printf( lPos = %d\n,lPos);fflush(stdout);
#ifdef USING_CARET
win-showCaret(lPos);
#endif
}
if (!lRet)
{
break;
}
}
return Fl::run();
}
try commenting out #define USING_CARET
1) trap keys in (Fl_Window/Double_Window) using above etc, WORKS OK (all keys
produce keydown).
2) add Fl_Text_Display to (1) WORKS OK (all keys produce keydown).
3) add caret functionality using Greg's showCaret instructions
DOESN'T WORK (not all keys produce keydown). Is this related to take_focus()?
What is going on ??
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Website suggestion: FLTK Library/Fluid GUI Builder/Forum/Links...
I would like to change the headlines in the current web site a bit. What do you think? Currently, the top bar read FLTK Applications * FLTK Library * Forum * Links * Login I would like to move FLTK Apps out of the top line because there is not much useful in there. Instead, I would like to put FLTK Library in the first place, followed by a tab Fluid GUI Builder. FLTK Library * Fluid GUI Builder * Forum * Links * Login The new link would contain an introduction into Fluid and tutorials, mostly taken from http://www.fltk.org/doc-1.3/fluid.html . Maybe we can add a bunch of videos as well? Fluid is one of the most convincing features of FLTK! The Applications link is not thrown away, but moved one level lower under FLTK Libarary, maybe named Samples Apps. But it would need quite some more beef and some up-to-date apps that compile well on all platforms with the current library (Jenkins to the rescue). It's not much, but maybe a start. - Matthias ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Website suggestion: FLTK Library/Fluid GUI Builder/Forum/Links...
On 15 May 2012, at 21:10, Matthias Melcher wrote: I would like to change the headlines in the current web site a bit. What do you think? Currently, the top bar read FLTK Applications * FLTK Library * Forum * Links * Login I would like to move FLTK Apps out of the top line because there is not much useful in there. Instead, I would like to put FLTK Library in the first place, followed by a tab Fluid GUI Builder. FLTK Library * Fluid GUI Builder * Forum * Links * Login The new link would contain an introduction into Fluid and tutorials, mostly taken from http://www.fltk.org/doc-1.3/fluid.html . Maybe we can add a bunch of videos as well? Fluid is one of the most convincing features of FLTK! The Applications link is not thrown away, but moved one level lower under FLTK Libarary, maybe named Samples Apps. But it would need quite some more beef and some up-to-date apps that compile well on all platforms with the current library (Jenkins to the rescue). It's not much, but maybe a start. Sounds like a good idea. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
