[fltk.commit] [WWW] r686 - trunk
Author: matt Date: 2013-02-17 04:03:51 -0800 (Sun, 17 Feb 2013) New Revision: 686 Log: Temporarily removed nightly builds. I am moving, taing the servers with. It will likely take two weeks until I can go back online. Modified: trunk/index.php Modified: trunk/index.php === --- trunk/index.php 2012-12-10 12:09:50 UTC (rev 685) +++ trunk/index.php 2013-02-17 12:03:51 UTC (rev 686) @@ -56,8 +56,10 @@ . $revisions[fltk-3.0.x] . 'v3.0.x-r . $revisions[fltk-3.0.x] . /a/td/tr); ? +!-- trtd align='right' nowrapNightly Builds::/td tda href='http://evbuilder.de/jenkins'View Link/a/td/tr +-- trtd align='right' nowrapDeveloper Roadmap:/td tda href='roadmap.php'View/a/td/tr /table ___ fltk-commit mailing list fltk-commit@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-commit
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
Has anybody looked at exec'ing zenity or kdialog, etc? On 02/15/2013 05:16 PM, Greg Ercolano wrote: 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 Thanks Manolo! Nice addition. Would be great if you could document any gtk/linux specifics for use of FNFC in the docs, and try to hit on: o How to trigger the GTK behavior (ie. macro names if any) o Any special linking instructions for the app (static+dynamic) Assuming you already have a simple test program you've been using to test the gtk + FNFC, might I suggest adding your test app to the examples as perhaps: examples/nativefilechooser-linux-gtk.cxx Adding examples is easy; just add the .cxx file, and make a small mod to examples/Makefile so that it builds. No visual studio files needed. See the examples/README.examples for coding suggs. 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.development] [RFE] STR #2904: Native file chooser isn'texactly native on linux
There is also the issue of how to safely execute programs from the library; it is incredibly difficult to safely deal with file descriptors and signals/handlers from a library without some coordination with the application... On 2013-02-17, at 4:35 PM, Ian MacArthur imacart...@gmail.com wrote: 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 _ Michael Sweet ___ 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] OT: Making application run once
Gonzalo Garramuno schrieb: I would like my application to have only one instance of it running at a time. How would I go about coding this? Pipes? Sockets? None of the above. AFAIK mutex or semaphore are ment to realise this. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.opengl] How to enable Drag n Drop on OpenGL window ?
My application is OpenGL based. I have created an OpenGL windows inside of
Fl_Double_Window.
Now here is the simple code for drag n drop, copied from an example.
// SIMPLE RECEIVER CLASS
class Receiver : public Fl_Box {
public:
// Ctor
Receiver(int x,int y,int w,int h) : Fl_Box(x,y,w,h) {
box(FL_FLAT_BOX); color(10); label(..to\nhere);
}
// Receiver event handler
int handle(int event) {
int ret = Fl_Box::handle(event);
switch ( event ) {
case FL_DND_ENTER: // return(1) for these events to 'accept' dnd
case FL_DND_DRAG:
case FL_DND_RELEASE:
ret = 1;
break;
case FL_PASTE: // handle actual drop (paste) operation
label(Fl::event_text());
fprintf(stderr, Pasted '%s'\n, Fl::event_text());
ret = 1;
break;
}
return(ret);
}
};
In my application I code like this..
MainWindow = new Fl_Double_Window(WINDOW_SIZE_W, WINDOW_SIZE_H, );
Receiver box(0,0,WINDOW_SIZE_W, WINDOW_SIZE_H);
MainWindow-end();
MainWindow-show(argc, argv);
Now the issue is, when I drag n drop one file over the OpenGL screen it doesn't
accept the file. File only accepted if I drop on the Receiver box. But my
application screen is totally covered with the OpenGL screen, so, how can I
enable Drag n Drop on the OpenGL screen ?
Any idea ?
thanks.
furqan
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
