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
