Re: [fltk.development] [RFE] STR #2636: notification of clipboard changes

2013-01-31 Thread Pierre Ossman
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


Attached file fltk-1_v5.3.x-clipboard-x11.patch...


Link: http://www.fltk.org/str.php?L2636
Version: 1.4-featurediff -up fltk-1.3.2/CMakeLists.txt.clp-x11 fltk-1.3.2/CMakeLists.txt
--- fltk-1.3.2/CMakeLists.txt.clp-x11   2012-09-13 16:19:01.0 +0200
+++ fltk-1.3.2/CMakeLists.txt   2013-01-30 15:56:25.810663430 +0100
@@ -515,6 +515,20 @@ else()
 endif(OPTION_USE_XINERAMA)
 
 ###
+if(X11_Xfixes_FOUND)
+   option(OPTION_USE_XFIXES use lib XFIXES ON)
+endif(X11_Xfixes_FOUND)
+
+if(OPTION_USE_XFIXES)
+   set(HAVE_XFIXES ${X11_Xfixes_FOUND})
+   include_directories(${X11_Xfixes_INCLUDE_PATH})
+   list(APPEND FLTK_LDLIBS -lXfixes)
+   set(FLTK_XFIXES_FOUND TRUE)
+else()
+   set(FLTK_XFIXES_FOUND FALSE)
+endif(OPTION_USE_XFIXES)
+
+###
 if(X11_Xft_FOUND)
option(OPTION_USE_XFT use lib Xft ON)
 endif(X11_Xft_FOUND)
diff -up fltk-1.3.2/configh.cmake.in.clp-x11 fltk-1.3.2/configh.cmake.in
--- fltk-1.3.2/configh.cmake.in.clp-x11 2011-07-19 06:49:30.0 +0200
+++ fltk-1.3.2/configh.cmake.in 2013-01-30 15:56:25.810663430 +0100
@@ -108,6 +108,14 @@
 #define USE_XDBE HAVE_XDBE
 
 /*
+ * HAVE_XFIXES:
+ *
+ * Do we have the X fixes extension?
+ */
+
+#cmakedefine01 HAVE_XFIXES
+
+/*
  * __APPLE_QUARTZ__:
  *
  * If __APPLE_QUARTZ__ is defined, FLTK will be
diff -up fltk-1.3.2/configh.in.clp-x11 fltk-1.3.2/configh.in
--- fltk-1.3.2/configh.in.clp-x11   2011-10-04 11:21:47.0 +0200
+++ fltk-1.3.2/configh.in   2013-01-30 15:56:25.810663430 +0100
@@ -108,6 +108,14 @@
 #define USE_XDBE HAVE_XDBE
 
 /*
+ * HAVE_XFIXES:
+ *
+ * Do we have the X fixes extension?
+ */
+
+#define HAVE_XFIXES 0
+
+/*
  * __APPLE_QUARTZ__:
  *
  * All Apple implementations are now based on Quartz and Cocoa,
diff -up fltk-1.3.2/configure.in.clp-x11 fltk-1.3.2/configure.in
--- fltk-1.3.2/configure.in.clp-x11 2013-01-30 15:56:25.802663573 +0100
+++ fltk-1.3.2/configure.in 2013-01-30 15:56:25.810663430 +0100
@@ -999,6 +999,16 @@ case $uname_GUI in
LIBS=-lXext $LIBS)
fi
 
+   dnl Check for the Xfixes extension unless disabled...
+AC_ARG_ENABLE(xfixes, [  --enable-xfixes   turn on Xfixes support 
[default=yes]])
+
+   if test x$enable_xfixes != xno; then
+   AC_CHECK_HEADER(X11/extensions/Xfixes.h, AC_DEFINE(HAVE_XFIXES),,
+   [#include X11/Xlib.h])
+   AC_CHECK_LIB(Xfixes, XFixesQueryExtension,
+   LIBS=-lXfixes $LIBS)
+   fi
+
dnl Check for overlay visuals...
AC_PATH_PROG(XPROP, xprop)
AC_CACHE_CHECK(for X overlay visuals, ac_cv_have_overlay,
diff -up fltk-1.3.2/fluid/CMakeLists.txt.clp-x11 fltk-1.3.2/fluid/CMakeLists.txt
diff -up fltk-1.3.2/src/CMakeLists.txt.clp-x11 fltk-1.3.2/src/CMakeLists.txt
--- fltk-1.3.2/src/CMakeLists.txt.clp-x11   2013-01-30 16:06:00.785430590 
+0100
+++ fltk-1.3.2/src/CMakeLists.txt   2013-01-30 16:06:17.883126642 +0100
@@ -243,6 +243,10 @@ if(HAVE_XINERAMA)
target_link_libraries(fltk ${X11_Xinerama_LIB})
 endif(HAVE_XINERAMA)
 
+if(HAVE_XFIXES)
+   target_link_libraries(fltk ${X11_Xfixes_LIB})
+endif(HAVE_XFIXES)
+
 if(USE_XFT)
target_link_libraries(fltk ${X11_Xft_LIB})
 endif(USE_XFT)
diff -up fltk-1.3.2/src/Fl_x.cxx.clp-x11 fltk-1.3.2/src/Fl_x.cxx
--- fltk-1.3.2/src/Fl_x.cxx.clp-x11 2013-01-30 15:56:25.793663733 +0100
+++ fltk-1.3.2/src/Fl_x.cxx 2013-01-30 16:03:37.355981103 +0100
@@ -53,6 +53,12 @@ static XRRUpdateConfiguration_type XRRUp
 static int randrEventBase;  // base of RandR-defined events
 #endif
 
+#  if HAVE_XFIXES
+#  include X11/extensions/Xfixes.h
+static int xfixes_event_base = 0;
+static bool have_xfixes = false;
+#  endif
+
 static Fl_Xlib_Graphics_Driver fl_xlib_driver;
 static Fl_Display_Device fl_xlib_display(fl_xlib_driver);
 Fl_Display_Device *Fl_Display_Device::_display = fl_xlib_display;// the 
platform display
@@ -307,6 +313,9 @@ static Atom WM_PROTOCOLS;
 static Atom fl_MOTIF_WM_HINTS;
 static Atom TARGETS;
 static Atom CLIPBOARD;
+static Atom TIMESTAMP;
+static Atom PRIMARY_TIMESTAMP;
+static Atom CLIPBOARD_TIMESTAMP;
 Atom fl_XdndAware;
 Atom fl_XdndSelection;
 Atom fl_XdndEnter;
@@ -667,6 +676,9 @@ void fl_open_display(Display* d) {
   fl_MOTIF_WM_HINTS = XInternAtom(d, _MOTIF_WM_HINTS, 0);
   TARGETS   = XInternAtom(d, TARGETS, 0);
   CLIPBOARD = XInternAtom(d, CLIPBOARD,   0);
+  TIMESTAMP = XInternAtom(d, TIMESTAMP,   0);
+  PRIMARY_TIMESTAMP = XInternAtom(d, PRIMARY_TIMESTAMP,   0);
+  CLIPBOARD_TIMESTAMP   = XInternAtom(d, CLIPBOARD_TIMESTAMP, 0);
   fl_XdndAware  = XInternAtom(d, XdndAware,   0);
   fl_XdndSelection  = 

Re: [fltk.development] [RFE] STR #2636: notification of clipboard changes

2013-01-31 Thread Pierre Ossman

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


The CMake portions were a bit off. Updated patch attached.


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 #2660: support for custom (image) cursors

2013-01-31 Thread Pierre Ossman

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2660
Version: 1.4-feature


The previous patch had an ABI breakage. It also had incorrect CMake
changes. Updated patch should be better.


Link: http://www.fltk.org/str.php?L2660
Version: 1.4-feature

___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev


Re: [fltk.general] Changing an Fl_Menu_Bar item colors

2013-01-31 Thread MacArthur, Ian (Selex ES, UK)

 Thanks for the reply. This code works well for changing the text
 foreground color.
 
 However I also need to change the background color (the gray box behind
 the text).
 
 Any ideas how to change the background color in an Fl_Menu_Bar item?

I don't think there is an easy fix for this (though hopefully others will know 
better!) but you might be able to make it so...

The method that actually draws the menu items, Fl_Menu_Item::draw(...), is 
defined in Fl_Menu.cxx, so I guess it might be possible to derive your own 
Fl_Menu class (and maybe also Fl_Menu_Bar class and Fl_Menu_Item struct...) and 
then add in the ability to set the menu item background...

Note that Fl_Menu_Item::draw(...) actually can cope with drawing different 
boxtypes and colours and so forth, but there's no way to ask for those 
features for regular menu items, it is meant for menu buttons and so forth... 
Though maybe you can do something with selection_color(); I wonder if that 
would work...? Um, probably not...


Anyway; best bet is probably to hope that Sanel or someone knows a workaround 
for this!

Cheers,
-- 
Ian






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] Changing an Fl_Menu_Bar item colors

2013-01-31 Thread David Allen
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.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk


Re: [fltk.general] Changing an Fl_Menu_Bar item colors

2013-01-31 Thread Ian MacArthur

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

2013-01-31 Thread Ian MacArthur

 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.general] Changing an Fl_Menu_Bar item colors

2013-01-31 Thread mickey

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.

In the days of 7 bit ASCII base64 was a necessity today it is rank
stupidity.

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!

from http://support.microsoft.com/kb/323489

Base64 encoding in Exchange Server
Base64 encoding is used in the following situations:

If you send a message that contains characters that are outside
the 7bit US-ASCII range. Exchange Server is a 7-bit Simple Mail
Transfer Protocol (SMTP) transport. To send an 8-bit message, the
message must be encoded in Base64, and then sent by using SMTP.

[snip]


May be your outlook (M$ outhouse) is sending in one of these char
sets.

If you send a message that uses characters from certain character sets
in the message body. Messages that use character sets from the
following code pages are encoded as Base64 messages when they are sent
from an Exchange 2000 computer:

Shift-JIS
EUC-KR
ISO-2202-JP
BIG5
ISO-2202-KR
GB18030
GB2312
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk