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
Attached file gtk-browser2.patch...
Link: http://www.fltk.org/str.php?L2904
Version: 1.3-featureIndex: src/Fl_Native_File_Chooser_GTK.cxx
===
--- src/Fl_Native_File_Chooser_GTK.cxx (revision 0)
+++ src/Fl_Native_File_Chooser_GTK.cxx (revision 0)
@@ -0,0 +1,626 @@
+// $Id: $
+//
+// FLTK native file chooser widget wrapper for GTK's GtkFileChooserDialog
+//
+// Copyright 1998-2013 by Bill Spitzak and others.
+// Copyright 2012 IMM
+//
+// This library is free software. Distribution and use rights are outlined in
+// the file COPYING which should have been included with this file. If this
+// file is missing or damaged, see the license at:
+//
+// http://www.fltk.org/COPYING.php
+//
+// Please report all bugs and problems to:
+//
+// http://www.fltk.org/str.php
+//
+
+# include dlfcn.h // for dlopen et al
+# include locale.h // for setlocale
+
+/* - Type definitions from GLIB and GTK
- */
+/* all of this is from the public gnome API, so unlikely to change */
+#ifndefFALSE
+#defineFALSE (0)
+#endif
+#ifndefTRUE
+#defineTRUE(!FALSE)
+#endif
+typedef void* gpointer;
+typedef intgint;
+typedef unsigned intguint;
+typedef unsigned long gulong;
+typedef gint gboolean;
+typedef char gchar;
+typedef struct _GSList GSList;
+struct _GSList
+{
+ gpointer data;
+ GSList *next;
+};
+#define g_slist_next(slist)((slist) ? (((GSList *)(slist))-next)
: NULL)
+typedef struct _GtkWidget GtkWidget;
+typedef struct _GtkFileChooser GtkFileChooser;
+typedef struct _GtkDialogGtkDialog;
+typedef struct _GtkWindow GtkWindow;
+typedef struct _GtkFileFilter GtkFileFilter;
+typedef struct _GtkToggleButton GtkToggleButton;
+typedef enum {
+ GTK_FILE_FILTER_FILENAME = 1 0,
+ GTK_FILE_FILTER_URI = 1 1,
+ GTK_FILE_FILTER_DISPLAY_NAME = 1 2,
+ GTK_FILE_FILTER_MIME_TYPE= 1 3
+} GtkFileFilterFlags;
+struct _GtkFileFilterInfo
+{
+ GtkFileFilterFlags contains;
+
+ const gchar *filename;
+ const gchar *uri;
+ const gchar *display_name;
+ const gchar *mime_type;
+};
+typedef struct _GtkFileFilterInfo GtkFileFilterInfo;
+typedef gboolean (*GtkFileFilterFunc) (const GtkFileFilterInfo *filter_info,
gpointer data);
+typedef void (*GDestroyNotify)(gpointer data);
+typedef enum
+{
+ GTK_FILE_CHOOSER_ACTION_OPEN,
+ GTK_FILE_CHOOSER_ACTION_SAVE,
+ GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER,
+ GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER
+} GtkFileChooserAction;
+#define GTK_STOCK_CANCEL gtk-cancel
+#define GTK_STOCK_SAVE gtk-save
+#define GTK_STOCK_OPEN gtk-open
+const int GTK_RESPONSE_ACCEPT = -3;
+const int GTK_RESPONSE_CANCEL = -6;
+typedef void (*GCallback)(void);
+#defineG_CALLBACK(f)((GCallback) (f))
+typedef int GConnectFlags;
+typedef struct _GClosureGClosure;
+typedef void (*GClosureNotify)(gpointer data, GClosure*closure);
+
+/* - End of Type definitions from GLIB and GTK
- */
+
+int Fl_GTK_File_Chooser::did_find_GTK_libs = 0;
+
+/* These are the GTK/GLib methods we want to load, but not call by name...! */
+
+// void g_free (gpointer mem);
+typedef void (*XX_g_free)(gpointer);
+static XX_g_free fl_g_free = NULL;
+
+// gpointer g_slist_nth_data (GSList *list, guint n);
+typedef gpointer (*XX_g_slist_nth_data) (GSList *, guint);
+static XX_g_slist_nth_data fl_g_slist_nth_data = NULL;
+
+// guint g_slist_length (GSList *list);
+typedef guint (*XX_g_slist_length) (GSList *);
+static XX_g_slist_length fl_g_slist_length = NULL;
+
+// void g_slist_free (GSList *list);
+typedef void (*XX_g_slist_free) (GSList *);
+static XX_g_slist_free fl_g_slist_free = NULL;
+
+// gboolean gtk_init_check (int *argc, char ***argv);
+typedef gboolean (*XX_gtk_init_check)(int *, char ***);
+static XX_gtk_init_check fl_gtk_init_check = NULL;
+
+// void gtk_widget_destroy (GtkWidget *widget);
+typedef void (*XX_gtk_widget_destroy) (GtkWidget *);
+static XX_gtk_widget_destroy fl_gtk_widget_destroy = NULL;
+
+// void gtk_file_chooser_set_select_multiple(GtkFileChooser *chooser, gboolean
select_multiple);
+typedef void (*XX_gtk_file_chooser_set_select_multiple)(GtkFileChooser *,
gboolean);
+static XX_gtk_file_chooser_set_select_multiple
fl_gtk_file_chooser_set_select_multiple = NULL;
+
+// void gtk_file_chooser_set_do_overwrite_confirmation(GtkFileChooser
*chooser, gboolean do_overwrite_confirmation);
+typedef void
(*XX_gtk_file_chooser_set_do_overwrite_confirmation)(GtkFileChooser *,
gboolean);
+static XX_gtk_file_chooser_set_do_overwrite_confirmation
fl_gtk_file_chooser_set_do_overwrite_confirmation = NULL;
+
+// void
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 Uploaded gtk-browser2.patch with a somewhat cleaner implementation that separates the FLTK and GTK browsers in two classes and two source files. 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
AFAIK kdialog is often distributed with KDE, which isn't the case for zenity/Gnome. 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... There is a env variable XDG_CURRENT_DESKTOP and should indicate the name of running desktop; however, the variable was added silently (which is unfortunate) by Canonical, RedHat, who knows, and there is no definitive spec about it on freedesktop.org. You can check how it is used (with a couple of hacks for other desktops) at http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-utils-common.in (search for 'detectDE'). Also to not forget 'xdg-file-dialog' intended to be portable among desktops and if another desktop adds a tool like kdialog, it will probably end up there. On Sun, Feb 17, 2013 at 01:35:46PM -0800, Ian MacArthur 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
Re: [fltk.development] [RFE] STR #2904: Native file chooserisn'texactly native on linux
On 02/17/13 17:25, Michael Sweet wrote: 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... I guess we have that problem already with fl_open_uri(), and actually should document that it may start a child process, and all that might entail (such as SIGCHLD and wait() on unix) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] OT: Making application run once
On 17.02.2013 16:57, Ian MacArthur wrote: I used named pipes to do this, since they work ok on WIN32 as well as *nix OSX. My app tests for the presence of the named pipe on launch; if not found it launches a full instance creates the pipe... If found, a little helper function just writes the new file instance onto the pipe then terminates. The main app monitors the incoming pipe for actions, albeit as a low priority background thread. Seems to work ok, but was a bit of messing about with platform specific code to get the pipes to work transparently across platforms. There's probably a better way though! Maybe not better, but for some reasons easier to implement, at least for me: I used a local TCP socket and Fl::add_fd() for this. PRO: platform independent implementation, and Fl::add_fd() works even on Windows, where Fl::add_fd() is restricted to sockets. This was the main argument to do it this way. Also, no threads required. CON: you need a fixed local socket number for it to work. A named pipe would be more flexible (arbitrary NAME vs. socket NUMBER). The app first tries to connect to the socket, and if it exists, sends a message and exits. If it doesn't exist, then this is the first instance of the app. It creates a local server socket and registers it with Fl::add_fd() to watch it. Whenever a new app is started, a callback is triggered in the first instance, since the other instance writes to the socket. The first instance then reads the message from the socket... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
How would I go about coding this? Pipes? Sockets? None of the above. AFAIK mutex or semaphore are ment to realise this. Well, maybe not - a lock file (or in my case a named pipe) can be a better bet, since it will work across processes on all platforms, whereas not all hosts systems will support mutexes across processes in that way... This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
On 18.02.2013 11:12, MacArthur, Ian (Selex ES, UK) wrote: There's probably a better way though! Maybe not better, but for some reasons easier to implement, at least for me: I used a local TCP socket and Fl::add_fd() for this. PRO: platform independent implementation, and Fl::add_fd() works even on Windows, where Fl::add_fd() is restricted to sockets. This was the main argument to do it this way. Also, no threads required. Yes: though my code was threaded anyway, so there wasn't a big cost for me in going this way. I knew that, and that's why I wrote at least for me ;-) It would have been nice if Fl::add_fd() worked on pipes on WIN32 though... Yep, and files as well. CON: you need a fixed local socket number for it to work. A named pipe would be more flexible (arbitrary NAME vs. socket NUMBER). Not quite an arbitrary name though - I had to figure out a recipe whereby the new process would figure out the same name as any prior process, so that it could look for the name at runtime... My emphasis was on NAME vs. NUMBER, and what you can select the name|number from. This way, I still consider the selection of a name for a pipe arbitrary, since the name space is much bigger than a number range from 1024 to 65535 for non-priviledged TCP sockets. Of course, all processes must agree about the same name if they want to communicate... I made something up based on user name, the dir in which the executable resided, and, erm, some other stuff... That seems to work, and means that if two users are on the same machine they get one instance each, rather than just one instance between them. Which was what I wanted. Yes, I didn't consider different users on the same system (client PC), since Windows was the main target, and single user Linux workstations were a secondary target. However, if I'd get the task to make it work for different users on the same system, maybe Linux workstations/servers with remote (X) access, then I'd probably utilize Fl_Preferences for saving the socket number (or pipe name, or ...), since Fl_Preferences is user specific. You must still take care that it is unique, and _your_ app probably predates the addition of Fl_Preferences to FLTK, but you know what I mean. For some sort of server process, maybe one instance for all users would be more appropriate, though? Sure, however in my constellation it's a GUI (FLTK) program, and so one instance per user would be the way to go, too, if there could be more than one user on a client PC. It would even be more complicated, if more than one _person_ could access the same system with the same _user_ name from different remote workstations. Not really something you'd want, but in real life ... :-( The app first tries to connect to the socket, and if it exists, sends a message and exits. If it doesn't exist, then this is the first instance of the app. It creates a local server socket and registers it with Fl::add_fd() to watch it. Whenever a new app is started, a callback is triggered in the first instance, since the other instance writes to the socket. The first instance then reads the message from the socket... Yup - sounds familiar... Only I didn't have the convenience of a working Fl::add_fd() method to help out, so I have a helper thread that just blocks on the pipe, and only ever runs if there is something there to read. Same principle, of course... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
Ian MacArthur wrote:
Michael Baeuerle wrote:
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)
Yes, my fault. I have ripped out the original FLTK preprocessor stuff
(because my demo don't use autoconf) and forget to insert '#include
string.h' instead.
- Added -Wall to the Makefile, just in case, but it didn't flag much
of note, other than...
Some commercial compilers (like the SunPro) don't understand -Wall,
therefore I have left it out for the demo.
- 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!)
AFAIK MacOS X has a BSD based userland. I have seen the same thing while
testing on NetBSD, there are two native 'scandir()' implementations in
libc and only one works (but both hasn't POSIX compliant parameter
declarations).
The problem here is that we requested something that in fact the system
don't claim to provide. I have modfied the Makefile so that the native
test is only build if the system claims to be POSIX.1-2008 compliant.
Recent GNU/Linux distributions do that.
The feature request in 'scandir_new.c' was also wrong and give warnings
on SunOS with threads enabled. I have corrected it and now it runs
cleanly on SunOS too (with and without threads).
BTW: Oracle has some documentation of the values for older standards:
http://docs.oracle.com/cd/E19963-01/html/821-1474/standards-5.html
Finally I have run the new implementation on Valgrind and found no
further errors.
http://micha.freeshell.org/tmp/2013-02-18_scandir.tar.gz
To include the new code into FLTK I would consider the following things:
1) Import new code to 'src/scandir.c'
2) Change function name from 'scandir_new()' to 'fl_scandir()'
3) '#include ../config.h' at the beginning so that 'HAVE_PTHREAD'
from autoconf becomes visible.
The feature test macros must stay before the first '#include'
of a system header file to work correctly
4) Ensure that 'src/scandir.c' is not build with a C++ compiler
(Looks like this is already the case)
5) List the FLTK license text in the header instead of hyperlink
6) Change the switching code in 'src/filename_list.cxx' like this:
--
extern C {
#ifndef HAVE_SCANDIR
int fl_scandir (const char *dir, dirent ***namelist,
int (*select)(dirent *),
int (*compar)(dirent **, dirent **));
#endif
}
...
#ifndef HAVE_SCANDIR
// This version is when we define our own scandir
int n = fl_scandir(dirloc, list, 0, sort);
--
should become something like this:
--
extern C {
#ifndef HAVE_SCANDIR
int fl_scandir (const char *dir, struct dirent ***namelist,
int (*sel)(const struct dirent *),
int (*compar)(const struct dirent **, const struct dirent **));
#endif
}
...
#ifndef HAVE_SCANDIR
// This version is when we define our own scandir
int n = fl_scandir(dirloc, list, 0, (int(*)(const struct dirent **,
const struct dirent **)) sort);
--
Regards,
Micha
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
To include the new code into FLTK I would consider the following
things:
1) Import new code to 'src/scandir.c'
Yes - I guess this takes it back to being similar to
what it was prior to STR #2687 or so...
2) Change function name from 'scandir_new()' to 'fl_scandir()'
3) '#include ../config.h' at the beginning so that 'HAVE_PTHREAD'
from autoconf becomes visible.
The feature test macros must stay before the first '#include'
of a system header file to work correctly
4) Ensure that 'src/scandir.c' is not build with a C++ compiler
(Looks like this is already the case)
Yes, the fltk Makefile ought to be doing this right already
5) List the FLTK license text in the header instead of hyperlink
6) Change the switching code in 'src/filename_list.cxx' like this:
--
extern C {
#ifndef HAVE_SCANDIR
int fl_scandir (const char *dir, dirent ***namelist,
int (*select)(dirent *),
int (*compar)(dirent **, dirent **));
#endif
}
...
#ifndef HAVE_SCANDIR
// This version is when we define our own scandir
int n = fl_scandir(dirloc, list, 0, sort);
--
should become something like this:
--
extern C {
#ifndef HAVE_SCANDIR
int fl_scandir (const char *dir, struct dirent ***namelist,
int (*sel)(const struct dirent *),
int (*compar)(const struct dirent **, const struct dirent **));
#endif
}
...
#ifndef HAVE_SCANDIR
// This version is when we define our own scandir
int n = fl_scandir(dirloc, list, 0, (int(*)(const struct dirent **,
const struct dirent **)) sort);
--
Though we need to be cautious about not breaking
the alternate implementation of fl_scandir()
given in scandir_win32.c also.
Maybe the win32 version needs tweaked to match
the more const-correct prototype anyway?
Anyway - if you have the bits for this working, would
it be possible for you to create an STR and upload the
files there?
Just so we keep a record of all this stuff...
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
MacArthur, Ian (Selex ES, UK) wrote: To include the new code into FLTK I would consider the following things: 1) Import new code to 'src/scandir.c' Yes - I guess this takes it back to being similar to what it was prior to STR #2687 or so... I have added the new code to 'scandir_posix.c'. 'scandir.c' now includes nothing, 'scandir_posix.c' or 'scandir_win32.c'. This way it should be more obvious what is happening. [...] 6) Change the switching code in 'src/filename_list.cxx' like this: [...] Though we need to be cautious about not breaking the alternate implementation of fl_scandir() given in scandir_win32.c also. Maybe the win32 version needs tweaked to match the more const-correct prototype anyway? I have made the default prototypes for all 'scandir()'s and the sort functions to be POSIX compliant. Leaving typecasts only for the cases this doesn't match. Anyway - if you have the bits for this working, would it be possible for you to create an STR and upload the files there? After testing it inside the source tree I will open an STR. Regards, Micha ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
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.opengl] How to enable Drag n Drop on OpenGL window ?
Thanks UWE, I tried but no success, still the same. File only accepted when drop over the Fl_Double_Window. Here is my code.. MainWindow-begin(); // Fl_Double_Window DnDReceiver b(0,0,WINDOW_SIZE_W, WINDOW_SIZE_H); // Drag n Drop Box glutInitDisplayMode (GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH | GLUT_ACCUM | GLUT_ALPHA | GLUT_STENCIL | GLUT_MULTISAMPLE); GLUT_MAIN_WINDOW = glutCreateWindow(RACS_VERSION); MainWindow-end(); MainWindow-show(argc, argv); I tried to put DnDReceiver box before, after, middle, everywhere, inside of begin and end of Fl_Double_Window but no success. Please guide me Where to put DnDReceiver box in the code. thanks. Am 18.02.2013 08:52, schrieb Furqan: 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 ? You can place a invisible widget e.g. Fl_Box with the attribute Fl_No_Box over the whole application, which just recieves DD events like in your described even handler and filters only these. All other events from mouse, keyboard etc. should pass to get handled as usual by the appropriate widgets. kind regards Kai-Uwe ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
