Re: [fltk.development] fltk and high res retina display?

2013-04-05 Thread Christophe Geuzaine 

On 05 Apr 2013, at 10:53, Manolo Gouy manolo.g...@univ-lyon1.fr wrote:

 I just upgraded to a newer mac laptop, and discovered that fltk apps
 don't render in the new highres mode.  It seems like it shouldn't be
 too hard for text at least, but I wasn't able to find an enable high
 res flag after a bit of looking at
 
 https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html#//apple_ref/doc/uid/TP40012302-CH1-SW1
 
 There is kWindowHighResolutionCapableAttribute  but it's for Carbon.
 The implication seems to be that for Cocoa apps it should just work.
 Any of the more mac knowledgeable sorts know what's going on here, or
 should I keep poking through the apple docs?
 
 
 I have activated QuartzDebug, as suggested in the above-mentionned
 web-page, to test high resolution without a retina display,
 and discover that fltk graphics have jagged look everywhere.
 What a delusion!
 A very strange thing is that system-created windows (the About
 my prog, open/save and print dialogs) also have jagged graphics.
 This suggests we miss some application-wide property.

Adding 

keyNSHighResolutionCapable/keytrue/

in the app's Info.plist makes standard FLTK widgets/fonts draw fairly well 
(there are some small artifacts and off-by-one line drawings here and there, 
but nothing major). OpenGL windows are still drawn at half-resolution, though...

Christophe

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

-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine



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

Re: [fltk.general] X11 coordinate clipping [was: Re: Fl_Tree - performance and scrollbehaviorissue]

2011-12-26 Thread Christophe Geuzaine 

On 25 Dec 2011, at 02:24, Greg Ercolano wrote:

 On 12/23/11 11:06, Greg Ercolano wrote:
 On 12/22/11 12:27, David FLEURY wrote:
 You are right, I will see for a Tree Item solution, to avoid regression 
 somewhere else.
 I do not know well enough fltk to have any opinion on this subject.
 Just try to make my tests work for my own configuration.
 
  I was noodling with creating an Fl_Tree of 65536 in size,
  and I can definitely see some room for optimization;
  adding elements is slow, and scrolling elements is slow.
 
  I'll see if I can take a stab at optimizing that so that
  adding elements is quicker, and also changing the draw()
  routine so that it only draws items that are within the window.
 
OK, just checked in r9216 which should optimize Fl_Tree
quite a bit. David, please give it a try:
 
   Adding items in a large linear list should be quite a bit
faster now; the slowness was due to repeat calls to find_child()
unnecessarily to figure out the insert point, which was causing
the exponential slowness.
 
   Drawing items should be much faster and should not suffer
   the wraparound issues described, because now draw() only draws
   items whose y() positions are within the Fl_Tree xywh area.
 
   I tested with the following code that creates 100k items
   which is entirely unusable in r9215 and lower, but should be
   quite normal in r9216 and up.
 
   There is still a practical limit on the number of items that
   can be in the tree; draw() will still /consider/ (ie. do calculations
   on) items that are not hidden (ie. open() and visible()), but at least
   it won't try to /draw/ items unless they're inside the window.
 


Hi Greg - Just tested the new version, it works great! There's one little bug 
though: the connections between the items are sometimes missing. To reproduce:

launch test/tree
set Line style to Dotted or Solid
open the Ascending and Descending items
scroll down

Look how the lines connecting ROOT, Bbb, etc. disappear/reappear when you 
scroll up and down.

Christophe


 
   
 #include FL/Fl.H
 #include FL/Fl_Double_Window.H
 #include FL/Fl_Tree.H
 int main( int argc, char **argv) {
   Fl_Double_Window *w = new Fl_Double_Window(900,300);
   Fl_Tree  *b = new Fl_Tree(10,10,w-w()-20,w-h()-20);
   char s[80];
   for ( int t=0; t6; t++ )
   {
   sprintf(s, Entry #%06d, t);
   b-add(s);
   if ( t % 50 == 0 ) printf(Working on %d\n, t);
   }
   w-resizable(b);
   w-end();
   w-show();
   return(Fl::run());
 }
 
 ___
 fltk mailing list
 fltk@easysw.com
 http://lists.easysw.com/mailman/listinfo/fltk

-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine



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

Re: [fltk.development] Fl_Native_File_Chooser on OSX

2011-09-04 Thread Christophe Geuzaine 

On 03 Sep 2011, at 22:32, Ian MacArthur wrote:

 All (but especially Greg I guess...)
 
 I have an app that uses the FNFC, and the OSX version crashes quite often 
 when I use the BROWSE_SAVE_AS mode - but the regular open file case seems 
 to be fine...
 
 Now, the app has been kicking about for a while, but it's fairly specialist 
 and there are a grand total of 3 users worldwide (myself and two others) and 
 it was not until recently we noticed there's an issue. The regular workflow 
 is such that the save-as case is seldom used, and even now there's only one 
 of us who does use it much if at all... But we are about to deploy more 
 widely, so we need to get it fixed...
 
 So, is anyone else seeing issues with the FNFC save-as option on OSX, or os 
 it peculiar to my code (quite possible...) I need to do a full-debug build 
 and see what gdb says, but I've been putting that off, the prospect is not 
 attractive!
 
 I wonder if there is something duff about the way in which I am calling it 
 that triggers some underlying issue - the the file-open option *appears* to 
 be stable, so...
 

Hi Ian,

I can confirm the random crashes with our app (Gmsh)... I tried to debug it but 
when I run the code in gdb I cannot reproduce it :-(

Christophe



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

-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine



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

Re: [fltk.development] [RFE] STR #2653: Display of formats inFl_Native_File_Chooser (BROWSE_SAVE_FILE) on MacOS X

2011-06-05 Thread Christophe Geuzaine 
On 03/06/11 12:13, Manolo Gouy wrote:

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

 [STR Pending]

 Link: http://www.fltk.org/str.php?L2653
 Version: 1.3-feature
 Fix Version: 1.3.0 (r8774)


 I believe r.8774 fixes this issue.
 Christophe: is that OK ?
 Filters (for both open and save) are now of the form
 filter_name (pattern)
 because this is the form they have in the X11 chooser.
 I believe this solution is better for platform-independant
 source programs, even if many Mac OS programs don't display
 the pattern (but MS-Word does display it).


Manolo - Works great!

(I guess personnally I would prefer not seeing the extensions at all on 
MacOS because it does not feel very mac-like... but it's not a big deal)


 Link: http://www.fltk.org/str.php?L2653
 Version: 1.3-feature
 Fix Version: 1.3.0 (r8774)


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

Re: [fltk.bugs] [MOD] STR #2595: Deleting OpenGL windows crasheswith new Cocoa Mac version

2011-03-26 Thread Christophe Geuzaine 

On 26/03/11 00:32, Manolo Gouy wrote:


[STR Closed w/Resolution]

Link: http://www.fltk.org/str.php?L2595
Version: 1.3.0
Fix Version: 1.3.0 (r8534)


Fixed in Subversion repository.

This bug was not OpenGL-related, nor Cocoa-related. It occurs
replacing GL subwindows by Fl_Window in your test program, and with
last year's Carbon FLTK 1.3 version.



Ok! Many thanks for your patch: it fixes the crash.

There's one weird side effect when using GL subwindows, though: if you 
draw a string in the GL window before deleting it, and you draw the same 
string in the new GL window that replaces it, the string is drawn as a 
solid color rectangle.


I guess there's a caching issue (are the textures e.g. linked to a given 
GL context via a display list)?


Attached is a small example that shows the problem.




The bug was: when attempting to delete a subwindow, the code
did not detect it's a subwindow, so deletes the window OS structure
that is in fact its parent's. Later, the OS accesses the parent
window structure, that has just been deleted.

Thus, the issue is How to detect that I'm dealing with a subwindow
when I want to delete it and when the link to its parent has been
already removed ?

I have implemented this: make sure that none of the windows
of the window list shares the same OS window (xid) as ours.

Is there a more direct way to do it ?


Link: http://www.fltk.org/str.php?L2595
Version: 1.3.0
Fix Version: 1.3.0 (r8534)



// compile with fltk-config --use-gl --compile gldelete.cpp
//
// run code, then press 'd'
// - expected behaviour: the opengl window is deleted and replaced 
//   with a new one
// - observed behaviour: code crashes

#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Tile.H
#include FL/Fl_Gl_Window.H
#include FL/gl.h
#if defined(__APPLE__)
#include OpenGL/gl.h
#include OpenGL/glu.h
#else
#include GL/gl.h
#include GL/glu.h
#endif

class openglWindow : public Fl_Gl_Window{
public:
  openglWindow(int x, int y, int w, int h) : Fl_Gl_Window(x, y, w, h){}
  void draw()
  {
glClearColor(0.5, 0.3, 0.8, 0.);
glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);
glRasterPos2d(0, 0);
gl_draw(A string);
  }
};

Fl_Tile *tile;

int shortcuts(int event)
{
  if(Fl::test_shortcut('d')){
tile-clear();

openglWindow *gl = new openglWindow(0, 0, 400, 400);
gl-end();
gl-mode(FL_RGB | FL_DEPTH | FL_DOUBLE);
tile-add(gl);
gl-show();
  }
  return 1;
}

int main(int argc, char **argv)
{
  Fl_Window *win = new Fl_Window(0, 0, 400, 400);
  tile = new Fl_Tile(0, 0, 400, 400);
  openglWindow *gl = new openglWindow(0, 0, 400, 400);
  gl-end();
  gl-mode(FL_RGB | FL_DEPTH | FL_DOUBLE);
  tile-end();
  win-end();
  win-show(argc, argv);
  Fl::add_handler(shortcuts);
  Fl::run();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.bugs] [MOD] STR #2595: Deleting OpenGL windows crasheswithnew CocoaMac version

2011-03-26 Thread Christophe Geuzaine 
On 26/03/11 15:42, Manolo Gouy wrote:
 On 26/03/11 09:53, Manolo Gouy wrote:
 There's one weird side effect when using GL subwindows, though: if you
 draw a string in the GL window before deleting it, and you draw the same
 string in the new GL window that replaces it, the string is drawn as a
 solid color rectangle.

 I guess there's a caching issue (are the textures e.g. linked to a
 given GL context via a display list)?

 Yes, the code attempts to re-use the pre-computed texture on the
 new window, and it fails.
 Because I know nothing of OpenGL, it's very difficult for me
 to debug that. Could you help ?

 I've had a look at the fltk code, and I think that the easiest fix is to
 force the recomputation of the texture pile.

 In my own code I just tested the following, which works: after deleting
 the original GL subwindow just call

 gl_texture_pile_height(gl_texture_pile_height());

 Maybe we could force a reset of the texture pile in the destructor of a
 GL window?

 Christophe

 Thanks. This solution is now included in r. 8536.
 Let me know if all is OK.


Yes, works perfectly.

Thanks again!
Christophe
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.development] spurious FL_FOCUS

2011-03-23 Thread Christophe Geuzaine 
On 23/03/11 11:33, Manolo Gouy wrote:
 When I create a new window, it gets an FL_SHOW, as expected.  When I
 click in the new window, a mouse down and mouse up are sent to the new
 window, and then after the mouse up, FL_FOCUS is sent to the *old*
 window.  Every click on the new window yields a focus on the old
 window (which according to the OS, doesn't have focus at all).  If I
 type a key, the event goes to the new window as expected, and the
 spurious FL_FOCUS stops happening and clicks are normal.

 I can reproduce this easily.  It might be specific to my app, but at
 the moment I'm thinking it's not.  I'm investigating further, but does
 this sound familiar to anyone else?

 OS X 10.6.6, current svn version of fltk.

 I'm trying to reproduce that with the editor demo and its
 File/New View menu item and OS X 10.6.

 I see that just after the new window is created, the old one has
 kept focus, but a click on any part of the new window, or even going
 to another application and then back to editor, is enough to bring
 focus to the new window. So, I'm not able to reproduce what you see
 where a click on one window sends FL_FOCUS to another one.
 This focus-gaining results from windowDidBecomeKey being notified
 by the system to the program which reacts by calling
Fl::handle( FL_FOCUS, w);
 So I don't understand why your program doesn't behave the same
 as the editor demo.

 I also see that adding
Fl::handle( FL_FOCUS, w);
 at the end of Fl_X::make() makes that the new window gets focus
 immediately after it appears on screen.

 P.S. the New View menu shortcut does not work, but that's another
 story. The option modifier can't be used for menu shortcuts
 on Mac OS because the option modifier changes the received character
 in a locale-dependent way.


Manolo - I've posted a new STR with two very small examples showing the 
focus issues I have in my own code (gmsh).

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

Re: [fltk.development] spurious FL_FOCUS

2011-03-23 Thread Christophe Geuzaine 
On 23/03/11 13:00, MacArthur, Ian (SELEX GALILEO, UK) wrote:

 Manolo - I've posted a new STR with two very small examples
 showing the
 focus issues I have in my own code (gmsh).

 Christophe,

 From your tests, do you know if this effect is OSX only or does it
 occur on other platforms?


 From my tests, it's only with the new Cocoa version. On Mac/Carbon, 
Windows and Linux everything works as expected.






 SELEX Galileo Ltd
 Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 
 3EL
 A company registered in England  Wales.  Company no. 02426132
 
 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-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Re: [fltk.bugs] [MOD] STR #2274: snow Leopard 64bit in 1.1.10

2009-10-20 Thread Christophe Geuzaine 
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?L2274
 Version: 1.1.10
 
 
 Ah, missed that 64bit detail in the subject.
 
 This sounds like STR #2221:
 http://www.fltk.org/str.php?L2221
 
 I don't remember where we're at with that. The above would appear to
 provide a patch.
 
 In short, I believe the issue was there's still some stray Carbon library
 calls FLTK is still using which lock us to 32bit.. completing the switch
 from carbon to either quartz or cocoa (can't remember which) would get us
 full 64bit apps on OSX.
 
 I think some details on this are in the cited thread.
 See also thread entitled fltk-1.1 OSX Quartz question
 
 

PS: have you seen Manolo's awesome work on this issue?

http://www.fltk.org/str.php?L2221

I have tested it here and it works great. The only missing piece really 
is OpenGL support.

Ch.


 Link: http://www.fltk.org/str.php?L2274
 Version: 1.1.10
 
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.development] CMake and IDE support

2009-09-08 Thread Christophe Geuzaine 
Albrecht Schlosser wrote:
 Christophe Geuzaine wrote:
 
 Just to provide one data point: we recently switched our fltk-based 
 project (Gmsh) from autoconf to CMake and it has been a great experience.

 Our configure.in script was about the size/complexity of fltk's (1000 
 lines, with a couple dozen configuration variants), and we completed 
 the transition by hand in a couple of days.

 The result is outstanding: XCode and Visual C++ support without 
 duplicated efforts, out-of-source builds with several variants at 
 once, automatic exe/lib/source dependencies, automatic packaging (disk 
 images of app bundles on MacOS, etc.)
 
 You wrote ... Visual C++ support. Does this mean that you can create 
 IDE project files that can be created by developers and packaged with 
 the distro, or do users need CMake and run nmake, as Greg wrote in 
 another post?
 

Users need to install cmake and generate the projects themselves: the 
projects (or the makefiles) created by CMake use absolute paths, which 
makes them non-distributable.

We perceived this as a potential problem in the beginning too, but after 
using the system I think it's actually a non-issue: cmake comes 
preinstalled on most linux distros, and installing it on Windows or Mac 
is trivial (there's a graphical installer). Users also have the full 
range of configuration options available once they have cmake... which 
is usually what they need to compile a complex piece of software with 
multiple dependencies.

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

Re: [fltk.development] CMake and IDE support

2009-09-08 Thread Christophe Geuzaine 
Roman Kantor wrote:
 There is a cmake switch CMAKE_USE_RELATIVE_PATHS (or something like
 that, do not remember exactly) which causes to generate relative paths.

Indeed, but I would not advise you to use it. For even relatively simple 
projects this will fail. (I think the CMake folks even acknowledge this 
in the official docs.)


 This should allow to tweak the cmake files to build portable project
 files without the need of having cmake on the target machine - as long
 as your cmake generates all configuration oprions (that is
 debug/release/dll versions of fltk and all associated libraries)
 
 R.
 
 Christophe Geuzaine wrote:
 
 Users need to install cmake and generate the projects themselves: the
 projects (or the makefiles) created by CMake use absolute paths, which
 makes them non-distributable.
 
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Re: [fltk.development] Fl_Native_File_Chooser on Snow Leopard

2009-09-07 Thread Christophe Geuzaine 
Matthias Melcher wrote:
 
 On 07.09.2009, at 22:37, Greg Ercolano wrote:
 
 MacArthur, Ian (SELEX GALILEO, UK) wrote:
 in a future FLTK release; I leave it to the fltk devs to
 decide when that's appropriate.

 Technically, I think the group fltk devs includes you these days!

 No, no.. ahhh! ;)

 For sure I don't know how to add it, as it would involve
 things I don't know how to do really:

 o Mods to configure
 o Mods to the VS build files
 o Mods to the makefiles
 o Mods to the docs (index, etc)
 
 Um, yeah, that is one of the biggest problems for pretty much all of us: 
 adding a new source file requires maintenance in all build files. I was 
 hoping that cmake changes that, but I don't see it happening (yet). In a 
 flash of insanity I started an automated IDE update utility, but gave 
 up: none of the IDE formats are documented (or make much sense without 
 knowing every niche of the IDE). The only (and not satisfying at all) 
 solution is to have all IDEs present, understand them all, and adapt the 
 setups - or ask the appropriate people on the list.
 
 Any better ideas?

Just to provide one data point: we recently switched our fltk-based 
project (Gmsh) from autoconf to CMake and it has been a great experience.

Our configure.in script was about the size/complexity of fltk's (1000 
lines, with a couple dozen configuration variants), and we completed the 
transition by hand in a couple of days.

The result is outstanding: XCode and Visual C++ support without 
duplicated efforts, out-of-source builds with several variants at once, 
automatic exe/lib/source dependencies, automatic packaging (disk images 
of app bundles on MacOS, etc.)

Just my 2 cents ;-)

Christophe


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

Re: [fltk.general] FLTK versions and namespaces

2009-09-04 Thread Christophe Geuzaine 

Greg Ercolano wrote:

imm wrote:

Eric Sokolowsky wrote:


1. A built-in hierarchical tree browser widget
Just for the record, Greg has a tree widget too - I mention this only 
because the FLU stuff (of which I am generally a fan) seem to be 
unmaintained now...


http://seriss.com/people/erco/fltk/Fl_Tree/


Right -- it's a rewrite, though I did refer to FLU's feature set
to make sure I wasn't missing anything obvious.

Fl_Tree is still a pre-1.0 state, but it's main functions seem
to work well.

The vertical scrollbar works normally, but currently there's no
horizontal scrollbar yet.

You can also put widgets inside the tree. This hasn't been
well tested, but the demo works.

If you try it, let me know if you have any trouble or questions.


Greg - We switched from the FLU tree widget to Fl_Tree in Gmsh. Fl_Tree 
is definitely more stable.


The only feature we were missing was the ability to store user data in 
the nodes. Attached is a small patch that adds that capability + makes 
Fl_Tree compile with FLTK versions older than 1.1.9.


Thanks again for this widget: it was really the biggest missing widget 
in FLTK.


Christophe

PS - On the wishlist for a future version: make it more efficient for 
very large trees ;-)
diff -u -r /Users/geuzaine/src/Fl_Tree-0.71/FL/Fl_Tree_Item.H 
./FL/Fl_Tree_Item.H
--- /Users/geuzaine/src/Fl_Tree-0.71/FL/Fl_Tree_Item.H  2009-06-04 
14:05:43.0 +0200
+++ ./FL/Fl_Tree_Item.H 2009-08-16 02:28:16.0 +0200
@@ -68,6 +68,7 @@
 int_label_xywh[4]; // xywh of label
 Fl_Widget *_widget;// item's label widget 
(optional)
 Fl_Pixmap *_usericon;  // item's user-specific icon 
(optional)
+void  *_userdata;  // item's user-specific data 
(optional) GMSH
 Fl_Tree_Item_Array _children;  // array of child items
 Fl_Tree_Item  *_parent;// parent item (=0 if root)
 protected:
@@ -276,6 +277,14 @@
 Fl_Pixmap *usericon() const {
 return(_usericon);
 }
+/// Set the user data.
+void userdata(void *val) {
+_userdata = val;
+}
+/// Get the user data.
+void *userdata() const {
+return(_userdata);
+}
 //
 // Events
 //
diff -u -r /Users/geuzaine/src/Fl_Tree-0.71/Fl_Tree_Item.cxx ./Fl_Tree_Item.cxx
--- /Users/geuzaine/src/Fl_Tree-0.71/Fl_Tree_Item.cxx   2009-06-04 
14:05:43.0 +0200
+++ ./Fl_Tree_Item.cxx  2009-08-16 12:17:18.0 +0200
@@ -60,6 +60,7 @@
 _label_xywh[2]= 0;
 _label_xywh[3]= 0;
 _usericon = 0;
+_userdata = 0; // GMSH
 _parent   = 0;
 }
 
diff -u -r /Users/geuzaine/src/Fl_Tree-0.71/Fl_Tree_Prefs.cxx 
./Fl_Tree_Prefs.cxx
--- /Users/geuzaine/src/Fl_Tree-0.71/Fl_Tree_Prefs.cxx  2009-06-04 
14:05:43.0 +0200
+++ ./Fl_Tree_Prefs.cxx 2009-09-01 16:51:11.0 +0200
@@ -1,3 +1,4 @@
+#include string.h
 #include FL/Fl.H
 #include FL/Fl_Pixmap.H
 #include FL/Fl_Tree_Prefs.H
@@ -112,7 +113,12 @@
 // Let fltk's current 'scheme' affect defaults
 if ( Fl::scheme() ) {
if ( strcmp(Fl::scheme(), gtk+) == 0 ) {
-   _selectbox = _FL_GTK_THIN_UP_BOX;
+#if (FL_MAJOR_VERSION == 1)  (FL_MINOR_VERSION == 1)  (FL_PATCH_VERSION  
9)
+  // GMSH PATCH for fltk  1.1.9 compat
+  _selectbox = FL_FLAT_BOX;
+#else
+  _selectbox = _FL_GTK_THIN_UP_BOX;
+#endif
} else if ( strcmp(Fl::scheme(), plastic) == 0 ) {
_selectbox = _FL_PLASTIC_THIN_UP_BOX;
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.development] Support for 64-bit OS X

2009-07-11 Thread Christophe Geuzaine 
imacarthur wrote:
 
 On 11 Jul 2009, at 6:08, Christophe Geuzaine wrote:
 darby johnston wrote:
 Is it possible\ to compile FLTK for 64-bit OS X applications? I tried 
 setting CPPFLAGS and LDFLAGS to '-arch x86_64' but got a lot of 
 errors like:

 Unfortunatey I don't think so, as FLTK relies on Carbon (which is 32
 bits only). Matthias and Greg: can you confirm this?
 
 Which version of fltk? Fltk-1.1 (and maybe fltk-2? I don't know) are 
 Carbon based. Fltk-1.3 is Quartz based, and fltk-1.1 *can* be built 
 targeting Quartz, although I don't know if it got all the tweaks that 
 went into fltk-1.3's Quartz support.

We are using 1.1 for the production versions, but I recently tested 1.3 
and got the same behavior. It would indeed be awesome if 1.3 could 
eventually be 64 bits by removing all the remaining Carbon stuff!

 
 However... I have a vague idea (Matthias would know more) that there may 
 be some loose ends in the fltk-1.3 build even now that are not fully 
 Quartz clean, as it were. That said, I think it has to be worth a shot.
 
 As a side note, this is actually quite a big problem for our fltk-based
 project (gmsh), as we cannot use the fltk version to handle very large
 datasets on Mac.
 
 I'm not quite sure what you are saying here - we have some code that is 
 fltk-1.1 in the GUI, and yes, it is only 32-bit, but the back-end number 
 crunching is 64-bit and that seems to be working OK.
 We did it that way because that appeared to be what Apple did with their 
 stuff during the transition (32-bit GUI code wrapping a 64-bit 
 application) so I guess that might be possible to do something similar 
 for gmsh in some way?
 

We used to do this, but nowadays even the graphical data can easily 
reach several gigabytes---so we basically need all the OpenGL stuff (and 
thus also the fltk bits if we want to keep the code simple) to be 64 bits.

(Right now when we need to deal with large datasets graphically on Mac 
OS X we build a lighter version of gmsh with a very basic GUI based on 
AntTweakBar.)

Christophe

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

Re: [fltk.development] Support for 64-bit OS X

2009-07-11 Thread Christophe Geuzaine 
imacarthur wrote:
 
 On 11 Jul 2009, at 6:08, Christophe Geuzaine wrote:
 darby johnston wrote:
 Is it possible\ to compile FLTK for 64-bit OS X applications? I tried 
 setting CPPFLAGS and LDFLAGS to '-arch x86_64' but got a lot of 
 errors like:

 Unfortunatey I don't think so, as FLTK relies on Carbon (which is 32
 bits only). Matthias and Greg: can you confirm this?
 
 Which version of fltk? Fltk-1.1 (and maybe fltk-2? I don't know) are 
 Carbon based. Fltk-1.3 is Quartz based, and fltk-1.1 *can* be built 
 targeting Quartz, although I don't know if it got all the tweaks that 
 went into fltk-1.3's Quartz support.

We are using 1.1 for the production versions, but I recently tested 1.3 
and got the same behavior. It would indeed be awesome if 1.3 could 
eventually be 64 bits by removing all the remaining Carbon stuff!

 
 However... I have a vague idea (Matthias would know more) that there may 
 be some loose ends in the fltk-1.3 build even now that are not fully 
 Quartz clean, as it were. That said, I think it has to be worth a shot.
 
 As a side note, this is actually quite a big problem for our fltk-based
 project (gmsh), as we cannot use the fltk version to handle very large
 datasets on Mac.
 
 I'm not quite sure what you are saying here - we have some code that is 
 fltk-1.1 in the GUI, and yes, it is only 32-bit, but the back-end number 
 crunching is 64-bit and that seems to be working OK.
 We did it that way because that appeared to be what Apple did with their 
 stuff during the transition (32-bit GUI code wrapping a 64-bit 
 application) so I guess that might be possible to do something similar 
 for gmsh in some way?
 

We used to do this, but nowadays even the graphical data can easily 
reach several gigabytes---so we basically need all the OpenGL stuff (and 
thus also the fltk bits if we want to keep the code simple) to be 64 bits.

(Right now when we need to deal with large datasets graphically on Mac 
OS X we build a lighter version of gmsh with a very basic GUI based on 
AntTweakBar.)

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

Re: [fltk.general] Fl_Tree 0.70 -- First public release

2009-06-07 Thread Christophe Geuzaine 
Greg Ercolano wrote:
 Robert Arkiletian wrote:
 On Wed, Jun 3, 2009 at 10:15 PM, Greg Ercolanoe...@seriss.com wrote:
 http://www.seriss.com/people/erco/fltk/Fl_Tree/
 This is great Greg. Very nice. I look forward to using it in the
 future. Thanks for contributing such useful widgets to FLTK.
 
   Thanks! Yeah, I know there's other FLTK tree widgets out there,
   but my goal was to ensure it was a standalone tool, and was
   written in the spirit of the core; tight code as possible,
   no stl, regular char*'s, etc.
 
   With doxygen'ed docs, it makes the code bigger than it needs
   to be, but the code is still pretty tiny.
 
   I think it'd be a good contender as a core widget once it
   stabilizes. It's API could use a good vetting to ensure it's
   forward thinking, and a peer review of the code wouldn't
   hurt it either.
 

Hi Greg - definitely +1 on the proposal to add this to the core lib.

PS: I've had to add

   #include string.h

in Fl_Tree_Prefs.cxx

and

   #include stdio.h

in test-Fl_Tree.cxx and test-simple.cxx to compile on OSX.

I will run some tests with our app and try to optimize insertion time: 
we would like to use trees with  10,000 entries.

Thanks for your excellent work!

Christophe



   I'm using it in production code, so it'll get a workout.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] mac OSX drag and drop open file with finder

2008-08-28 Thread Christophe Geuzaine 
Louis wrote:
 Yes, it is possible. Make sure that your app is in a bundle. If you
 have a correct bundle, you call fl_open_callback() with a function
 that will handle all drop operations onto the application icon.

 Uhm in a bundle? Do you mean in a app bundle directory?
 The application is in a .app directory, i can open the programm with double 
 click.
 The info.plist content is:
 ?xml version=1.0 encoding=UTF-8?
 plist version=0.9
 dict
   keyCFBundleInfoDictionaryVersion/key
   string6.0/string
   keyCFBundleExecutable/key
   stringfedit/string
   keyCFBundleIdentifier/key
   stringorg.fltk.fedit/string
   keyCFBundleName/key
   stringfedit/string
   keyCFBundlePackageType/key
   stringAPPL/string
 /dict
 /plist
 
 If I drag a file onto the application and release the mouse button the file 
 moves back to its original location.
 The application name also does not get bold like the textedit name if a file 
 is dragged onto it.

You need to declare the file types your app can handle. For example, if 
your app can display .txt and .dat files and edit .dat files, you could add

keyCFBundleDocumentTypes/key
   array
 dict
   keyCFBundleTypeExtensions/key
 array
   stringtxt/string
   stringdat/string
 /array
   keyCFBundleTypeName/keystringMyApp Data File/string
   keyCFBundleTypeRole/keystringViewer/string
 /dict
 dict
   keyCFBundleTypeExtensions/key
 array
   stringdat/string
 /array
   keyCFBundleTypeName/keystringMyApp Data File/string 

   keyCFBundleTypeRole/keystringEditor/string
 /dict
   /array

in your plist. You could also provide additional info like specific 
icons for each file type, use a CFBundleOSType instead of a file 
extension, etc.

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

Re: [fltk.general] 1.1.x-UTF8 hack brought up to r6041

2008-02-25 Thread Christophe Geuzaine 
Yuri D'Elia wrote:
 In article [EMAIL PROTECTED],
  Greg Ercolano [EMAIL PROTECTED] wrote:
 
 MacArthur, Ian (SELEX GALILEO, UK) wrote:
 Great job, can this merge into the official 1.1.8?
 No - it breaks the ABI, so it isn't compatible with the stock 1.1.x
 series.
  Right, though it could become 1.3.x
 
 Now that the roadmap shows 0 bugs and RC1 is almost out the door, I 
 would really love to see 1.1.x become 1.3 with all the breaks the ABI 
 patches integrated, with UTF8 being the first of the stack.
 

If I could cast a vote, my top five candidates for inclusion in 1.3 
would be, by order of importance:

1) utf8 support
2) robust tree browser
3) change short to int for widget sizes
4) native file chooser
5) ...native file chooser with the same API as the default one :-)

Christophe


 I wonder if there's anything really worth backporting from 1.2?
 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.bugs] [MOD] STR #1865: segfault at Fl_Widget::type at../FL/Fl_Widget.H:110

2008-02-05 Thread Christophe Geuzaine 
Michael Sweet wrote:
 [STR Closed w/o Resolution]
 
 Link: http://www.fltk.org/str.php?L1865
 Version: 1.1.7
 Fix Version: None
 
 
 General support is not available via the STR form. Please post to the FLTK
 forums and/or mailing lists for general support.
 
 Note that the this pointer is bad in your backtrace - more than likely
 the application is corrupting the heap.
 

I think Martin might be experiencing this bug 
http://www.fltk.org/str.php?L1162

It's fixed in the svn tree.

Christophe


 
 Link: http://www.fltk.org/str.php?L1865
 Version: 1.1.7
 Fix Version: None
 
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Re: [fltk.general] [Fwd: Re: Fl_Native_File_Chooser]

2008-01-07 Thread Christophe Geuzaine 
Christophe Geuzaine wrote:
 
 Hello all - Here's an email exchange I juste had with Greg about his 
 Fl_Native_File_Chooser class.
 
 Any ideas?
 


PS: clearing up the event state with

Fl::e_state = 0;

at the end of the callback fixes the problem. But this is a pretty ugly 
hack...

Ch.






 Christophe
 
  Original Message 
 Subject: Re: Fl_Native_File_Chooser
 Date: Mon, 07 Jan 2008 13:59:21 -0800
 From: Greg Ercolano [EMAIL PROTECTED]
 To: Christophe Geuzaine [EMAIL PROTECTED]
 References: [EMAIL PROTECTED]
 
 Christophe Geuzaine wrote:
 Hello Greg - A little question about your native file chooser (version 
 0.84) on Mac OS X 10.5 (Leopard), with the latest FLTK 1.1 snapshot.

 If I add a shortcut in your simple-app.cxx example on line 68, i.e.,

  but-shortcut(FL_META+'o');

 then, after pressing Command+o and selecting Cancel in the file 
 chooser, somehow FLTK still seems to think that FL_META is pressed (so 
 just pressing 'o' will reopen the file chooser).

 I discovered this while evaluating your native file chooser for 
 inclusion in my code ('Command+o' opened the file browser; after 
 closing it, hitting 'q' activated the 'Command+q' shortcut for 
 quitting the app!).

 Could you give this a try on your machine and check if it's an issue 
 with Leopard (unfortunately I don't have Tiger around anymore...), or 
 with Fl_Native_File_Chooser per se?
 
 Hi Christophe,
 
 Hmm, it sounds like the keyup event is being eaten by the
 native operating system's file chooser, and thus the up event
 never makes it to FLTK, which will continue to think the
 button is down.
 
 Not sure what to do about this offhand, since the OS's file chooser
 has its own event loop that is sure to usurp FLTK's event loop.
 
 Can you forward this to fltk.general group along with my above 
 comments?
 
 It's possible there's a way to tell FLTK to release the key by
 forcing a key release event, to prevent the problem you're describing,
 but I don't know what the correct way would be offhand.
 
 
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Leopard + mac.r + FLTK 1.1.7 = useless app??

2008-01-04 Thread Christophe Geuzaine 
imm wrote:
 On 2 Jan 2008, at 9:40, Christophe Geuzaine wrote:

 I confirm that this is a Leopard issue (tested with both 1.1.7 and the
 latest svn snapshot).
 
 
 Christophe, can you file an STR for this please, perhaps (if possible) 
 with a minimal example that shows the errant behaviour. I don't have 
 10.5 here, but I thought others had reported more positive results.
 

- STR #1852


 When the app is not in a bundle, the Mac-specific magic that was added
 post 1.1.7 makes the app usable (you get the focus), but the system menu
 bar is not working. This is not a huge deal, but it would be nice to
 have it work again: it's very handy when developping (it's a pain to
 have to use a bundle every time, especially from the command line).
 
 You only have to create your bundle once, though (and that is easily 
 scriptable, or use my bundle_maker CLI app.)
 

Sure, I create the bundle automatically in my makefile. It's just a
little less convenient, as testing from the command line on Mac becomes
different from testing on other platforms (automated test scripts then 
need to be particularized for the Mac, etc.).



 Thereafter, all you need do is add a cp line to your Makefile to copy 
 your exe into the bundle and you are good to go. Viz:
 
 cp my_exe my_bundle.app/Contents/MacOS/my_exe
 
 Invoking the bundle from the CLI is then as simple as typing:
 
 open my_bundle
 
 And things should Just Work.
 
 


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

Re: [fltk.general] Leopard + mac.r + FLTK 1.1.7 = useless app??

2008-01-02 Thread Christophe Geuzaine 
Dan Lorca wrote:
 Problem is even test/demo isn't getting any focus.  Is this a known
 issue with 1.1.7 in Leopard?  Am I missing something?

 Please help.  Kind of going nuts here.
 I've never had a problem with this, but I always just use fltk-config
 to add the rez fork (if I add a res fork at all...)

 Viz:

  fltk-config --post my_app

 And that Just Works (TM).

 
 {snip the helpful suggestions}
 
 Thanks for the prompt responsethe problem is that --post isn't working 
 either - and like I said test/demo isn't launching with focus.  I was 
 wondering if that's a Leopard issue or something (and if so, whether newer 
 builds would even solve the problem).
 
 When I stopped working on my project I was using 1.1.7 and (my ignorance 
 here) I'm not aware of what fundamental changes might occur between 1.1.8 or 
 even 2.  If the changes aren't going to affect it compiling/working, then no 
 problem.  My general view for things like this is to not upgrade without a 
 good reason :).


I confirm that this is a Leopard issue (tested with both 1.1.7 and the
latest svn snapshot).

When the app is in a .app bundle, everything works fine, both with 
1.1.7 and with the latest svn snapshot.

When the app is not in a bundle, the Mac-specific magic that was added 
post 1.1.7 makes the app usable (you get the focus), but the system menu 
bar is not working. This is not a huge deal, but it would be nice to 
have it work again: it's very handy when developping (it's a pain to 
have to use a bundle every time, especially from the command line).

Any ideas on how to make the system menu bar working again in Leopard 
(without creating a .app bundle)?

Christophe







 
 Anyways, open to further suggestions.  I will look into the bundle solution - 
 its something I was flirting with, but will it solve my problem being that 
 Rez/--post are not working?
 
 
 -dan

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

Re: [fltk.general] fltk-1.1.8-utf

2007-10-09 Thread Christophe Geuzaine 
MacArthur, Ian (SELEX) (UK) wrote:
 The other change is to fix the XFT builds so that gl_font() 
 can select 
 fonts of different sizes - the default fltk-XFT behaviour 
 is to pick a 
 single fixed font for GL use, regardless of what size or 
 face you request.
 With this hack in place, you can now get different sizes - 
 the face is 
 still pretty much ignored, however.
 I might be able to work that, but for now it's just a hackaround...

 Hi Ian - It would be great to merge this fix into the 
 mainline FLTK 1.1 
 tree. Debian (for example) ships FLTK configured with XFT 
 support, which 
 makes OpenGL fonts in all the FLTK apps in Debian look bad.
 
 
 Have you tested this fix and found that it is good? I did some
 testing, but did not have time enough to be as thorough as I'd like.
 Does it work reliably for you with your Debian apps?
 
 If so, we could maybe speak nicely to Matthias about patching it into
 the 1.1.8 mainstream (it is almost, but not quite, a drop-in replacement
 for Fl_fonts_xft.cxx, I think.)


Hi Ian - Yes, I've tested it on Debian and it works well.

What I did is simply replace the function fl_xxfont() in the latest 
official FLTK snapshot with the one from the fltk-1.1.8-utf.

Looking at fl_xxfont() I guess we could quite easily add support for the 
other standard fonts, too.

Christophe



 
 Cheers,
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] fltk-1.1.8-utf

2007-10-09 Thread Christophe Geuzaine 
imm wrote:
 Another minor update:
 
 http://www.imm.uklinux.net/fltk/fltk118-utf8-2007-10-03.tar.bz2
 

...

 
 The other change is to fix the XFT builds so that gl_font() can select 
 fonts of different sizes - the default fltk-XFT behaviour is to pick a 
 single fixed font for GL use, regardless of what size or face you request.
 With this hack in place, you can now get different sizes - the face is 
 still pretty much ignored, however.
 I might be able to work that, but for now it's just a hackaround...
 

Hi Ian - It would be great to merge this fix into the mainline FLTK 1.1 
tree. Debian (for example) ships FLTK configured with XFT support, which 
makes OpenGL fonts in all the FLTK apps in Debian look bad.

Thanks for the fix!

Christophe


 There was a query over on fltk.opengl that I think was related to this 
 issue.
 
 Enjoy,


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

Re: [fltk.general] fltk-1.1.8-utf

2007-10-09 Thread Christophe Geuzaine 
MacArthur, Ian (SELEX) (UK) wrote:
 The other change is to fix the XFT builds so that gl_font() 
 can select 
 fonts of different sizes - the default fltk-XFT behaviour 
 is to pick a 
 single fixed font for GL use, regardless of what size or 
 face you request.
 With this hack in place, you can now get different sizes - 
 the face is 
 still pretty much ignored, however.
 I might be able to work that, but for now it's just a hackaround...

 Hi Ian - It would be great to merge this fix into the 
 mainline FLTK 1.1 
 tree. Debian (for example) ships FLTK configured with XFT 
 support, which 
 makes OpenGL fonts in all the FLTK apps in Debian look bad.
 
 
 Have you tested this fix and found that it is good? I did some
 testing, but did not have time enough to be as thorough as I'd like.
 Does it work reliably for you with your Debian apps?
 
 If so, we could maybe speak nicely to Matthias about patching it into
 the 1.1.8 mainstream (it is almost, but not quite, a drop-in replacement
 for Fl_fonts_xft.cxx, I think.)


Hi Ian - Yes, I've tested it on Debian and it works well.

What I did is simply replace the function fl_xxfont() in the latest 
official FLTK snapshot with the one from the fltk-1.1.8-utf.

Looking at fl_xxfont() I guess we could quite easily add support for the 
other standard fonts, too.

Christophe



 
 Cheers,

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