Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
On 14 Apr 2013, at 13:57, Duncan Gibson wrote: I have an application with a colour bar type legend which does not give the required resolution, so I needed to be able to adjust the low and high values in an intuitive but minimally invasive way on screen. I hacked together the following demonstrator, drawing some inspiration from Fl_Slider. The features I required were: - a vertical slider - possibility of setting min and max values of continuous range (no step) - possibility to move low and high sliders (min = low high = max) I then hacked it further to fit directly with the rest of my application. Questions: 1. Does anybody know of a similar widget out there? 2. Is it worth factoring out a separate DoubleValuator base class? 3. Apart from vertical/horizontal what other features are needed? 4. Does it require min/low/high/max fields? 5. Would a floating tooltip with feedback be enough? (eg Greg's TipWin) I'd be willing to have a go a this, but can't provide any timeframes. Coming to this party late, but I just remembered that Jason Bryan's FLU widgets have a double-slider widget. His pages at OSC.edu appear to be gone but the mirror here still seems to be working: http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/ His FLU_Dual_Slider might be relevant, to see how what he did compares. He derived a pile of new fltk based widgets, so there may be clues in that work for a template for future derivations? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Fl_tile: don't shrink, just shift
On 20 Apr 2013, at 22:04, dirac wrote: I'm building a stack of horizontal widgets, like that (I hope the ASCII art works): +---Fl_tile---+ | +-+ | | | widget 0| | | +-+ | | +-+ | | | widget 1| | | +-+ | | +-+ | | | widget 2| | | +-+ | |++ I would like to make each widget vertically resizable, so an Fl_tile seems a good choice for a container. Though I suspect that initial reaction may be misleading... Unfortunately I've noticed that Fl_tile shrinks the other widgets: for example if I enlarge Widget 0 completely to the very bottom, widget 1 and widget 2 disappear, i.e. their height becomes zero. Yup, the issue here is (I think) that Fl_Tile, like many container widgets, is striving to maintain a fixed outer dimension, so as widget 1 grows, the other widgets in the container need to shrink... I guess that what you want is a container widget that will grow/shrink as it's children grow/shrink. And that's not quite the same thing as an Fl_Tile. My question: is there a way to extend Fl_tile so that it shifts the other widgets below Widget 0, instead of shrink them? Possibly Fl_tile should also expand itself vertically to make room for the other widgets. Yes, though Fl_Tile may be the wrong place to start. I'd probably just start form an Fl_Group then modify the resize behaviour to match the changing sizes of the groups children... Hmm, now, I seem to recall that Jason Bryan's FLU widget extensions for fltk had something like that - they would be worth a look. OK; his pages at OSC.edu appear to be down, but there's a mirror here that still seems to work: http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/ Maybe his collapsible group widget might give you some starting hints? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [MOD] STR #2935: Fl_File_Browser::load() improvements for Unix
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2935 Version: 1.3-current Fix Version: 1.3-current (r9884) STR 2935 applied in svn. Thanks to Michael Baeuerle for the patch. Link: http://www.fltk.org/str.php?L2935 Version: 1.3-current Fix Version: 1.3-current (r9884) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] fluid - Adding win32 icon
On 16 Apr 2013, at 19:03, Greg Ercolano wrote: So I imagine most folks would be managing the resource files by hand now, I honestly don't know: I've been using the mingw tools in preference to the MS tools for so long now, that I'm not sure what would be deemed normal any more! I know that I manage the .rc files by hand, and use the mingw resource compiler, but have no ide what the equivalent MS tools would be... so perhaps the simpler they are, the better. Could not agree more. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] [FLTK 1.3] FilesystemlistinFl_File_Browser(STR#2935)
On 16 Apr 2013, at 23:03, Michael Baeuerle wrote: MacArthur, Ian (Selex ES, UK) wrote: OK - pushed at #9884 I have checked out and tested the final version from SVN again on all relevant platforms and it still works as expected. Excellent: thanks for checking! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 17:53, David FLEURY wrote: Le 25/03/2013 22:07, David FLEURY a écrit : I found an easy tool (VarilconsRevolve) Here a new patch. I remove all unnecessary lines from the rc file and fluid_resource.h I just remove cygwin (I have no cygwin installed, I can't not test). I have to 2 more icons on the fluid.ico file (48*48 and 64*64) so its not so big. Not sure I can do better. Hi, I reactivate this, just to known if I had to keep it somewhere on my repo to patch my fltk, or something like this will be apply in the official repo. Is there an STR for this somewhere? I can't find it... so I can't find the patch. Anyway: what sizes are in the icon file now? We need to be sure there are enough sizes to cover the range expected by XP through Win7 (and I suppose Win8, though I don't know what sizes it likes; I assume same as Win7?) As fas as the patch goes, I imagine the only material change to the code is to add a #ifdef to load the icon, e.g. as is done on the sudoku example in the test folder? That is certainly what I do in my own code, at any rate. Regarding changes to the Makefile, I'm only likely to use the mingw tools any time soon, so if a suitable icon is available I can adjust fluid's Makefile to do the resource compilation and so forth for the mingw (and hence probably cygwin too...) builds. Again, that'll largely be a matter of cloning the suduko build target really...! Which reminds me... whilst we are on the subject of Windows icons; we really need to look at #2816 again and get that merged, as it would be useful... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 21:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ah. That's gong to make it very hard for us to view and comment on it, then. I think the best thing would be to create an STR and post the icon and your patches there, for folk to take a look at. Anyway: what sizes are in the icon file now? 32k The icon file is 32k bytes now? That seems OK, maybe a bit larger than I'd have expected... OK, just checked, and the icon I've been using for my app is 29k, but it has sizes from 16x16 up to 256x256 in it. I have added a 64*64 and a 48*48 icons So, it has 16x16 32x32 48x48 and 64x64 then, is that right? My understanding is that, for Win7 at least, we'd really want a 128x128 as well, possibly even a 256x256 just in case! Is the image you are using for the icon very complex? I'm a bit puzzled why the icon is bigger than mine when it does not have as many sizes in it...? We need to be sure there are enough sizes to cover the range expected by XP through Win7 (and I suppose Win8, though I don't know what sizes it likes; I assume same as Win7?) I have tested it against win8. The icon look fine (64*64) not succeeded to put a bigger one (size increase to much too) Yup, that seems odd. WOnder why it seems to be so big... As fas as the patch goes, I imagine the only material change to the code is to add a #ifdef to load the icon, e.g. as is done on the sudoku example in the test folder? Yes exactly That is certainly what I do in my own code, at any rate. Regarding changes to the Makefile, I'm only likely to use the mingw tools any time soon, so if a suitable icon is available I can adjust fluid's Makefile to do the resource compilation and so forth for the mingw (and hence probably cygwin too...) builds. Again, that'll largely be a matter of cloning the suduko build target really...! I have no mingw installed. I have excluded mingw for this patch since I cannot test it. If you post what you have to an STR, we can certainly look at making it work for mingw too... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 22:13, Greg Ercolano wrote: On 04/15/13 13:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ian; he included the patch here on fltk.dev at the head of this thread. Oh, OK. I had the sense, from what he was saying, that there were changes to the patch - David and I discussed this patch a few days back, and I think he was tweaking things about, so I wanted to see where we have got to. I also wanted to take a peak at the icon, so I thought that posting all the bits to an STR would be the easiest option. Also, would make it easy for others to pitch in... Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widgetthat returns its top-level window
On 12 Apr 2013, at 18:44, Albrecht Schlosser wrote: Using const_cast is only another way to write it, but means the same essentially, doesn't it? However, if some compilers wouldn't flag a warning for const_cast but would for the old-style cast, then we could maybe use it, but according to the CMP this shouldn't be used for fltk 1.1 code, however it should be used for 2.0 code. 1.3 code is not (yet) specified, so we'd have to make a decision about this first. I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method toFl_Widgetthat returns its top-level window
On 13 Apr 2013, at 00:07, Greg Ercolano wrote: On 04/12/13 13:19, Ian MacArthur wrote: I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? The static_cast mod flew in all my tests on redhat9 and irix6.5, and those are as old as the friggin hills. You say static_cast here? Would we not be wanting const_cast in this case...? Or am I missing something obvious again? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Caps Lock detection
On 11 Apr 2013, at 18:34, Greg Ercolano wrote:
I guess we should see how Win32 and OSX behave, and if they're
reliable
as well, we should either:
1) Document the OS specific behavior, whether different or same,
and leave the code alone
2) Pick one behavior, and modify the code to enforce it, and
document it
Can. Of. Worms.
Attached below, my take on this. It's messy...
However, the code given returns the correct state on OSX 10.6.8,
Linux-in-a-VM, and WinXP.
What I find (at least on my systems...)
- On Linux, ONLY look at the FL_KEYDOWN events
- On WIN32, ONLY look at the FL_KEYUP events (and the sense is maybe inverted
wrt the linux case)
- On OSX, I need to process both up and down events, because it looks (and I
may be really losing the plot here) as if I only get keydown events when the
Caps Lock is going on, and I only get keyrelease events if the Caps Lock is
going off...
So... The code works, but it is not nice:
--
//
// FLTK CAPSLOCK TEST
// compile: fltk-config --compile test-capslock-fltk.cxx
//
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
static Fl_Box *state_box = 0;
static unsigned updn = 0;
static unsigned updn_old = 0;
static void change_state_box(void) {
if(updn != updn_old) {
updn_old = updn;
if(updn) {
state_box-color(FL_RED);
state_box-label(ON);
}
else {
state_box-color(FL_BLACK);
state_box-label(OFF);
}
state_box-redraw();
}
} // change_state_box
class MyWindow : public Fl_Window {
public:
MyWindow(int W,int H) : Fl_Window(W,H) { }
int handle(int e) {
switch (e) {
case FL_KEYUP:
#ifdef __APPLE__
if ((Fl::event_state() FL_CAPS_LOCK) != 0) {
updn = 999;
}
else {
updn = 0;
}
change_state_box();
#endif // __APPLE__
#ifdef WIN32
if ((Fl::event_state() FL_CAPS_LOCK) != 0) {
updn = 0;
}
else {
updn = 999;
}
change_state_box();
#endif // WIN32
break;
case FL_KEYDOWN:
#ifndef WIN32
if ((Fl::event_state() FL_CAPS_LOCK) != 0) {
updn = 999;
}
else {
updn = 0;
}
change_state_box();
#endif // !WIN32
break;
default:
break;
}
return(Fl_Window::handle(e));
} // handle
};
static MyWindow *win = 0;
int main(int argc, char **argv) {
win = new MyWindow(500,500);
win-begin();
state_box = new Fl_Box(10, 10, 80, 40, OFF);
state_box-color(FL_BLACK);
state_box-box(FL_FLAT_BOX);
state_box-labelcolor(FL_WHITE);
win-end();
win-show(argc, argv);
return Fl::run();
} // main
// end of file
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 10 Apr 2013, at 17:25, Howard Rubin wrote: I don't agree. Most login screens warn immediately if capslock is on because their password fields don't echo input. Though it does appear that, at least if there is any prospect that your users will be running Linux in a VBox VM, that we may have to embrace the possibility that the very best we can do is detect the Caps Lock state when the user starts typing - reliably detecting Caps Lock otherwise seems... fraught... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Dynamic linking with fltk 1.3 ?
On 9 Apr 2013, at 17:34, Nikita Zlobin wrote: Hello. I determined, that fltk 1.1 by default proposes shared versions of its libraries, when 1.3 - static. All fltk variants will support either dynamic or static linking. The default in the configure scripts is static linking, but if you configure the fltk libs with the --enable-shared option set, then the dynamic libs will be generated (and used in preference to the static libs, though they will also be created of course.) I noticed, that fltk has own cmake files in /usr/lib/fltk directory. The Cmake files are not actively maintained - I do not think any of the core dev team actually uses Cmake much, if at all. That said, I am led to believe that others have used them with success, so if you want ot go ahaed with them they can probably work for you. Tried to look into them, but probably i need to learn cmake better. Yes, probably - and if you get them working, we accept patches...! All i could understand is that in 1.3 FLTKLibraries.cmake adds (not sure, what is destination, may be some priority list?) first static, than dynamic libraries. Is it complete at all? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 9 Apr 2013, at 20:18, Howard Rubin wrote: On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote: unsigned n; XkbGetIndicatorState(d, XkbUseCoreKbd, n); caps_state = (n 0x01) == 1; That works perfectly, and even better, needs no timer. Test program below. Hmm - might need to be careful though: didn't really work reliably for me, at least not in a F17 VM. I'm entirely prepared to believe that the VM is exacerbating the problem, of course, but it does suggest that this might not be a 100% reliable fix, or that at least some users will get caught out... Maybe... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 9 Apr 2013, at 22:02, Greg Ercolano wrote: On 04/09/13 12:29, Greg Ercolano wrote: we could perhaps provide a wrapper to get the state of the keyboard LEDs (for operating systems that provide this) e.g. fl_get_indicators() or some such that returns flags. Maybe fl_get_keyboard_leds() and fl_set_keyboard_leds() would be better. There might be some resistance to adding this though, since FLTK is primarily a GUI toolkit trying to stay light on its API, its intention to abstract GUI related features, and not abstract all features of the window manager. Guess I'd be curious what other devs have to say. I'm not opposed per se, though I do woory about clutter... However, as I said to Howard earlier; for me, on F17 (and now also Ubuntu 12.10) I find that it doesn't actually work, with the linux image in a VirtualBox VM. I *assume* this is some VM weirdness, but am not sure... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewherearranged
Yep, this was suggested as a workaround only, either to see how it
can be done (just for learning), or if one really wants to use
Fl_Pack. Deriving from Fl_Pack (as I assume you meant above) for
another container widget and do the polling makes things even worse,
but I assume that you only wrote it for the same reasons as I did.
Yes, indeed.
I think the better thing is to make your own container based on Fl_Group, since
that gives more control over how the packed widgets will finally be drawn
anyway...
Also, more or less as an aside, I think your (Albrecht's) analysis of how
Fl_Pack is causing this issue is correct - since I was already poking at
marty's code, I tweaked it to use a timer as you had suggested (only for the
purposes of experiment of course!) and the code now works as expecetd...
--
// marty - button add example
#include iostream
#include string
#include cstdio
#include cstdlib
#include FL/Fl.H
#include FL/Fl_Box.H
#include FL/Fl_Menu_Button.H
#include FL/Fl_Menu_Item.H
#include FL/Fl_Pack.H
#include FL/Fl_Window.H
using std::cout;
using std::endl;
using std::string;
static Fl_Pack* G1;
static Fl_Window* WIN;
static int idx = 0;
static Fl_Color LBG = FL_DARK_BLUE;
static Fl_Color LFG = FL_WHITE;
static Fl_Color LSC = FL_BLUE;;
static Fl_Color LTC = FL_WHITE;
static Fl_Font LFONT = (FL_HELVETICA | FL_BOLD);
static Fl_Fontsize FSIZE = 20;
static int LSPC = 5;
enum eop { DEL=-1, ADD=1 };
class Sbut : public Fl_Menu_Button
{
public:
Sbut (int i);
static void onButton ( Fl_Widget* w, void* v);
int handle ( int event );
int i() { return _i; }
int _i;
};
//
void clearTo ( int idx )
{
cout clearto idx : ;
Fl_Widget* w;
int last = G1-children()-1;
if ( last idx )
cout removing ;
{
// remove last to idx
for ( int i=last; i-1; i-- )
{
if ( i != idx )
{
cout i ;
w = G1-child(i);
G1-remove(w);
delete w;
}
}
}
WIN-redraw();
cout endl;
}
//
static void pop_on_timeout(void *v)
{
Sbut* sb = (Sbut*)v;
WIN-redraw();
cout pop_on_timeout: popping menu endl;
sb-popup();
}
//
void onMenu (Fl_Widget* w, void* v)
{
eop op = (eop)fl_intptr_t(v);
Sbut* sb;
if ( op == ADD )
{
cout onMenu: add endl;
sb = new Sbut(idx);
G1-add(sb);
idx++;
Fl::add_timeout(0.2, pop_on_timeout, (void*)sb);
}
else if ( op == DEL )
{
cout onMenu 2: deleting endl;
int i = G1-find(w);
clearTo(i);
sb = (Sbut*)G1-child(0);
Fl::add_timeout(0.2, pop_on_timeout, (void*)sb);
}
}
//m
Fl_Menu_Item xMenu[] = {
{add button to end, and popup menu, 0, onMenu, (void*)ADD},
{delete other buttons, and popup menu, 0, onMenu, (void*)DEL},
{0}
};
//cc
Sbut::Sbut (int id )
: Fl_Menu_Button( 0, 0, 100, 50)
{
//cout Sbut(s) 0: id endl;
_i = idx;
callback(onButton);
char _cstr[16];
sprintf(_cstr, %i, id);
copy_label(_cstr);
//cout label = label() endl;
color( LBG, LSC);
labelcolor(LFG);
labelfont(LFONT);
labelsize(FSIZE);
menu(xMenu);
if ( menu() )
{
Fl_Menu_Item* mi; // non-const pointer
mi = (Fl_Menu_Item*)menu();
int sz = mi-size();
for ( int j=0; jsz; j++ )
{
// cout set: j endl;
color(LBG, LSC);
mi-labelsize(FSIZE);
mi-labelfont(LFONT);
mi-labelcolor(LFG);
mi = mi-next();
}
}
}
//hH
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
{
cout Sbut handle 1: PUSH endl;
do_callback();
return 1;
}
return 0;
}
//hH
void Sbut::onButton ( Fl_Widget* w, void* v)
{
int i = G1-find(w);
cout Sbut onButton 0: i endl;
Sbut* sb = (Sbut*)w;
sb-popup();
}
//***
int main (int argc, char **argv)
{
Sbut* sb;
WIN = new Fl_Window(0, 0, 200, 300);
G1 = new Fl_Pack(0, 0, 150, 150);
G1-begin();
for ( int i=0; i5; i++ )
{
sb = new Sbut(i);
idx++;
}
G1-end();
WIN-end();
//WIN-resizable(G1);
WIN-resizable(WIN);
WIN-show(argc, argv);
return Fl::run();
}
/* end of file */
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2945: Virus is detected when being compiled in MSVS 2010
Actually, I suspect it is more likely to be a false positive than anything else.At various times in the past I have had AVG, Norton or McAfee all throw warnings when configure was running; and not just on fltk builds but on other packages too.I suspect that the AV authors aren't particularly focussed on the developer community and there may be things configure does that look suspect if viewed in a general context...That said, I'm not sure any of that's pertinent to the OP's case, where I can't imagine configure is involved at all...!-- IanSent, much to my surprise, from my Palm Pre3On 6 Apr 2013 14:51, Greg Ercolano e...@seriss.com wrote: DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature Have you ruled out this might be a problem with your own machine? Have you had problems with viruses recently? (ie. if you have an out of data java interpreter, etc. that is causing binaries that link against possibly corrupt libraries on your machine to, by extension, appear to be corrupt themselves?) Have you ruled out building code from other toolkits causes the same problem, eg. try building wxwidgets or the opengl demos. Is there a pattern in the files Avira is detecting, such as all the opengl oriented demos? (CubeViewd.exe is a debug build of an opengl oriented app) Please include a list of all files it detected, as there may be a pattern in the files it detects, ie. all the opengl oriented applications, or the opengl debug libraries. (You mentioned cubeviewd, which uses opengl) If there is a pattern, it's possible the problem is a corrupt library on your machine (eg. opengl related) that is getting linked into the executables causing the problem. Let's rule all that out first. Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2945: Virus is detected when being compiled in MSVS 2010
Oh, and it's probably worth saying that I've run a variety of virus scanners over my current stock of fltk builds, with no warnings flagged.That said, I can't reproduce the OP's environment since I have neither VS2010 nor Avira readily to hand.Does look a lot like a false positive... Or maybe the OP's machine is compromised?-- IanSent, much to my surprise, from my Palm Pre3On 6 Apr 2013 14:07, faywong philip584...@gmail.com wrote: DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature Operate Environment: Windows 7 SP1 32bit, MSVS 2010, Avira Free Anti-virus 2013 Actual Steps: 1) import/open the projects for MSVS 2010, and compile them totally 2) when compile is in progress, the Avira starts to complain and request me to delete several files generated from FLTK's source code And I will take one as an example: in file: C:\Users\faywong\Downloads\fltk-1.3.2\test\CubeViewd.exe found a virus: TR/Crypt.XPACK.Gen2 Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] fltk3 compile error
dXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLgoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= Thanks for the reply but would you mind translating it? It's unreadable. Marty Sigh... Sorry about that, I thought that was fixed... Technically, it's not unreadable, it's just Base-64 encoded... Anyway; here's what it was meant to say (I hope!); marty moore said: Hi all, I get the following error when trying to compile fltk3: $make === making src === Compiling fltk3png/png.c... fltk3png/png.c:14:21: error: pngpriv.h: No such file or directory fltk3png/png.c:17: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âYour_png_h_is_not_version_1_5_10â fltk3png/png.c:559: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âPNGAPIâ fltk3png/png.c:649: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âPNGAPIâ fltk3png/png.c:680: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âPNGAPIâ fltk3png/png.c:687: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âPNGAPIâ fltk3png/png.c:695: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âPNGAPIâ fltk3png/png.c:762: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âPNGAPIâ make[1]: *** [fltk3png/png.o] Error 1 make: *** [all] Error 1 marty@fltk-3.0.x-r9831$ I'm running debian 6.5, emacs 23, and gcc 4.4.5-1. libpng3 and libpng12-0 are installed. Anyone have any ideas?? Yes: note that fltk3 is still alpha, and is intended for experiments only at this stage, so has a few rough edges. What you are hitting is STR #2833 http://www.fltk.org/str.php?L2833 In summary, there is a bug in fltk3's configure mechanism such that it attempts to build fltk's built-in PNG lib version, even if there is a system wide one available. (The earlier fltk variants only compile the built-in PNG lib if there is no system-wide one found...) However, when building the built-in PNG, the system PNG headers get found first, and they are *not* compatible (too old), and Bad Things ensue. If you can be bothered, tweaking the paths in makeinclude so that the correct set of PNG headers are found when building the local built-in PNG lib will fix this. Or, you could try configuring with --enable-local-png as I think that might help... Or, you could update your system PNG to something recent, and that should help to! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] best way to get an int from Fl_Menu_Item user data
Assuming this is readable this time... (and not more B64 nonsense...)
I'm looking at storing an enum as user data in an Fl_Menu_Item user
data. In the callback, I want to access the enum.
I know that I can put the enum into user data as a string:
enum eop { task0=200, task2, task3};
Fl_Menu_Item menu = {
{ thing 1, 0, mycallback, (void*)201} }
void mycallback(widget* w, void* v)
{
eop e = (eop) (atoi((char*)v));
...
}
What is it you are trying to do here?
Pass a numeric value into the callback in the userdata, I think; but you are
doing it by passing a string than calling atoi() on it...
but that seems a little cumbersome and inflexable.
Indeed.
Worked example below.
I notice that old examples used
int i = (int)v;
but that won't work with gcc-4.4.5
Huh? Should do.
We might need to see your code.
Just tested with gcc 4.7.2 and that works fine...
Will fltk-3 provide more flexibility?
No, it is the same.
For now, fltk-1.3 is the recommended build, it is stable. Fltk3 less so...
//
// fltk-config --compile menu-userdata.cxx
//
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Menu_Bar.H
#include stdio.h
static Fl_Double_Window *main_win=(Fl_Double_Window *)0;
static Fl_Menu_Bar *menu_bar=(Fl_Menu_Bar *)0;
enum eop { task0=200, task2, task3};
static void cb_item1(Fl_Menu_*, void *v) {
int i = (int)v;
printf(Menu got %d\n, i);
fflush(stdout);
}
Fl_Menu_Item menu_menu_bar[] = {
{A Menu, 0, 0, 0, 64, FL_NORMAL_LABEL, 0, 14, 0},
{Item 1, 0, (Fl_Callback*)cb_item1, (void *)task0, 0, FL_NORMAL_LABEL, 0,
14, 0},
{Item 2, 0, (Fl_Callback*)cb_item1, (void *)task2, 0, FL_NORMAL_LABEL, 0,
14, 0},
{0,0,0,0,0,0,0,0,0},
{0,0,0,0,0,0,0,0,0}
};
int main(int argc, char **argv) {
{ main_win = new Fl_Double_Window(356, 231, Test Window);
{ menu_bar = new Fl_Menu_Bar(0, 0, 356, 20);
menu_bar-menu(menu_menu_bar);
} // Fl_Menu_Bar* menu_bar
main_win-end();
} // Fl_Double_Window* main_win
main_win-show(argc, argv);
return Fl::run();
}
/ end of file ///
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] best way to get an int from Fl_Menu_Item user data
On 3 Apr 2013, at 17:34, Greg Ercolano wrote: On 04/03/13 08:44, marty moore wrote: I notice that old examples used int i = (int)v; but that won't work with gcc-4.4.5 Right -- probably a precision loss error during the void* - int, since sizeof(void*)==8 and sizeof(int)==4. I think the best approach (in 1.3.x) is to use the new fl_intptr_t, e.g. int i = fl_intptr_t(v); Or, you could just use a long instead of an int, but that might cause trouble on non-64bit builds.. which is I think what fl_intptr_t tries to solve. (See the definition in FL/Fl_Widget.H) Ah: right... Yes, I probably have -fpermissive set in my build environment anyway, so don't see this... I think something based around intptr_t (or fl_intptr_t) is the way to go, since on any host system, regardless of word size, that is guaranteed to provide an integral type that is large enough to hold a pointer... Probably intptr_t would work just about everywhere nowadays I'd guess, since C99 (and is it in C++11 too?) is pretty widely supported now. But the definition for fl_intptr_t should work *everywhere* so it is probably the most portable option. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] best way to get an int from Fl_Menu_Item user data
On 3 Apr 2013, at 19:38, Richard Sanders wrote: When I first compiled with 64 bit linux the compiler complained about int i = (int)(v); but was happy with long i = (long)(v); Greg's suggestion of using fl_intptr_t seems like the most portable option, should work *everywhere* I think! Both Linux and mingw 32 bit are happy with the change to long from int. Mingw64 is another fish. AFAIK pointers in win64 are 64 bit pointers and the compiler issues errors. The work around for that is to use the compiler switch fpermissive, then only warnings are issued. The *nix's (and VxWorks, others...) went from being ILP32, to being LP64, so in both those cases sizeof(long) == sizeof(ptr), but in the 64 bit cases sizeof(int) != sizeof(ptr). However, in an attempt to preserve as much as possible of their API, MS decided to go from ILP32 to LLP64/IL32, so that in Win64 code sizeof(long) != sizeof(ptr), you need to use sizeof(long long) == sizeof(ptr) Or... use intptr_t, since sizeof(intptr_t) == sizeof(ptr) everywhere... And of course sizeof(fl_intptr_t) == sizeof(ptr) everywhere too! Now in all cases long works so the same code covers all bets. Still think fl_intptr_t is the more portable solution long term. Don't know about macs though. A Mac is just a *nix box these days... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature This may be possible, but I didn't do it (thinking about it was making my head hurt...) I guess the idea is to use the typographical height of the folded string, which will take into account the vertical leading between rows of text and so forth; but tailor that to take account of the inked height of the first and last rows... Or something... In any case, I think we'd maybe want to make that a distinct function from fl_text_extents() if we did that ? I also wonder about (somehow) handling fltk @ symbol expansion and so forth in the improved mechanism. If we go that way... Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): supportmultiplelines
On 27 Mar 2013, at 20:16, chris wrote: Ah, I think I understand the difference now, will have a look at the test tomorrow... Though at now cannot imagine a use case for knowing the inking area. Ah, but it turns out that there are quite a lot of uses for knowing the inked area of a typographical element. Not so much for rendering strings of text though; in that case fl_measure if usually the right thing. But if you are rendering text for other purposes, it is often beneficial to know what the actual extents are, since they are usually smaller, some times much smaller, than the sizes reported by fl_measure. Even using fonts decoratively, it is useful to know the extents... For my own part, for example, I often use fl_text_extents to measure glyphs from musical fonts, to ensure that they are positioned on the staff accurately, and suitably sized. The values returned by fl_measure are pretty well useless for this purpose. So, maybe not all that everyday a use case for most folks, I guess, but a real one nonetheless! Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature Yes, I thought about that at the time, but chose not to do it. The problem is, it is not obvious what the right answer is, for a string that has carriage returns / line feeds in it. In particular; What is the resulting vertical height? It will presumably *not* be the sum of the vertical heights of the constituent sub-strings, since that will not account for the vertical leading between the rows of text - assuming the rows are rendered by the host system's regular text drawing mechanism. So, for multi-line text, you probably *need* to render each line yourself, if you care about the inked extent, so that you can directly control the vertical leading between rows. Or, use fl_measure and accept that it will return a bounding box that is larger than the inked extent... I suspect that in the case of multi-line text that fl_measure will usually be more useful anyway. Hmm, now I think about it, I'm not even sure I know what the various different host text systems do with measuring the extents of wrapped text... It is even possible that *some* of them might even get this right, i.e. return a bounding box that describes the inked extents, incorporating the vertical leading. But I do not know for sure, and certainly some of the text systems Do Not get this right, so... It's tricky. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] docking windows
On 21 Mar 2013, at 13:12, asif saeed wrote: Hi, I have turned to FLTK after a very long time. Almost a new user. I just wanna know if you have support available for docking windows? Or do you have to make do it in order to achieve it? There's no built-in support, though there are a few worked examples in the links pages. Mine is here, FWIW: http://www.fltk.org/links.php?V326+Q Though I don't actually use that code much myself; I really wrote it in answer to a forum question. The code worked fine, but may be subject to bit rot as it is a few years old now (i.e. 5 or 6 I guess... It was a while ago!) though I don't think it did anything unusual, so probably works fine still! Hmm, I just noticed that the links on that page link through to a ISP I no lnger have an account with: oh well, still seem to be working though! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
On 16 Mar 2013, at 02:21, Chris Russ wrote: I've been working on a widget that can show images zoomed in and out at arbitrary percentages, and that part works. Now, in the middle of my ::draw() function I want to overlay some RGBA PNG images -- these have transparency where I'd like the underlying image to show up. I can make the images show up in the right places, but the alpha channel is being completely ignored in this little snippet: void *baseaddr = (void *)(head-image_-data()[0]); int imagew = head-image_-w(); int imageh = head-image_-h(); int imaged = head-image_-d(); fl_draw_image((const uchar *)baseaddr, x, y, imagew, imageh, imaged); head-image_ in this case was an Fl_PNG_Image that should have 4 channels. It has been cast into an Fl_RGB_Image, which should be a compatible type. But alpha blending isn't happening. I'm getting white where there should be transparency to the pixels previously drawn in the buffer. Instead, I should be getting a blend using the variable opacity in the A channel. Hi Chris, I think this pretty much ought to work, at least with fltk-1.3.x. What version are you using? Anyway, take a look at the unittests demo from the test folder,one of the tabs there is about image blending and such (IIRC the tab is titled drawing images. Does that work on your system? ISTR it maybe only works on W32 and OSX, not sure about X11... Anyway, the code for that tab is in the file unittest_images.cxx, so that might yeild some clues! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
Correction: I hinted that the unittest_images demo did not work right on X11, but I just fired up a VM to check and it worked fine for me (Ubuntu-12.10 VM) with fltk-1.3.x-r9835 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
On 16 Mar 2013, at 06:28, memoryl...@tin.it wrote:
Now a plant is smaller and has only two stations: the remote machine will put
some visible booleans to zero... and the graphics app
will show only the installed stations.
So one can think: I create a group with image, bargraph, boxes and it's done.
I can't do this, because my app has to be general: it's the plant installer
who knows how the plant is made.
He will create the configuration file for my app (we created a Windows
software for this), specifying where (x, y) and how big the objects are.
I *think* what I'd do is create a group (probably with a FLAT_BOX type) that
contained just the required widgets - I'd populate this at runtime with widgets
as required based on reading the config file.
The redraw would then be sent to the group, hopefully that would work...!
With judicious use of groups, you can possibly arrange for some of the widgets
to be in another group to reduce the redrawing somewhat...
What sort of update rate are you looking for?
If the rate is slow, then redrawing the whole lot, in a double_buffered window,
will be smooth and relatively painless.
Will depend on how powerful your device is of course, but if it is plant
control, then animating at a few Hz may be fast enough, without taking too much
resource away from other tasks? Humans can't actually respond to inputs much
faster anyway, so refreshing at more than a 2 or 3 FPS is just wasting cycles -
we are not making a movie or a video game here, so we don't need 60 FPS to make
things work!
Coming back to the problem: instead of redrawing all the bargraph parent,
IMHO the key point could be the ability to invalidate only one small
portion of the parent,
the rectangular portion under the bargraph.
Bargraph::RedrawObject()
{
parent()-invalidateRect(xBar, yBar, wBar, hBar);
redraw();
}
First instruction tells the parent to redraw only the part under the
bargraph, and the second redraws the bargraph.
Obviously this is general: all objects needing some sort of transparency
should behave this way.
You can manage this by controlling the damage regions for your widgets - but
you still need to do the redrawing of the damaged regions yourself, the toolkit
will not do it for you...
If the update rate is low, it is probably not worth the extra effort - just
redrawing the lot will be simpler!
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Re: R: Bargraph object with Fl_Group
On 15 Mar 2013, at 15:02, memoryl...@tin.it wrote: In general I do not know what there will be under my bargraph : maybe a picture, maybe a filled background. The situation is more similar to the desktop you mentioned. So long as the background is drawn by your app, then it is feasible to composite the bar graphs and etc on top of it. But: If the background is drawn by some other app, or is otherwise outside the control of your app windows, then compositing the graphs and so forth on top becomes Very Tricky. For now the simplest solution I can imagine is to redraw the whole parent of my object. Quite possibly: I think we need to understand more about the nature of the backgrounds, how they are drawn etc, and from there we can figure out how to render the graphs on top of them... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Webkit as FLTK subwindow?
On 12 Mar 2013, at 16:28, Roman Kantor wrote: Just asking if there is somebody who tried that (on any platform) or tried to embed other QT widget (as subwindow, that is probably easier as QT widget could use its own event delivery upon that window) for that matter. I don't think I have anything useful to offer here, other than that I once (a while back, and *very* briefly) looked at WebKit, and became somewhat bogged down... There seem to be multiple variants out there, WebKit isn't just one thing any more (or so it seemed), so maybe one of those variants would be easier to embed? And, WebKit aside, I assume you don't fancy Dillo as an option? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] updating style buffer after text change
On 12 Mar 2013, at 21:14, Steve Maas wrote: I'm stuck with a project and would appreciate some help. I have a Fl_Text_Editor class that uses a style buffer for highlighting keywords in a xml formatted text. Can anyone suggest an efficient way to keep the style buffer updated after the user changes text without rebuilding the style buffer entirely? More specifically, after the user deletes some text (possibly multiple lines), how do I find the corresponding section in the style buffer that needs updated? Similarly, when the user insert text, how can I insert new style info for the added text? I thought the editor demo in the test folder actually did all this? Might be worth a look anyway (if you haven't already, that is!) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Displaying non-english sumbols in OS Windows
On 10 Mar 2013, at 15:04, Albrecht Schlosser wrote: On 10.03.2013 15:15, Anton Petrov wrote: The problem is that in the windows operating system cyrillic text is incorrectly displaying. How it could be fixed? We need to know which FLTK version you're using. To be able to render cyrillic *and* other text in *one* application you must use FLTK 1.3, and you must probably install the correct fonts, but then it just ought to work. Yes; re-iterating what Albrecht said, with fltk-1.3, and text encoded in UTF8, and a suitable font selected, then it pretty much just works. Or at least, that is to say, I have rendered Cyrillic and Greek text in that way. I can't actually read any languages in either of those scripts, so was only displaying strings I was given; I am told it worked! If you are using an older fltk, say fltk-1.1, then you probably need to get into that whole codepage madness... Which of course makes your text non-portable. You really want to be using UTF8 and a recent fltk-1.3 snapshot! Also, if you have text that is encoded in some other representation (i.e. not UTF8) then you will need to convert it to UTF8 to get it working. That's not something fltk can really help you with, but there are many, many tools out there that do that! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Vote request: addition of two new schemesgrad and gleam
On 9 Mar 2013, at 01:57, Greg Ercolano wrote: I added a chooser for the different schemes, and squeezed in Edmanuel's widget panel that shows how the schemes look with different widgets. Here's a thought (I haven't checked the latest svn!) do we need to also tweak the test/demo wrapper program too, then? It has a scheme picking drop-down too, so I guess it needs to know about the new schemes? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Vote request: addition of two new schemes grad and gleam
On 8 Mar 2013, at 17:31, Greg Ercolano wrote: A request to vote on the addition of the gleam and grad patches to FLTK. There's two STRs for this: http://www.fltk.org/str.php?L2672 http://www.fltk.org/str.php?L2675 Would like to combine and apply. Code seems OK, looking for consensus and comments on patches. I've not looked at the patches in detail recently - looked at the gleam patch a while back, but Edmanuel has been working on it more since then... If it looks OK to others, then I'd be +1 on adding it, as more schemes would probably be a popular option! My only comment is I'd like to modify the unittests program to have a test for all our scheme options (plastic, gtk+, etc) so it can be used to look for artifacts. Basically taking STR#2672's test/gleam application and moving it into unittests as one of the test screens (with some mods). This sounds like a good idea in any case: this is what the unittests framework was meant for really, I think! (I mean, adding on all sorts of useful testing features without having to ad new test programs directly.) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Fix Version: 1.3-current (r9833) Applied the simplified version of Michael Baeuerle's scandir_posix patch. Note that this patch does not have all the const correct goodness from the earlier patches, but does mean that the fltk-1.3 API is not altered. Longer term, we'd be better off with the const correct versions (say 1.4 / fltk-3 or...) but this should do us fine for now! Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Fix Version: 1.3-current (r9833) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] Question about Fl_Input
On 6 Mar 2013, at 04:35, edgar wrote: I am using Ubuntu 12.10 but eventually I would like to compile this for Windows7 and OSX. By the way, the code you sent compiled right away and runs nicely. Most of it makes sense to me but I need to check out the draw functions more carefully to get the full picture ;) Well, Ubuntu should be no problem; ISTR they have the Musica font (possibly even version 3.06) in one of their packages, so it ought to be pretty easy to get it installed on your test machine. Failing that, it's pretty easy to install a font for just a single user on linux: - in the home dir of the user, create (if it does not already exist) a dir called .fonts - copy the desired font file, either name.ttf or name.otf, into the .fonts dir - rebuild the fontconfig cache, which, um, I can't remember how to trigger... just log out then back in ought to do it! (Might be fc-cache that does it, I think!) Thereafter, when you run any apps, the font should now be available to you app without doing anything else special. Certainly, works for me! Pretty easy for you to try it on your ubuntu box, see how the font faces look for the various musical glyphs etc. I am knocked out by how helpful the fltk community has been. No worries... Also, I have a very mildly tweaked version of the demo, if anyone is interested, where I have fixed the duff clef scaling I had coded in... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Duplicating a widget on multiple pages
On 6 Mar 2013, at 16:36, Greg Ercolano wrote: On 03/06/13 08:09, Doug Parks wrote: I am using a Slider Input widget, created from the example on Erco's FLTK Cheat page. I am trying to duplicate the widget on multiple pages such that when I change it on one it is changed on the other page. How would I go about doing this because the attempts I have made to do this have failed. Thank you for the help. Show an example of what you tried with comments about what your goal is, add comments in the code as to things you're having trouble with, and we can guide you in the right direction. Also; is this the same widget, or (more likely) you have multiple sliders that are slaved together in some way? Actually, I'm not quite sure what you mean by pages here - is this some sort of tabbed thing, with different pages that way, or... something else...? If it is tabs, then I suppose (in principle) that it would be possible to remove the widget from one tab and show it on another, as the tabs change over, so that one widget could be used on every tab... Though having written it, I'm not sure I like that idea all that much now! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] applications, themes, lsb and porting
On 6 Mar 2013, at 13:46, L Michaels wrote:
I've been checking out what Open Source applications run on FLTK 1.3
(currently 1.3.2). There are some nice ones listed on the FLTK Wiki in the
Software section. However, I've run across some that aren't listed. Should
I submit listings for some of the Open Source FLTK software that's not listed
on the Wiki or is that something the project developers are supposed to do?
I can't see why not: you could at least post an STR with the info on it, that
in itself might be useful to others.
Georg Potthast told me about the grad1 patch to add another theme to FLTK and
I started using it with FLTK 1.3. I also ran across the gleam theme patch
and began using that as well. When I updated from 1.3 to 1.3.2, I did some
file compares and created a new patch for the two themes that works for
1.3.2. Don't know if it's of use to anyone, but thought I'd mention it. If
someone's looking for a theme patch for 1.3.2, it saves some effort if they
don't have to do it themselves.
There were STR's open for some of these theme's, so if you have revised
patches, feel free to add them to the STR's, that way others might be able to
find them!
Was curious if anyone's successfully built FLTK 1.3 branch using the lsb
(lsbc++) compiler? I noticed the thread in the forum about the missing
scandir function. When I tried building with lsb over the weekend, that was
the first issue I hit. The lsb libraries don't have an implementation of
scandir. Will take a look at the patch mentioned in the thread and see if I
get any further.
Yes, I think there's a good chance that Micha's latest patch should work for
you, though you might need to fiddle with it to make sure the compiler
personality is identified suitably!
Also, ran across a directfb port for an older version of FLTK. Was wondering
if anyone was working on or looking into using current versions of FLTK with
directfb or wayland?
I think the directfb patch is pretty much orpahned, though likely the code
still works.
Wayland (or indeed Mir) might be worth a look, but I don't think anyone has
tried: I'd assume in the first instance we'll depend on the X11 emulation in
{Wayland|Mir} to get up and running anyway...
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] applications, themes, lsb and porting
On 6 Mar 2013, at 18:18, L Michaels wrote: There were STR's open for some of these theme's, so if you have revised = patches, feel free to add them to the STR's, that way others might be = able to find them! Not to familiar with FLTK's STRs. I think the related STRs are: http://www.fltk.org/str.php?L2672 http://www.fltk.org/str.php?L2675 I noticed there's a Post File feature. Do I use that to upload the patch and do I add it to one or both of the STR pages above or create a new one with the Feature Request? Well, you upload the patch itself using the Post File mechanism, then you post a brief description of what your patch changes using the Post Text option. As to where to post... #2672 is the Gleam patch, so post changes to it there. Ditto #2675 for any changes to the Grad1 patch. Or, if what you have is new stuff then sure, open a new STR for that. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687) - now STR #2931
On 1 Mar 2013, at 16:27, Michael Baeuerle wrote: Minimally invasive patch: http://micha.freeshell.org/tmp/str_2931_r9827_simple.patch Applied to fltk-1.3 branch at r9833. Michael, can you test on your machines to make sure I have not messed up, please? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Question about Fl_Input
On 3 Mar 2013, at 04:36, edgar wrote:
I am starting with a simple program to show a whole note on a staff with a
treble clef.
The user is asked to enter the note name.
The program should let the user know if their input was correct and display a
running score in the window.
OK - that seems straightforward.
However, as a design point, I'd caution against letting the user input the
answer as free text or even natural language since you then have to parse
what they enter and see if it makes sense...
(e.g. I never say whole note, I'd say semibreve, but both are correct...)
Rather, I'd offer a list of answers and allow the user to pick one - that
removes the parsing aspect and makes things a lot simpler, with no loss of
generality...
Here is the basic algorithm:
Display window with the following:
Instruction header - prompts user to enter note name.
staff and clef - (staff is drawn. clef and note are .png)
Loop {
note is shown on the staff - chosen randomly from a bank of locations.
User enters note name
Program checks user response, tabulates a score and prints a running score
to the window
}
User selects a quit button which destroys all dynamically allocated widgets.
This step is probably unnecessary - if you program is ending, and the process
in which it runs is ending, then all the allocated memory will be released by
the process anyway... In which case actually making the effort to explicitly
destroy allocated widgets is nugatory work...
Here is the code I have so far. It compiles and runs with my png files, but
I don't know how to:
Um... OK.
Well, I don't think that's the right way to go about this. There are a few
things wrong with this code...
Also, it is making your task more complex than in needs to be, which is a Bad
Thing.
Time permitting, I'll cobble up a demo and post it, of how this might be done
in a more fltk'ish way.
Might not be today though.
1. Get the user's input to the window instead of the console.
I think I can send it to an output box, but I'd like to send
it to the window via an invisible box - sort of like the header.
This is trivial, but possibly not with the code structured the way you have it.
2. Loop the sequence. I would also like to keep the code which checks the
answers separate from the code that implements the GUI.
Again, trivial, but we need to look at your program structure and see how you
can achieve that.
Key points though:
- There are better ways to draw lines in fltk; where did you get this approach
from? It looks really quite... odd...
- If you are going to render a lot of musical symbols, loading a musical font
(such as Musica or etc.) will be easier than rendering lots of PNG glyphs, and
will also anti-alias and scale automatically.
- The way the main window is being created and run here is holding you back.
- You need to see how to subclass a box and derive your own draw() method to
handle the drawing of your staff.
Anyway, I'll try and make a demo, then post it for you to see.
There are easier ways to do what you want!
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]
On 1 Mar 2013, at 15:39, Greg Ercolano wrote: On 03/01/13 01:33, MacArthur, Ian (Selex ES, UK) wrote: What Mike said: As soon as *anything* in SVN changes after a release, we need to bump the version numbers in some way. Or, just change it immediately after release. Changing the version number is itself a change, and would therefore bump the svn version#. Ah, fair point. Though in a sort of self-fulfilling prophecy kinda way... Right, I think linux (or something) used even release numbers for dev (.0, .2, etc), and odd numbers for release versions (eg. .1, .3, etc). Yes - I always quite liked that, but they stopped doing it that way... Or, we could work the SVN version number into Enumerations.H (eg. FL_SCCS_VERSION?) which might be nice to have anyway so that someone with an app can see the FLTK version /and/ SCCS #. I think svn allows for hook scripts to be triggered whenever there's a checkin for this kind of thing. Pretty sure cvs had this too. I use svnversion for this in my own build script, but you are right, the svn hooks can probably do this in a neater way. Not sure what that number becomes if we ever move to git, though.. What it becomes, as you know, is a human-opaque string of gibberish... (Technically I understand why it is like that, but I really can't believe we couldn't figure out some way to hide that behind some human-friendly index...) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
Hi Patrick,Sounds like you are working your way through the history of language development, but in reverse order!;-)C++ - Ada - Cobol ...!Cheers,-- IanSent, much to my surprise, from my Palm Pre3On 22 Feb 2013 14:46, Patrick patr...@spellingbeewinnars.org wrote: Hi Sanel Thanks for responding to my post. Your ideas are terrific. I know a little about swig and pyFLTK but I didn't know anything about the other two options. So I have been going around it circles on and off for two years with GUI tookkits. I have tried virtually all of them now. I don't want to code in C/C++. I have been obsessed with Ada for about 15 months and the GUI options for it are horrible. Bindings for other languages are available but I couldn't figure out how to call back to and forth from Ada with them without somethign whacked liked using D-Bus. I have realized that pretty much everything I like about Ada is available from Cobol too and I have recently switched my focus. Open Cobol compiles to intermediate C. I was trying to figure out how to call back into C++ from C but then I finally realized I could just run the C code through a C++ compiler and have code at the same "level" as C++ and now I don't think I need to figure out a way to call "up" into C++. Having said that, I think that a C binding would really help the project and I would like to help, please let me know if I can. Thanks again-Patrick P.S have you tried chicken scheme? Is it suitable for you? You could also run it's intermediate C code through a C++ compiler and then you would be able to call into FLTK C++ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] change labelfont and labelize in fltk 1.3.2
On 22 Feb 2013, at 22:16, edgar wrote: Thanks so much for all of the terrific advice. You're welcome: we're happy to help! I have a lot of experience using Finale and ProTools, but I am new to programming. Take a look at Musescore and Rosegarden then - they cover a lot of the same ground as Finale and ProTools, but are open source, so you can tweak them to your needs more. The workflow is a bit different, in places, but you can do the same things... I would like to write some music education applications: nothing nearly as vast as Finale or Sibelius, but little programs that parse MIDI into notation or vice versa. There's a whole can o' worms hiding in there though: parsing notation into MIDI is pretty easy, but parsing MIDI into notation is *hard* as MIDI doesn't retain enough information about what was originally notated... In many cases it just holds a stream of notes, and the voice each is played with. So you need to figure out the time sig, the key, what the parts are, and if it's a piano (say) you need to guess whether to notate the notes to the right or left hand, and so on... And then actually getting the notation to layout nicely on the page is just a nightmare - I used Sibelius a fair bit (quite a few years ago now!) and it always did an OK sort of job laying things out; I didn't realise at the time just how hard that actually was to achieve! In our tool, we looked at embedding meta-data into the MIDI stream to retain more of the layout from the original notation, but it wasn't nice. Ended up using a version of MusicXML to store the layout information (and it is fairly easy to convert that to MIDI to play it anyway...) Most of the main tools can read/write MusicXML format these days (though none have it as their primary format) so it does represent a sort of common format for exchanging material between tools. Scoring music is trickier than it looks... I spoke to a guy who codes for Auralia who said the same thing. I guess I have my work cut out for me... Yes: have fun! BTW, do you know of some simple MIDI programs that are open source for means of studying the code? Depends what it is you want to do. The MIDI file format is not all that complex, so it is pretty easy to read/write the raw files. That said, I mainly use Portmidi (an open source MIDI lib) to output MIDI data these days as it runs on all the platforms I use, and once you get used to its API, it works OK for playing stuff in real time. Or maybe I answered the wrong question? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] C API experiment
On 21 Feb 2013, at 14:36, Patrick wrote: I've only been using Fltk in pure C++ applications so far. Fltk is worth programming in C++ but I am not crazy about it. I don't like C either actually but it's easier to work with from other languages. I have read some other posts in the past about creating a C API and it looks like the main issue is that it would bloat FLTK. I doubt that bloat is the key - I suspect the problem is that many C++ projects, such as fltk, have a lot of overloaded function calls (that is, functions with the same name, but which take or return different parameters.) There's no way in plain C to have more than one function with a particular name, so there's no easy way to make a C API that maps one-to-one onto the C++ API. And from there on out, it just gets messy... I was thinking that if I was able to find a way to auto-generate a whole bunch of C functions that contain calls to all the C++ methods I could create the C binding and that if each was in it's own C++ file that contained the extern C brackets then there would be a mechanism to mitigate bloat. You probably need to investigate whether some form of IDL (Interface description language) could be used to specify the interface you want and have that create the C/C++ code for you. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] change labelfont and labelize in fltk 1.3.2
On 21 Feb 2013, at 02:35, edgar wrote: I copied hello.cxx from the docs and compiled but the font comes up tiny- definitely not 36 - and does not change when other values are given as arguments. Nor do the fonts change. If you send me an email address I will send a screenshot with code and the FLTK window. One note is that the compiler g++ could not locate the Xext library so I removed it from the compile statement. Is the label font size and type dependent on the Xext lib? No lib Xext? I'm surprised fltk works at all...! I'm guessing you don't have the dev packages installed then. If you don't have Xext dev packages, then you are probably missing a load of other good stuff too, so that probably does explain the behaviour you are seeing... I can rebuild fltk but it was challenging to get the X11 libraries to link up so I would rather find Xext and get it in the right path if that is the problem. Yes, sounds like you need to install the dev packages. What system did you say you were on? Is it ubuntu? They seem to have taken the whole user focus thing a bit too far in their desktop systems, and they leave out a whole pile of dev stuff that you likely need! From memory... try... apt-get install libx11-dev apt-get install libxt-dev apt-get install libxft-dev apt-get install libglut3-dev Though that list is probably wrong! Then re-run the fltk configure script from scratch and then rebuild fltk - after that, I'd hope things would be better! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] change labelfont and labelsize in fltk 1.3.2
On 21 Feb 2013, at 03:09, edgar wrote: I just installed Xext lib and compiled hello.cxx with -lXext. It compiled but still no change in labelfont and label size. :( See my earlier post - I suspect you are missing more dev packs than just Xext... Also, once you have installed the missing packages, you must re-run the fltk configure script, so that the fltk build will know that the libs are now available. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] change labelfont and labelize in fltk 1.3.2
On 21 Feb 2013, at 20:33, edgar wrote: I installed the packages above as mentioned. One note according to Ubuntu support: libglut3-dev has been replaced. This package has been replaced by ``freeglut3-dev''. Could this be affecting the fonts? No, that would only affect use of GL and GLUT, not regular font handling... Does the build require flags before running the configure script? Not on a normal system... might need that if your set up is odd in some way, but any stock distro would be fine as is. So fltk runs and I can compile the programs but unfortunately it still does not change the labelsize or labelfont. Do I need to include extra libraries in the compiler statement? Yes, from what you have, I'd say you are missing a good few things... Here is how I am compiling: g++ -Wall hellofltk.cxx -I/usr/local/include -L/usr/local/lib -o hellofltk -lfltk lXext -lX11 -lm OK, first off, you need to read up on fltk-config, there's a HowTo here: http://www.fltk.org/articles.php?L599 But in summary, if you are compiling a single file, don't do it yourself, let fltk-config figure it out for you: fltk-config --compile my_file.cxx That way, the right libs should get pulled in... To find out what the right libs are, try: fltk-config --ldstaticflags And see what gets listed. I'd guess something like... /path/to/libfltk.a -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11 The kickers there, at least in terms of font handling, are Xft and fontconfig. Xinerama probably won't matter much, and pthreads and dl you will need once your code becomes more complex, though probably not for the sample code you are testing right now! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current ALbrecht queried whether there are any ABI issues: Micha reports that it looks like there are. In particular, the change of the prototypes of the sorting functions to be more const-correct breaks C++ linkage. Options are perhaps to revert the functions to their previous non-const forms? Greg suggests that we could keep the new forms if we put the ABI guards around them, with the old forms being the default... The new forms are preferred though because they are a better match to the Posix spec. In other, happier, news, Micha reports that the code runs fine on: -- POSIX.1-2008 compliant native 'scandir()': - HP-UX 11.11 (32Bit, big endian) Special AIX native 'scandir()': - AIX 5.1 (32Bit, big endian) -- And Manolo has verified that the special detection of MacOS =10.8 still works. Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature A thought: Should Fl_X11_File_Chooser maybe be called Fl_Fltk_File_Chooser or some such thing? In that, it is not really X11 specific, it is just a wrapper for the basic FLTK file chooser, so could be used on any host in principle (though in this case likely only under X11 I concede!) Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Upload Michael Baeuerle's patches to implement a scandir() function that we can use on *nix systems that is free of any potential license restrictions. The prior fl_scandir method was removed by #2687 due to license concerns, but this broke compilation on some systems (e.g. SunOS 5.7) that do not provide a suitable scandir() function natively. Attached files implement a substitute that we can use, that is reported to work, and should not break any exisitng platforms. Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current scandir_patches_for_fltk-1.3.x-r9824.tar.gz Description: Binary data ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Currently tested on the following systems: -- Windows: - WinXP with mingw32 (assume other WinXX versions OK, since code change is trivial here) OSX: - 10.6.8 (OSX post 10.8 has a different scandir() implementation so needs to be verified separately) Systems with no usable native 'scandir()': - SunOS 5.7 (64Bit, big endian) Systems with a native POSIX.1-2008 compliant 'scandir()': - F17, 32-bit - Ubuntu 12.10, 32-bit (this codepath is effectively unchanged from before) OSF/DU/Tru64/IRIX: - None yet AIX: - None yet Systems with native 'scandir()', but not a POSIX.1-2008 compliant one (plus it matches to none of the explicitly handled cases above): - GNU/Linux with glibc 2.8 (32Bit, little endian) - NetBSD 5.1 (32Bit, little endian) Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] change labelfont and labelsize?
On 18 Feb 2013, at 22:38, edgar wrote:
Hi.
I am not able to change labelfont() and labelsize() in fltk-1.3.2
I am using the g++ compiler and Ubuntu 12.10.
Here is an example of the code with Hello World:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
int main(int argc, char **argv) {
Fl_Window *window = new Fl_Window(340,180);
Fl_Box *box = new Fl_Box(20,40,300,100,Hello, World!);
box-box(FL_UP_BOX);
box-labelfont(FL_BOLD);
FL_BOLD is not a font face name; it is a modifier.
Perhaps you meant FL_HELVETICA or FL_HELVETICA_BOLD or some such?
Note that, FL_HELVETICA_BOLD is actually the value (FL_HELVETICA | FL_BOLD)
Take a look at the examples in the test folder, and see how label fonts and
sizes are handled, and check the docs for text drawing and font handling
details.
It'll all make much more sense...
box-color(FL_WHITE);
box-labelcolor(FL_GREEN);
box-labelsize(36);
box-labeltype(FL_ENGRAVED_LABEL);
window-end();
window-show(argc, argv);
return Fl::run();
}
I can email a screenshot, but I don't see where to attach the screenshot
to this message. Thanks,
Edgar Crockett
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Cool tweaks: very good stuff. But, addressing Sanel's observations: Do we want to do this? I wrote the code more as a proof of concept in response to the STR than as an indication of intent to do this... Sanel said: Sorry guys for commenting here (or maybe 'devel' list will be fine), but adding Gtk+ dialog in form of 'native' one, makes absolutely no sense. Yes, it is a tricky one, though I suspect for the majority of users, the gtk chooser is more familiar than our native one... So, what for example if I install Kubuntu where Qt is reference toolkit and remove all Gtk+ stuff? Is it then normal to expect FLTK to show Qt dialog as 'native' one? Yes, in particular this is awkward - though note that this already happens to me anyway; I have often had apps I'm running open the gtk file chooser, even though I'm running some KDE-based desktop. I assume I am not unique in this regard, so perhaps this is considered normal these days? In any case, if we go this way, we have to dlopen the gtk libs or the kde libs, having somehow decided which to actually use...? I *assume* there is some way (environment variables?) to determine what flavour of desktop the user is running? IMHO if user wants Gtk+-like dialog, how hard for him would be to dlopen() Gtk+/Motif/whatever... Yup - this code was meant to show exactly how hard it would be, and to provide a working example... not necessarily intended to be included into fltk core. In any case, if we did include this, it would need to ahve the ABI runtime guards around it for 1.3.3 or something? Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn'texactly native on linux
On 16 Feb 2013, at 07:07, Bill Spitzak wrote: Has anybody looked at exec'ing zenity or kdialog, etc? I'd never even heard of zenity until Greg mentioned that JUCE used it... It certainly looks like it could work for us; we'd want zenity --file-chooser zenity --file-chooser --multiple zenity --file-chooser --directory I guess to cover our normal cases. BUT... How widely deployed is it? A lot of the test boxes I have do not have zenity installed, though they do have gtk libs... Though these machines may be non-standard and therefore unrepresentative of course! In any case: We still need to address the issue of guessing what desktop the user is running and then choosing either zenity or kdialog accordingly... Thoughts? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: decision on license to use for fltk/examples source code
On 16 Feb 2013, at 02:19, Greg Ercolano wrote: I guess I kinda like Zlib (#2) or MIT(#3). #4(GPL2) if we can settle on exceptions. I would vote for zlib (#2) but suggest we add an explicit statement that is is OK to take these code examples and incorporate them into your own modules. I'm not keen on the MIT license these days, and very wary of the GPL, I don't think we can really use it for code that we *intend* people to modify without attribution, or other hindrance! On the more general note of licenses, I'm coming round to the MPL-2 these days, it seems to be a nice balance for things... But again, not appropriate for the examples folder I think... IANAL, as ever... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Ubuntu vs Fedora performance GMorgan0.58
On 14 Feb 2013, at 17:22, Robert Vogel wrote: Thank you for your note. I think you are correct...I DO have an Nvidia card. But, since it was not too straightforward to install the drivers, I didn't prove it. The nVidia driver bundle from their website is pretty easy to install, you just run the install script they give, and stand well back! That said, I've never used it on F17 - though have on other distros, most recently some sort of hacked up slackware derived monstrosity... It has always Just Worked for me, though I have heard that others have had issues! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
On 16 Feb 2013, at 18:11, Michael Baeuerle wrote: Here it is: http://micha.freeshell.org/tmp/2013-02-16_scandir.tar.gz The archive contains the new implementation, the old implementation and some test programs to compare the new, the old and the native implementation of the system. The test programs show the content of the current working directory. If a name is specified as parameter, a filter is applied to mask all other directory entries. The new implementation locks a mutex if HAVE_PTHREAD is #defined. In this mode it should be thread safe even if readdir() is not reentrant (that is allowed by POSIX). At the moment I can't access the Sun machine from here, but I have tested on AIX 5.1 and HP-UX 11.11 and it works on both. I will test on the Sun the next few days. In the meanwhile it would be nice if somebody else can run the test programs on other systems. Tried it on a few linux distros, and on OSX (10.6.8) Appears to be good. Observations are... - Had to add #include string.h into scandir_old.c to get things to compile nicely (on linux and OSX) - Added -Wall to the Makefile, just in case, but it didn't flag much of note, other than... - The native test on OSX fails outright, the OSX scandir is odd... And forcibly setting #define _POSIX_C_SOURCE 200809L makes it worse... Commenting out that line allows the code to run correctly but -Wall warns that the prototype is wrong (unsurprisingly!) However, your code appears to be good! Cheers, -- Ian ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Ubuntu vs Fedora performance GMorgan0.58
On 12 Feb 2013, at 21:15, Robert Vogel wrote: Originally the UI was generated using Fluid, but lately I have been hand-coding it. Just to be sure there is no misunderstanding the formerly generated code is now an element called NotGenerated.cxx. It contains a small routine, LightIt, which colors the bars when sequencing and scrolls. The last line of LightIt is a redraw statement. If I comment it our in Fedora, timing recovers. I use the same 64 bit machine for both U12.4 and F17. So, here's the question: What's the difference between Ubuntu and Fedora that could cause this ? Hard to say: there is *nothing* in the fltk lib that knows about different Linux distro's, so we don't do anything different for Ubuntu vs Fedora. Or any other linux for that matter... Hmm, OK, I just tried a run on a VM here; Ubuntu 12.10 32-bit vs F17 32-bit, with some rendering tests I had. No idea how representative that will be of your usage, mind you... Didn't really see much, if any, difference in the numbers - both came out about the same in every test. In my GL frame test the Ubuntu box came in at 152 fps, the F17 was at 149, but other tests I couldn't say I saw any difference that was not just noise. Ah, now, here's a thought - What graphics card are you using? Ubuntu quite often will install the vendor supplied (non-free) binary drivers, whereas F17 will not (unless you force it to) and that can make a *substantial* difference to rendering. In particular if you have a Nvidia card, the vendor binary driver is *much* faster than the nv/nouveau free drivers; in one test I did recently the nv driver managed 18 fps, the nvidia driver was over 500 fps. Running *the same* executable. That sort of delta might make a difference! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Building code examples using FLTK on recent Linux, and Raspberry Pi
On 11 Feb 2013, at 20:14, Alec Ross wrote: Thanks Ian, No worries... FWIW, I have built the PPP demo code on Ubuntu-12.10 and OSX now, for a look, linked against 1.3.2... Some comments appended below... 2) A few simple, compilation problems in the example code that were easy to fix. Though perhaps unexpected? I'd imagine those examples are well-tried, so if errors are being encountered that might hint at some underlying problem? Indeed. Well, that was interesting... The dialect of C++ the examples are in seems quite dated; all the compilers I have access to whined about the code in places. Several places needed actual interventions; - Several occurrences of Font had to be Graph_lib::Font to disambiguate the meaning. - Several occurrences of Window had to be Graph_lib::Window to disambiguate the meaning. The binaries, once built, did run, but... (more on that later...) Problem 1) above was encountered with or without an (1.3) version of FLTK separately installed on the machine. By installed do you really mean installed or just on the same machine? Wrt 1.3, I mean installed. Wrt the 1.1, I built and linked with this, but did not install it. This was intended to leave open the possibility of its not interfering with the use of the installed 1.3; and more importantly, I'd hoped to get a working version of the PPP examples, insulated from any changes coming w/ updates to the (FLTK) library. Ah... word of caution though - *if* the fltk-1.3 headers were actually installed, then when you tried to build a local fltk-1.1, there is a really nasty chance that the compiler might pick up the (system, installed) fltk-1.3 headers when you want the fltk-1.1 headers. Now, that *nearly* works, sort of, and I have even managed to compile and link code in a messed up setup like that. Wouldn't run though! ;-( But there were no huge issues seen with the results, apart from those covered below, which might be unrelated to this change. In running the built example code, there was a problem related to closing the example window. Several of the samples have a Next button which worked - at least reasonably - reliably to effect closing. But the window's 'x' or close on its menu seemed to result in the app's looping. Is this to be expected? I've seen references saying that windows under FLTK, Fl::run() does not return until all of the windows under user control are hidden or closed. Is this related? No, this appears to be a design choice in the PPP Simple_window class; though I would have done it differently! If you look at the file GUI/Simple_window.cpp, in the method Simple_window::wait_for_button(); there is a deliberate attempt to ignore the window close button. (Though implemented in a rather odd way, in fltk the better thing to do would be to attach a null callback to the default window callback handler, but I suspect Dr Stroustroup didn't want to take his students down that particular rabbit hole at this stage in their studies!) Also, at line 30 of that file he is spinning in a loop: while (!button_pushed) Fl::wait(); I think it would behave better with a slight delay set here, viz: while (!button_pushed) Fl::wait(0.1); Grab a tarball of fltk-1.3.2 from here, and then do the: ./configure ; make dance. I may do. But my proper installations were done from the package systems of Ubuntu (via GUI), and RPi (via apt-get at the command line). Meh. IIRC the debian packagers (hence Raspbian and Ubuntu) mess about with our packages, so I don't use them. The raw tarballs are preferred. Finally, on the Raspberry Pi's display, the lines are over-thin, and the colours (colors ;-)) are somewhat poor. Hmm, the colours look OK in my tests. The lines are a bit thin, but about what I'd expect for a single-pixel not-anti-aliased line on X11. Fltk does not anti-alias lines (well, except on host systems like OSX where you get it whether you want it or not) so that may be making things look worse than you expected? Or maybe it really does look bad on your system, I dunno... You could post a screen grab somewhere? Tks. I've done that before, and may do so again. But I suspect that the line thickness issue is a) 'cos the samples date from a lower res age, and I don't think fltk has changed its line defaults though. Since... ever? b) thickening would be easy to achieve by slight tweaking of the implementation of the PPP graphics shapes classes. A 2-pixel line width might work better generally anyway in these examples? (Which begs the question: is/are there functions in FLTK that can determine at runtime the screen or window dimensions (in pixels) for width and height? If so, the code could self-adjust the line thickness.) Sure, you can use the Fl::screen_*() methods to determine the display size, resolution, etc... Check the docs for details. I'd try the fltk /test folder
Re: [fltk.general] FLTK pronunciation [was: EDE/FLTK talks onFOSDEM]
On 11 Feb 2013, at 22:05, Greg Ercolano wrote: On 02/11/13 01:26, MacArthur, Ian (Selex ES, UK) wrote: If it's a unanimous thing, we should probably change the docs.. or just leave it as one of those odd cultural things? Sure. Like: How do you pronounce OSX? Lol, I certainly do both; oh-ess-ex and oh-ess-ten. I confess I do use both - depends who I'm talking to I guess... Maybe my using eff-ell-tee-kay regional, as in the region only around me ;) I pronounce qt and tcl as que-tee and tee-cee-ell, as I just can't fathom cute and tickle; too cutesy. Oh yes; 100% agree. I mean, tickle, really?! Everyone seems to know what I'm talking about, though. But maybe I'm also driving everyone around me crazy. I assume they just think I'm too ignorant of the true way. Which is fine by me...! Nah! The docs say fulltick, so that *must* be right. The docs are *always* right... ..though of course no one *ever* reads docs ;) Sure. They are a form of write-only storage, right? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FL_LEAVE in Fl_Menu_Bar
On 9 Feb 2013, at 00:06, Howard Rubin wrote: In this program, I've derived from Fl_Menu_Bar and overridden the handle(int) function. That's because I need the submenu to pop up when the mouse enters the the menu, without the user having to press a mouse button. I'm not really clear on what you are trying to achieve, but I do wonder if you might be better deriving your own menu bar class form Fl_Menu_ rather than trying to prod Fl_Menu_Bar to do what you need. If you are going too far beyond what it normally does, that might actually be easier. Or... maybe you can cobble something together by putting menu_buttons into a group (rather than menus in a menu_bar) and (somehow) use that to get the desired effect? It seems that pulldown() doesn't return until I press Esc, and handle(FL_LEAVE) doesn't get called until then. Thinking of my Fl_Menu_Bar derived class and its submenus as a unit, I need to somehow detect as soon as the mouse cursor enters or leaves that unit, without requiring a keyboard press or mouse click. Yes.. One thing that occurs to me is that, in your derived handle() method, you probably need to be sure and call the base class method in every case, as it may be propagating actions to subsidiary widgets and so forth. So I generally call it first, and then do any specific extra actions locally. And return the appropriate value, of course. Oh, and having returned non-zero for the ENTER event you need to also return non-zero for the LEAVE event to make things balanece. I think... Though I have no idea if any of that is pertinent in this case or not! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Sys_Menu_Bar not honouring programmatic updates to check boxes
On 7 Feb 2013, at 11:03, MacArthur, Ian (Selex ES, UK) wrote: I have an app that, in its menu structure, has some FL_MENU_TOGGLE entries that show a check mark... Now, depending on various happenings within the code, these check marks may be set or cleared programmatically at runtime, using e.g. item-set(); and item-clear(); All well and good - except on OSX where I am using Fl_Sys_Menu_Bar, where the changes to the state of the toggles are never shown by the menus... I took a brief look at this, and it does seem as if the Fl_Sys_Menu_Bar on OSX does not get updated to reflect the changes caused by the Fl_Menu_Item::set(),clear() and set_only() methods, in its current form. Not sure how to make that work (it is beyond my OSX-fu skills) but I guess it might be possible to sledgehammer it by triggering a call to convertToMenuBar(...) which would tear down and then rebuild the entire Fl_Sys_Menu_Bar. Sounds a bit heavy-handed, but should work and mean that the state is reported correctly... Anyway, that looks like something that I can do by deriving my own class from Fl_Sys_Menu_Bar and adding a few new methods to test it, so I'll maybe take a stab at that later. (No OSX machines in this office, so can't test now!) OK - outcomes... Didn't need to do anything clever in the end; just a bit of a nasty hack instead! Turns out that calling Fl_Sys_Menu_Bar::replace(); will cause OSX to tear down and rebuild the menu structure, and thus make it reflect the current state of the check marks and so forth. So, just pick a menu entry, then rename it to itself, and... Something like this: // Apple / OSX specific hack to force the menu to be rebuilt // NOT needed on win32/linux... int idx = mb1-find_index(File/item 1); mb1-replace(idx, item 1); // end of menu rebuild hack... Seems to work just fine. As a workaround. A proper fix would be nice though! Cheers, -- Ian ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Fl_Sys_Menu_Bar not honouring programmatic updates to check boxes
(Maybe one for Manolo?) I have an app that, in its menu structure, has some FL_MENU_TOGGLE entries that show a check mark... Now, depending on various happenings within the code, these check marks may be set or cleared programmatically at runtime, using e.g. item-set(); and item-clear(); All well and good - except on OSX where I am using Fl_Sys_Menu_Bar, where the changes to the state of the toggles are never shown by the menus... Though if I query the menu items internally they do report the state toggling, and if I click on the check items, they respond as if they had the internal state rather than the displayed state... That is, if the menu shows a check mark, but internally that item is clear, then clicking on the item causes it to be updated to the set state... Then clicking it again clears it... Of course, the same code appears to be fine on X11 and WIN32 so this does seem to be a feature of Fl_Sys_Menu_Bar. Anyone else seeing this? Is there a workaround? How do I cause the Fl_Sys_Menu_Bar to be refreshed to reflect the actual state? I guess this may be a bug? Or is this Just The Way Things Are on OSX and we are stuck with it? Cheers, -- Ian ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Moving symbol on Fl_Menu_Bar Fl_Menu_Item
On 1 Feb 2013, at 21:54, Howard Rubin wrote:
I'm adding a symbol to an Fl_Menu_Item on an Fl_Menu_Bar using
set_labeltype(). It's mostly working but when the menu is dropped down,
the symbol moves to the left by about 12 units. (BTW, this approach
solves the Changing an Fl_Menu_Bar item colors question)
Why does the symbol move and how can I keep it from moving?
I'm not entirely sure *why* it is happening, but it is pretty easy to see
*what* is happening...
If you modify menu_label as follows...
void menu_label(const Fl_Label* o, int X, int Y, int W, int H, Fl_Align a) {
fl_normal_label(o, X, Y, W, H, a);
// * Why does this move when the menu item is selected? *
// W = 63; // apply the sledgehammer fix...
int xx = X + W - 12;
int yy = Y + (H / 2);
printf(pos (%d, %d) (X %d Y %d W %d H %d)\n, xx, yy, X, Y, W, H);
fl_circle(xx, yy, 5);
}
Then at run time (on this Mac, numbers on other hosts might conceivably differ?)
For the not selected menu:
pos (60, 12) (X 9 Y 0 W 63 H 25)
For the selected menu:
pos (45, 9) (X 6 Y 0 W 51 H 19)
Now... I am not sure what I'm seeing there, but I speculate that the changes to
X and H reflect the change in the size of the selection rectangle or something,
they seem to be about 3 (or 6) pixels off the size of the no-selection case? 3
pixels seems about right for the inset of the selection from the edges...
The kicker is the change in the W value - and I don't know what is happening
there at all...
However, that is the key - note the commented out sledgehammer fix in the
code fragment. With that enabled it all works just fine.
So; not a solution, but might be a hint where to look (or how to hack around
it!)
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Changing an Fl_Menu_Bar item colors
On 31 Jan 2013, at 19:40, David Allen wrote: Posts from Ian come up as a big block of letters in my browser. Is this some kind of compressed file or is there a problem somewhere? I use Opera on Ubuntu. Urgh! I had not seen that, they get delivered here OK... But looking on the forum view, I see them as big blocks of what looks like Base64 or some such thing... Has this been happening for long? Did not used to happen... I'm posting those from Outlook at work and I have had some sensible looking replies, so I guess that at least some folk must be seeing them intact... Weird: I'll check tomorrow, see if my Outlook settings have been changed or something... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Changing an Fl_Menu_Bar item colors
On 31 Jan 2013, at 19:40, David Allen wrote: Posts from Ian come up as a big block of letters in my browser. Is = this some kind of compressed file or is there a problem somewhere? I use = Opera on Ubuntu. Urgh! I had not seen that, they get delivered here OK... But looking on the forum view, I see them as big blocks of what looks = like Base64 or some such thing... Has this been happening for long? Did not used to happen... I'm posting those from Outlook at work and I have had some sensible = looking replies, so I guess that at least some folk must be seeing them = intact... Weird: I'll check tomorrow, see if my Outlook settings have been changed = or something... For what it is worth... I just fired a few of my trashed messages through a hack decoder I knocked up; and it is Base64 encoding as I suspected. Don't know why though. Looking back through the forum, it looks like my posts were OK in December, but since I went back to work in January, all my posts look to be b64 and not readily readable. So... I have to assume some setting has been improved by the clowns that run our IT services at work... I'll need to see if I can revert this - though there may be some noise whilst I test - apologies in advance! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFC] a new class to support Internationalization
On 29 Jan 2013, at 17:35, Sanel Zukan wrote: Maybe question is why FLTK does not support (GNU) gettext across whole library? This way translation strings could be handled in more standard way and you will get for free a bunch of tools or services like Transifex. Hi Sanel, I'm not clear what you are proposing here: it doesn't seem to me that there are all that many strings in the library that are exposed in GUI elements, so I'm not sure what we would i18n here... What am I missing? There are a few places, e.g. in the fl_ask (and related) dialog boxes where strings are coded in, be ISTR that they are all accessible to be changed from user code at runtime? Other than that...? -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2925: Inherit Fl_Menu_Window from Fl_Double_Window to avoid flickering
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature I'm not sure what's being reported/requested here, or the context in which it is needed, can the OP please expand or clarify the situation? In particular, from the attached screen-grab, I infer that the host platform is probably OSX, in which case the single/double buffering thing is more confusing, since rendering on OSX tends to be buffered and composited in such a way that it is inherently double-buffered anyway, even if we use a single buffered window... So... Perhaps somnething else is causing flickering in this case? Anyway, I'm confused... Perhaps some example code that exhibits the problem might be helpful here? Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2926: Remove hardcoded extra pixels from menu window size
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2926 Version: 1.3-feature Can you mock up some expamples of how you'd expect it to look, and post these here too, for reference? Link: http://www.fltk.org/str.php?L2926 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2927: Please replace LEADING constant in FL_Menu.cxx to something changeable
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2927 Version: 1.3-feature Not sure what's being asked for here - the menu's look OK to my eyes... Can you post a mock-up of how you expected it to look? Link: http://www.fltk.org/str.php?L2927 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2925: Inherit Fl_Menu_Window from Fl_Double_Window to avoid flickering
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature Closed at the request of the OP Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2929: New Fl_I18n class to support internationalization of FLTK apps
On 28 Jan 2013, at 21:49, Manolo Gouy wrote: Link: http://www.fltk.org/str.php?L2929 Version: 1.3-feature A major issue: Fluid support for i18n is missing. I thought fluid could help with i18n... Yes, if you go Edit-Project Settings then you can select catgets or gettext support, and then use File-Write Strings to output the actual strings for processing... Or, is that not what you are meaning? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Segmentation fault when calling Fl_Output-value()
On 25 Jan 2013, at 04:56, Moses McKnight wrote: I'm using the latest svn of fltk 1.3, and I have a simple window with an Fl_Output. When I call the value(const char*) function with a string I get a segmentation fault, and running it in the debugger shows it happens in the Fl_Widget::clear_changed() function, called at the beginning of the Fl_Input_::static_value(const char* str, int len) function. Any idea why this might be happening? I am using a number of Fl_Output in other windows in this same application without any problems. Without seeing more of your code, it's hard to say: a common reason for this sort of thing is that something (perhaps the string?) has been declared stack-automatic in some function, and has fallen out of scope before it is used... Does that sound likely here? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2816: Add ability to set proper window icons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature This being so (the ABI safety of said patch) then I think this would be good to add... What do others think? Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2636: notification of clipboard changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature Great - if this is indeed ABI-neutral then I am in favour... What do others think? Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] GIF Image
Hi Marc, On 21 Jan 2013, at 17:21, Marc R.J. Brevoort wrote: On Thu, 17 Jan 2013, Ian MacArthur wrote: Somebody (maybe Albrecht? Can't recall now, it was a while ago...) did post patches to implement animated GIF's, but that was some time (years) ago, and there seemed to be no demand for that ability, so it never happened... That was me. http://ringbreak.dnd.utwente.nl/~mrjb/fltk Yes - sorry about the mis-remembering there; fortunately others with better search skills than me, found the appropriate links! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Open a menu with Mouse hover
On 21 Jan 2013, at 17:39, Howard Rubin wrote:
How can I get a menu item to drop down by hovering the mouse?
In this program, clicking on the File menu will drop it down, and then I
can just move the mouse over the Edit menu to drop it down.
I need the File menu to drop down when I move the mouse over it without
the mouse click.
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Menu_Bar.H
int main(int argc, char **argv) {
Fl_Double_Window *win = new Fl_Double_Window(300,100);
Fl_Menu_Bar *menubar = new Fl_Menu_Bar(0,0,300,25);
menubar-add(File/Open);
menubar-add(File/Save);
menubar-add(Edit/Cut);
menubar-add(Edit/Copy);
menubar-add(Edit/Paste);
win-end();
win-show();
return(Fl::run());
}
There's no built-in support for that in fltk, so you'll need to roll your own
widget to do this.
For most widgets, the normal thing to do would be just derive from the widget
you want to tweak, then override the handle() method to catch the enter/leave
events and use those to trigger your drop down.
But... for historical reasons (possibly to be resolved in fltk3!) the
Fl_Menu_Item widget is not a true class, and you can't really derive your own
modified version as a result...
Instead, what you can do is replace the Fl_Menu_Bar with a simple box,
populated with your own widgets derived from Fl_Menu_Button - this can easily
be made to appear like a conventional menu bar, but the derived Fl_Menu_Button
widgets can have a modified handle() method that catches the FL_ENTER /
FL_LEAVE events and uses those events to trigger to popping up (or down) of the
menu associated with the Fl_Menu_Button.
Any use...?
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Abstract platform driver layer
On 21 Jan 2013, at 15:28, Christopher James Huff wrote: There seems to be little in the way of an organized abstraction of the underlying platform, with platform-specific code instead being scattered here and there through the codebase. Has it been considered to take the approach used for graphics drivers and apply it for for general platform support? The main idea here is something that would give a well-defined interface to implement for things like window operations and event handling, better separate FLTK and platform-specific code, and would make it easier to do port to platforms including frameworks like SDL or GLUT. It would also allow extension of a platform by subclassing to modify behavior or support different OS versions. Yeah... I think we are heading that way, but there's a lot of legacy code to get through... Maybe for fltk3...! As ever, a competent volunteer is more than welcome to take a stab! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #829: Support for animated GIFs in Fl_GIF_Image
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L829 Version: 2.0-feature Yes, I agree with Greg, this looks do-able now, with the ABI guards and so forth in place, and Marc's code looks decent, though might need poking a bit to make it more fltk-compliant! So, maybe an option for 1.3.x where x 2 then? Link: http://www.fltk.org/str.php?L829 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #829: Support for animated GIFs in Fl_GIF_Image
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L829 Version: 3.0-feature For now, I'm moving this to 3.0 (as it seems more appropriate there than 2.0) but I think we should consider putting onto 1.3.x with a suitable ABI-define guard around it... Link: http://www.fltk.org/str.php?L829 Version: 3.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Activate buttons - was: GIF Image
On 19 Jan 2013, at 15:39, Ian MacArthur wrote:
On 18 Jan 2013, at 23:49, George wrote:
Now i have another question I'm kind of a beginner in fltk. I have a window
with some input widgets and a button which is deactiveted initially. I want
to activate the button when i insert text in all the input widgets(the
button can't be pressed if an input is empty). I've read some things and i
know it;s something with events handling and FL_KEYDOWN but it really gives
me a hard time. Any help will be appreciated
I don't think it would require any messing about with event handling per se;
should be enough to have a callback attached to the input widgets that checks
whether they are all set or not, and if they are all set, do a
button-activate() to wake up the button...
So... in a rare quiet moment, I was inspired to throw together a quick demo: I
think this shows what was being asked...
Though in practice I imagine that some more sophisticated validation of the
content of the Fl_Inputs would be performed, to make sure the values set were
valid (and not just non-empty!)
// demo of activating a button...
// fltk-config --compile inactive-button-demo.cxx
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Input.H
#include FL/Fl_Button.H
static Fl_Double_Window *main_win=(Fl_Double_Window *)0;
static Fl_Button *done_bt=(Fl_Button *)0;
static unsigned inputs_set = 0;
static void check_inputs_are_ready(Fl_Input* in, unsigned mask) {
if (strlen(in-value())) {
inputs_set |= mask;
}
else {
inputs_set = ~mask;
}
if (inputs_set == 7) {
done_bt-activate();
}
else {
done_bt-deactivate();
}
}
static void cb_input1(Fl_Input* in, void*) {
// input 1;
check_inputs_are_ready(in, 1);
}
static void cb_input2(Fl_Input* in, void*) {
// input 2;
check_inputs_are_ready(in, 2);
}
static void cb_input3(Fl_Input* in, void*) {
// input 3;
check_inputs_are_ready(in, 4);
}
static void cb_done_bt(Fl_Button*, void*) {
main_win-hide();
}
int main(int argc, char **argv) {
main_win = new Fl_Double_Window(348, 367, Activate Button Demo);
main_win-begin();
Fl_Input *input1 = new Fl_Input(130, 37, 200, 33, Enter Some Text);
input1-callback((Fl_Callback*)cb_input1);
input1-when(FL_WHEN_CHANGED);
Fl_Input *input2 = new Fl_Input(130, 124, 200, 33, Enter Some Text);
input2-callback((Fl_Callback*)cb_input2);
input2-when(FL_WHEN_CHANGED);
Fl_Input *input3 = new Fl_Input(130, 212, 200, 33, Enter Some Text);
input3-callback((Fl_Callback*)cb_input3);
input3-when(FL_WHEN_CHANGED);
done_bt = new Fl_Button(215, 285, 115, 65, Done);
done_bt-callback((Fl_Callback*)cb_done_bt);
done_bt-deactivate();
main_win-end();
main_win-show(argc, argv);
return Fl::run();
} // main
// end of file
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Activate buttons - was: GIF Image
Urgh - that's irritating.
I just saw my own post, and it looks like the mail server has mangled it
somewhat.
I thought that only happened when I was using MS Outlook, not with Apple Mail,
but apparently Apple Mail gets mangled now too. Oh well...
Is this any better (re-posting, sorry!)
// demo of activating a button...
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Input.H
#include FL/Fl_Button.H
static Fl_Double_Window *main_win=(Fl_Double_Window *)0;
static Fl_Button *done_bt=(Fl_Button *)0;
static unsigned inputs_set = 0;
static void check_inputs_are_ready(Fl_Input* in, unsigned mask) {
if (strlen(in-value())) {
inputs_set |= mask;
}
else {
inputs_set = ~mask;
}
if (inputs_set == 7) {
done_bt-activate();
}
else {
done_bt-deactivate();
}
}
static void cb_input1(Fl_Input* in, void*) {
// input 1;
check_inputs_are_ready(in, 1);
}
static void cb_input2(Fl_Input* in, void*) {
// input 2;
check_inputs_are_ready(in, 2);
}
static void cb_input3(Fl_Input* in, void*) {
// input 3;
check_inputs_are_ready(in, 4);
}
static void cb_done_bt(Fl_Button*, void*) {
main_win-hide();
}
int main(int argc, char **argv) {
main_win = new Fl_Double_Window(348, 367, Activate Button Demo);
main_win-begin();
Fl_Input *input1 = new Fl_Input(130, 37, 200, 33, Enter Some Text);
input1-callback((Fl_Callback*)cb_input1);
input1-when(FL_WHEN_CHANGED);
Fl_Input *input2 = new Fl_Input(130, 124, 200, 33, Enter Some Text);
input2-callback((Fl_Callback*)cb_input2);
input2-when(FL_WHEN_CHANGED);
Fl_Input *input3 = new Fl_Input(130, 212, 200, 33, Enter Some Text);
input3-callback((Fl_Callback*)cb_input3);
input3-when(FL_WHEN_CHANGED);
done_bt = new Fl_Button(215, 285, 115, 65, Done);
done_bt-callback((Fl_Callback*)cb_done_bt);
done_bt-deactivate();
main_win-end();
main_win-show(argc, argv);
return Fl::run();
} // main
// end of file
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2918: fltk-config adds unneeded libraries
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2918 Version: 1.3-feature I can't see how this patch can be correct for the general case where the linked libs refferd to are needed... In the general case, XFT et al will be needed, so removing them from the link, as shown in this patch, seems wrong. Perhaps the OP's system does not use or provide these libs? That does seem odd though, nowadays, unless it is a cut down system, or embedded, or something? In any case, I suspect the problem lies elsewhere - probably makeinclude or configure should not be setting those libs into the @LIBS@ symbol, if they are not needed by the system. Anyone have a view on this? Link: http://www.fltk.org/str.php?L2918 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] GIF Image
On 17 Jan 2013, at 22:54, George wrote: I am trying to insert a gif into a window but even though i use FL_GIF_Image and even the picture is .gif , it' s still looking just like a normal static picture in the window. Fltk's built-in GIF handling does not support animated GIF's, only static GIF's. Somebody (maybe Albrecht? Can't recall now, it was a while ago...) did post patches to implement animated GIF's, but that was some time (years) ago, and there seemed to be no demand for that ability, so it never happened... Your best bet is probably to just make your own widget to unpack the frames from the GIF and then animate them - I don't have any code lying around for handling GIF's any more, so nothing to suggest there, but it is not that hard. For the animation, well, start with Greg's example here and see how you get on: http://seriss.com/people/erco/fltk/#Animate ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2816: Add ability to set proper window icons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature The patch looks OK to me, but I worry it may be ABI breaking? If so, we'll need to put ABI guards around it to stop it breaking any builds that are using dynamic loading of the fltk libs... Thoughts? Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2860: Multi-head full screen support
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2860 Version: 1.3-feature I quite like the idea of this patch, but do we need ABI guards around the new bits to prevent it breaking builds for folk using dynamic linking? Link: http://www.fltk.org/str.php?L2860 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2636: notification of clipboard changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature I think this would be useful - but it looks like an ABI-breaker to me (but what do I know!?) so maybe we need to defer it...? Thoughts? Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2816: Add ability to set proper window icons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature @Greg: Quite probably - I'm quite happy to be wrong about ABI issues here, which is really why I flagged it up, so that someone who knows what they are talking about (rarely me) can say! It seems worth having, so if it will fly right, we should do it... Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Nedit using fltk - Experimentation
On 16 Jan 2013, at 17:33, David FLEURY wrote: Hi, during my last vacation, I have tried to learn FLTK, so I decided to work on porting NEdit to FLTK. After my third attempt, I made this thing (I call it NEdit++). This is quite ugly - and buggy , my aim was just to see how to write GUI with FLTK. I have keep the old not UTF8 compliance of NEdit, but keep the rectangular selection (I use it quite often). The preferences is working (at least for me). I took me 2 weeks. This is really a partial port (may be less than 40% of the code - don't remember it was in august). Instead of letting dying this code on my disk, I have put it there, a rar and some screenshots under Win8 : http://hylvenir.free.fr/nedit/nedit.html If someone have the courage or the madness to look at it, and doing a full port of Nedit :) Umm, you do know that the core editor widget code in Fl_Text_Editor is the Nedit code? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Remove X11 dependency
On 16 Jan 2013, at 18:26, Lyubomyr wrote: Hello, I'm developing a program that should be able to run in environments that don't have X11 available. The program at start should check if x11 is available and if so then start FLTK based UI and CLI version otherwise. I was going to do something like that: 1) pass flag to linker to tell him that no need resolve all symbols now (-znodefs on Solaris) 2) On start check if X11 avaiable and load the library as well as resolve symbols on the run. 3) Use FLTK assuming that X11 was just loaded and resolved The problem is that while I successfully forced linker not to resolve all symbols while creating executable, on start it still is failed with: pre ld.so.1: erappd: fatal: relocation error: file bin/erapp/Solaris/x86_64/erappd: symbol XDestroyRegion: referenced symbol not found /pre Does anyone know what can be done in this case? Hmmm... Weak linking and so forth... well, it can get tricky. And it doesn't always work, and isn't always portable... I wonder if there might be an easier way? What I'm envisaging is a system where your code is in two parts: the CLI part, and a standalone GUI part. The idea is that the CLI part (with no X11 dependencies) would run first, and probe to see if the X11 libs are available. If so, it can fork the GUI part, and communicate with it via a pipe (or socket or etc.) If no X11 support is found, the CLI part just continues as normal, and the code that handles the GUI pipe now handles the console... maybe... That way, all the X11 dependencies are isolated in a (probably small) separate binary, and all should be well. Any use? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OpenGL + widgets
On 15 Jan 2013, at 01:20, Christopher James Huff wrote: On 2013-01-14 16:32:03 -0500, Ian MacArthur said: Is there an easy way to render a standard window to an image? It'd greatly streamline testing if I could do comparisons in the app itself. It's pretty easy to make a group that just renders to an offscreen buffer, then blit that buffer content onto another surface for display... I'll dig about, I think I have code for that somewhere... Turned out not to need the offscreen buffer, just read_image() was perfect for what I was doing. I now have a test application that shows the per-pixel difference between the OpenGL driver and whatever the native driver is. This is looking pretty cool already - I like it; though I'm not getting any time to look at it, my schedule is trashed right now. One trivial observation is that the use of FLU / flu as a namespace confused me, since there is already a (fltk-1.1) third-party add-onn lib called FLU, that I used to use quite a lot! Maintaining portability, particularly when we have to play well with the MS tools, and various embedded toolchains, means a pretty conservative lowest common denominator approach plays out best. Reasonable, but I find lambdas and some other C++11 features to be major improvements that have been long overdue in C++, and particularly useful in UI code, and any new projects I start are likely to make use of C++11. This library uses a mixin to overlay the lambda-friendly interface without modifications to FLTK itself. Indeed, and I have no issue with using new features in my own code, too. But for the core lib it is a problem; indeed I still support some embedded devices for which the only tool chain is based on gcc-2.95, so C++11 features are perhaps a bit beyond it! I'm sure other users are in the same situation, hence my caution about new features in the lib. Oh, now that's a thought - for the embedded targets, an EGL driver rather than a GL one, might be really neat too... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OpenGL + widgets
On 14 Jan 2013, at 20:10, Christopher James Huff wrote:
On 2013-01-13 17:32:52 -0500, Ian MacArthur said:
But I think an actual GL driver layer would work better... Though
handling of fonts might always be problematic - drawing TT fonts in
Windows GL is actually easier. MS did do some useful things after all!
I've now got a very incomplete but working implementation of an OpenGL
driver for FLTK3:
https://github.com/cjameshuff/fltkstuff
It's not clear how to actually *use* a different graphics driver, I'm
simply swapping my driver into fltk3::graphics_driver when drawing the
window, but this seems unlikely to be the correct way...suggestions? I
use the existing FLTK font stuff.
Best bet might be to see if we can get some input from Manolo here - he's did a
lot of work on the driver layer, particularly when getting the printing support
and etc. working, so he might have the clearest suggestions.
Is there an easy way to render a standard window to an image? It'd
greatly streamline testing if I could do comparisons in the app itself.
It's pretty easy to make a group that just renders to an offscreen buffer, then
blit that buffer content onto another surface for display... I'll dig about, I
think I have code for that somewhere...
There's also code for retrofitting FLTK with support for some C++11
features, in particular lambdas for callbacks and event handlers. The
OpenGL driver doesn't depend on this, but it may be of interest.
Yes, we talked a bit about lambdas, but the feeling was that they aren't an
instant win for us, and there's always the portability issue.
Maintaining portability, particularly when we have to play well with the MS
tools, and various embedded toolchains, means a pretty conservative lowest
common denominator approach plays out best.
Anyway, here's a possible offscreen example - it's not the one I was thinking
of, must be on a different machine, but the idea is the same!
/* Re: capture widget image - minimal example MacArthur, Ian (SELEX GALILEO,
UK)Feb 10, 2009
http://www.fltk.org/newsgroups.php?gfltk.general+v:27474
*/
// offscreen-grab.cxx
// fltk-config --compile offscreen-grab.cxx
#include FL/Fl.H
#include FL/x.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Group.H
#include FL/Fl_Button.H
#include FL/Fl_Scroll.H
#include Fl/fl_draw.h
// #include write_png.h
Fl_Offscreen offscr = 0;
int offscrW = 750;
int offscrH = 750;
class offscreen_group : public Fl_Group {
protected:
void draw( );
public:
offscreen_group(int X, int Y, int W, int H) :
Fl_Group(X,Y,W,H) { }
};
void offscreen_group::draw() {
int wo = w();
int ho = h();
if (!offscr) offscr = fl_create_offscreen(offscrW, offscrH);
if(!offscr) return; // create must have failed!
fl_begin_offscreen(offscr);
// draw the widget hierarchy of this group into the offscreen
Fl_Group::draw();
fl_end_offscreen();
// copy the offscreen back onto this window...
fl_copy_offscreen(0, 0, wo, ho, offscr, 0, 0);
}
/*/
uchar *data_p = NULL;
static void cb_bt_grab(Fl_Button*, void*)
{
if(offscr) { // offscreen exists, grab something
if(data_p){
delete[] data_p;
data_p = NULL;
}
fl_begin_offscreen(offscr); /* Open the offscreen context for
reading */
data_p = fl_read_image(data_p, 0, 0, offscrW, offscrH, 0);
// write_png(Test2.png, data_p, offscrW, offscrH, 3,
meta-data, comment);
fl_end_offscreen(); // close the offscreen context
}
} // cb_bt_grab
/*/
int main(int argc, char **argv) {
Fl_Double_Window *main_win = new Fl_Double_Window(450, 430,
Fl_Offscreen group test);
main_win-begin();
Fl_Button *grab_bt = new Fl_Button(405, 405, 40, 20, Grab);
grab_bt-callback((Fl_Callback*)cb_bt_grab);
Fl_Scroll *scroller = new Fl_Scroll(0,0,400,400);
scroller-begin();
offscreen_group *osg = new offscreen_group(0, 0, offscrW, offscrH);
osg-begin();
osg-box(FL_FLAT_BOX);
int a = 40, b = 40;
Fl_Button *b0;
while ((a + 60) offscrW)
{
b0 = new Fl_Button( a, b, 60, 60, BUTTON);
a += 60;
b += 60;
}
osg-end();
scroller-end();
main_win-end();
main_win-resizable(scroller);
main_win-show(argc, argv);
return Fl::run( );
}
/* end of file */
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
On 12 Jan 2013, at 03:17, Denton Thomas wrote: Using Fl_Window (Fl_Double_Window) + set_non_modal() is definitely easier, and does not hog input. Thanks for mentioning that, Ian. New problem, though. Test code is below. Regardless of what group/win type I use, mouse input will pass through the popup to the window/widgets below. This acts like an insertion-order thing. So, widget is drawn z-top, but it is z-below for input. I can fix the input order by making sure the other widget additions occur before the suggestion box. In my project, though, I can't control/guarantee the insertion order of the widget into the parent group ... so I'm a bit stumped. Ideas? I'll keep reading docs/threads ... (Without studying the sample code in all that much detail..) my initial reaction is that the creation of the Fl_Window based SuggestionBox widget as a member of your SuggestionInput widget, is causing it to be created as a sub-window of the main window, rather than a window in its own right and this is messing with the behaviour of the other widgets. If you can put the SuggestionBox browser in a pop-up window, rather than putting the pop-up windows inside the SuggestionBox, things might be simpler and make it easier to control the ordering of windows / events / etc...? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OpenGL + widgets
On 13 Jan 2013, at 20:59, Christopher James Huff wrote: Is there a recommended approach to drawing FLTK widgets inside or on top of an OpenGL window? Not as such... I see a few ways to approach this. The simplest way to get quick results seems to be to subclass widgets to provide OpenGL draw() methods and write an OpenGL window draw method that draws its children. And indeed Matthias has a demo doing exactly that, erm... somewhere... I can't find the link right now. This was code he put up years ago, but AFAIK it ought to still work fine with fltk-1.3. A more general but also more complex approach would be write an OpenGL output driver (has anyone else written such a thing already?), Which would be the preferred way, at least with fltk-1.3, if anyone could ever get around to writing the code... With fltk-1.3, the driver layer was abstracted away, with the specific intent of making it easier to implement alternate low-level code; obviously the initial intent was to make it easier to have the X11/WinXX/Cocoa and printing layers work, but the idea was always to make a GL layer (and others, e.g. framebuffer, whatever,) possible. But so far no one has had the time... A volunteer, they say, is worth 10 pressed men... (that's a hint, by the way, just in case you have a little time to throw at this - we'd appreciate it!) or somehow draw widgets to an image which is then drawn in OpenGL (could an existing driver easily be modified to do this?). Are there other options, or anything in particular to watch out for when doing one of these? This is also feasible, you'd use the existing drawing mechanisms to render to an off-screen buffer, then pass that buffer to the GL context for display, I guess. Note that *some* platforms (I think OSX for sure and maybe, IIRC, X11 in fltk2) use essentially this technique to render font faces in GL contexts, by drawing the glyphs (or in the OSX case entire strings) into a buffer then passing that to GL for rendering into the scene. But I think an actual GL driver layer would work better... Though handling of fonts might always be problematic - drawing TT fonts in Windows GL is actually easier. MS did do some useful things after all! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Amalgamation
On 2 Jan 2013, at 11:08, superbem wrote: Happy new year! Another very nice feature regarding amalgamation, to the Fluid, would be a feature to have an generate code option to produce an amalgamation with the widgets used, then it includes the code on 3 files, the 2 as it are already now, then on the main one, include de generated sub amalgamation, instead the include pointers. That way the size isn't any more an issue. And very portable. As an option would be great. Something like that might be an interesting feature, more like modularization than strictly amalgamation - reminiscent of what JUCE's infojuicer can do with its modules in many ways. We'd probably still need some metadata for the widgets classes so we could resolve the dependencies quickly, so possibly non-trivial to implement. It may be possible to auto-generate the dependencies though? Might need a bit of though... Anyway, if you have patches to implement this, please post them on an STR so we can take a look. Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Time out Reentrance on Windows
On 2 Jan 2013, at 11:12, claude roux wrote:
Hello,
The way I use FLTK encompasses some level of re-entrance. However, I
discovered a little problem in the way add_timeout is used on Windows. If I
initialize a first timeout, it works like a charm... If I try to relaunch a
new timeout within the same application, then it does not work anymore.
I have investigated a little bit, and I have discovered that in order to
re-use a timer in the same application, I needed to reset the value of
s_TimerWnd to 0 in fl_win32.cxx.
For the moment, I have implemented a small function, which does that (the
variable is static)
void FlResetTimer() {
if (s_TimerWnd)
s_TimerWnd=0;
}
I suppose there is a better way to have this variable reset in a different
place, but for the moment, it seems to suffice.
Hm, I'm not keen on that approach - it looks to me as if it is cancelling the
timer, but not clearing out the action associated with timer, which may be
messy down the line.
I think the preferred approach, if you may have reentrancy on your timers, is
just to call Fl::remove_timeout() first, before you re-add it. Note that
calling Fl::remove_timeout() on a not-added timer is harmless.
Though, to be honest, where I've hit this issue, I've just had a state variable
that I check before doing the add call; if it is clear I add the timer and set
the flag. If it is already set, I can decide whether to remove it, or to allow
the extant timer event to occur.
The flag is of course cleared by the function that runs when the timer fires.
Since the code is pretty much single threaded, this is more or less safe...!
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 2 Jan 2013, at 12:14, Albrecht Schlosser wrote: Yep, that's also correct, but fortunately normal FLTK widgets don't *use* the navigation keys. Hence, navigation key events usually return zero from the widget's handle() method, and the group gets it. Ah, but there's a thought... If Denton has already modified his widgets to handle the focus differently, then they may perhaps be eating the nav events, thus preventing them from propagating to the container scroll widget at all? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Time out Reentrance on Windows
On 2 Jan 2013, at 13:30, claude roux wrote: However, after reading your response, I came to realize that one specificity of my implementation is that the FLTK main loop is launched within a thread, which is usually OK for most things, except as it appears for the timeout (and also as I have recently discovered for awake, which is no longer invoked if Fl::run is not in the main thread, which is pretty logical, actually)... Ah... Hm, well, I have to say I would recommend against that. It throws up some very strange and inconsistent behaviours across platforms. In particular, the behaviour on WinXX systems is quite inconsistent, and can vary a lot form windows version to version (I guess MS changed things internally as they went along - though later versions seem better than older ones, as a general handwave impression, i.e. Win7 is less flaky than WinXP if your run thongs from a child thread. Well, maybe...) Though, for what it is worth, I have a colleague who has a large and complex Windows-only app written in fltk that, due to the odd way it is initiated, in effect runs the fltk loop from a child thread (i.e. not the main() thread) and it does work OK. (Though I keep suggesting he change it, and perhaps he has done now!) In particular, though, he has seen episodes where the behaviour of the app is erratic on some machines and good on others (the suspicion is that the different graphics drivers may be behind this, though that is uncertain...) Anyway, I guess what I'm saying is that, if you really want to go this way, then test your code on as many *different* host machines with as many different graphics drivers and host OS versions as possible, as I suspect that even though it works fine one your dev machines it may not work for your end users! Just a word of caution... -- Ian ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
