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-browser.patch...
Link: http://www.fltk.org/str.php?L2904
Version: 1.3-featureIndex: src/fl_gtk.h
===
--- src/fl_gtk.h(revision 0)
+++ src/fl_gtk.h(revision 0)
@@ -0,0 +1,66 @@
+/* - 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
- */
+
+
Index: src/Fl_Native_File_Chooser_FLTK.cxx
===
--- src/Fl_Native_File_Chooser_FLTK.cxx (revision 9729)
+++ src/Fl_Native_File_Chooser_FLTK.cxx (working copy)
@@ -1,10 +1,9 @@
// $Id$
//
-// FLTK native OS file chooser widget
+// FLTK native file chooser widget wrapper for GTK's GtkFileChooserDialog
//
-// Copyright 1998-2010 by Bill Spitzak and others.
-// Copyright 2004 Greg Ercolano.
-// API changes + filter improvements by Nathan Vander Wilt 2005
+// 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
@@ -28,21 +27,272 @@
#include sys/stat.h
#include string.h
+static int did_find_GTK_libs = 0;
+
+#ifdef _TEST_GTK_FILE_CHOOSER
+# warning Test code for GTK file chooser
+# include fl_gtk.h
+# include dlfcn.h // for dlopen et al
+# include locale.h // for setlocale
+
+
+static int have_looked_for_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
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 The attached gtk-browser.patch modifies the current svn repository so that Fl_Native_File_Chooser uses the GTK dialog when libgtk2-or-3.so is available at run time, and falls back on Fl_File_Chooser when it's not. Most of the new code is Ian's work. As set here, no change in the library configuration is needed, no option needs to be turned on neither. This corresponds to the logic Fl_Native_File_Chooser does something different from Fl_File_Chooser when possible. A less drastic modification of FLTK could be to have _TEST_GTK_FILE_CHOOSER optionally turned on at configure time. The demo program test/native-filechooser.cxx is modified (Ian did it, really) to exercize all file chooser dialog flavors (open, save, directory,...) in turn. The patch creates a new file (src/fl_gtk.h) containing all useful type declarations from gtk/gtk.h. This avoids altogether to modify the configure mechanism. I believe this unorthodox procedure is safe because all declarations therein are part of the gnome public API (see http://developer.gnome.org). The patch also modifies FL/Fl_Native_File_Chooser.H somewhat and src/Fl_Native_File_Chooser.cxx extensively. I found this works well on Linux/Debian and Darwin/X11. It's probably necessary to test it on other Linux distros. 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.general] OT: Making application run once
I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
Hi, If you are going to run your program on Linux/Unix, you can use DBus and it's feature to assign unique name to connected client; example of this you can find at: http://sundaram.wordpress.com/2010/01/08/single-instance-apps-using-d-bus/ However, if you are thinking to make it OS inferior or simply to omit DBus, you can create hidden so called 'lock' file at known location when application starts (e.g. /tmp/.foo.lock) and delete it when application quits; the same application will check if that file exists and if does, report how one instance is already running. Sanel On Sat, Feb 16, 2013 at 05:10:11AM -0800, Gonzalo Garramuno wrote: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
Am 16.02.2013 14:10, schrieb Gonzalo Garramuno: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. For OS independence I would use: http://www.fltk.org/doc-1.3/classFl__Preferences.html together with repeat_timeout( cb ) it should be fine http://www.fltk.org/doc-1.3/classFl.html#ae5373d1d50c2b0ba38280d78bb6d2628 Application reads the lock key and if none exists, writes a new lock key containing e.g. a PID. Second instance reads the lock key, checks if the PID exists and writes a command key with instructions for the first instance and quits. The first instance polls through repeat_timeout() the command key and does what it needs. On exit the first application deletes the lock key. hope this helps Kai-Uwe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
On 02/16/13 05:10, Gonzalo Garramuno wrote: I would like my application to have only one instance of it running at a time. However I am unsure how to implement this. If the user opens another instance the contents of what it opened should go to the already opened instance. As an example, I would put emacs. How would I go about coding this? Pipes? Sockets? None of the above. Sniffing around a bit, I believe the terminology to search for is single instance application, and SDI (Single Document Interface), the latter usually using the former. I'm not sure offhand what the 'right approach' is, esp for a cross platform app other than to probably find and use an existing cross platform toolkit that handles this for you. Likely such toolkits use sockets or named pipes. Microsoft has docs on this (I don't necessarily recommend the technique they recommend here, but just FYI to show the terminology they use): http://msdn.microsoft.com/en-us/library/ms996475.aspx#reaworapps1_topic5 Qt has a class to handle this called QtSingleApplication, ie: http://doc.qt.digia.com/solutions/4/qtsingleapplication/qtsingleapplication.html#details ..you might want to look at its innards for implementation, as it likely does what you want cross platform. From what I can tell, there are cross platform toolkits out there already that can implement this for you, but I can't refer to any as I don't know which ones to recommend. Or just roll your own, and create a ~/.yourapp-lock file, and as Kai-Uwe says, either use that file to write commands, or use a named pipe like the lp daemon does, or use a socket. The lock file should have a pid in it (as KU mentions) and info on how to contact it (socket port#, named pipe filename etc) or just make the lock file the named pipe. Both unix and windows support named pipes, and although the APIs are not the same. Some info here: http://en.wikipedia.org/wiki/Named_pipe ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
