[fltk.commit] [Library] r9895 - branches/branch-3.0/src/fltk3

2013-04-21 Thread fltk-dev
Author: manolo
Date: 2013-04-21 08:45:37 -0700 (Sun, 21 Apr 2013)
New Revision: 9895
Log:
Some improvement in memory allocation for function create_default_drag_image().

Modified:
   branches/branch-3.0/src/fltk3/cocoa.mm

Modified: branches/branch-3.0/src/fltk3/cocoa.mm
===
--- branches/branch-3.0/src/fltk3/cocoa.mm  2013-04-20 22:16:03 UTC (rev 
9894)
+++ branches/branch-3.0/src/fltk3/cocoa.mm  2013-04-21 15:45:37 UTC (rev 
9895)
@@ -3220,6 +3220,8 @@
 }
 
 static fltk3::Image *create_default_drag_image()
+/* Creates a small image that can be used when dragging from an FLTK widget.
+ */
 {
   const int version_threshold = 100700;
   int width, height;
@@ -3236,21 +3238,22 @@
 char str[4];
 int l = fltk3::utf8encode(0x1F69A, str); // the Delivery truck Unicode 
character from Apple Color Emoji font
 fltk3::draw(str, l, 1, 16);
-fl_end_offscreen();
 }
   else {
-CGContextSetRGBFillColor( (CGContextRef)off, 0,0,0,0);
+CGContextSetRGBFillColor( (CGContextRef)off, 0,0,0,0); // draw two nested 
squares
 fltk3::rectf(0,0,width,height);
 CGContextSetRGBStrokeColor( (CGContextRef)off, 0,0,0,0.6);
 fltk3::rect(0,0,width,height);
 fltk3::rect(2,2,width-4,height-4);
   }
+  fl_end_offscreen();
   CGContextRef c = (CGContextRef)off;
   unsigned char *pdata = (unsigned char *)CGBitmapContextGetData(c);
   fltk3::Image *img = new fltk3::RGBImage(pdata, CGBitmapContextGetWidth(c), 
CGBitmapContextGetHeight(c), 4);
-  img = img-copy();
+  fltk3::Image *img2 = img-copy();
+  delete img;
   fl_delete_offscreen(off);
-  return img;
+  return img2;
   }
 
 

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


Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range

2013-04-21 Thread Ian MacArthur

On 14 Apr 2013, at 13:57, Duncan Gibson wrote:


 I have an application with a colour bar type legend which does not give
 the required resolution, so I needed to be able to adjust the low and
 high values in an intuitive but minimally invasive way on screen.
 
 I hacked together the following demonstrator, drawing some inspiration
 from Fl_Slider. The features I required were:
 - a vertical slider
 - possibility of setting min and max values of continuous range (no step)
 - possibility to move low and high sliders (min = low  high = max)
 
 I then hacked it further to fit directly with the rest of my application.
 
 Questions:
 1. Does anybody know of a similar widget out there?
 2. Is it worth factoring out a separate DoubleValuator base class?
 3. Apart from vertical/horizontal what other features are needed?
 4. Does it require min/low/high/max fields?
 5. Would a floating tooltip with feedback be enough? (eg Greg's TipWin)
 
 I'd be willing to have a go a this, but can't provide any timeframes.


Coming to this party late, but I just remembered that Jason Bryan's FLU widgets 
have a double-slider widget.

His pages at OSC.edu appear to be gone but the mirror here still seems to be 
working:

http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/ 

His FLU_Dual_Slider might be relevant, to see how what he did compares.

He derived a pile of new fltk based widgets, so there may be clues in that 
work for a template for future derivations?




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


Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selectinglow and high values within min/max range

2013-04-21 Thread Duncan Gibson

 Coming to this party late, but I just remembered that Jason Bryan's
 FLU widgets have a double-slider widget.

 His pages at OSC.edu appear to be gone but the mirror here still
 seems to be working:

 http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/=20

 His FLU_Dual_Slider might be relevant, to see how what he did
 compares.

 He derived a pile of new fltk based widgets, so there may be
 clues in that work for a template for future derivations?


I was going to say that the above link didn't work for me either
until I remembered to remove the =20 at the end. This will work:
http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/

It also reminded me that I had trawled through all of the Links
pages a while ago, and weeded out the dead links to come up with:

  Article #884: What third party widgets are available for FLTK?
  http://fltk.org/articles.php?L884

So why I hadn't remembered and checked there first I don't know :-(

If you go to the Flu_Dual_Slider doxygen page from the link above,
the list of public methods is quite limited, so the interface looks
to be quite simple. He does allow overlap where low == high.
He has derived it from Fl_Valuator, which is interesting, because
that only supports a single value so I would be curious how he
has implemented it.

However, although he appears to be using the FLTK licence, I don't
think we should just base our code on hiswithout understanding our
own vision / requirements.

Cheers
D.

PS. I shall update the article to include the link above [Done]

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


Re: [fltk.general] How to make a 3 position toggel switch

2013-04-21 Thread chris
Fl_Radio_Button may be what you need (if I understand your description
 correctly).

Cheers,
chris


I need to make a 3 position (on-off-on) toggle switch widget.

Can someone to point me to a toggle switch widget?

If one does not exist, can someone point me to an example/tutorial on how to 
make a custom toggle switch widget?

Thank You,

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


Re: [fltk.general] Fl_tile: don't shrink, just shift

2013-04-21 Thread Ian MacArthur

On 20 Apr 2013, at 22:04, dirac wrote:

 I'm building a stack of horizontal widgets, like that (I hope the ASCII
 art works):
 
 +---Fl_tile---+
 | +-+ |
 | | widget 0| |
 | +-+ |
 | +-+ |
 | | widget 1| |
 | +-+ |
 | +-+ |
 | | widget 2| |
 | +-+ |
 |++
 
 I would like to make each widget vertically resizable, so an Fl_tile
 seems a good choice for a container.

Though I suspect that initial reaction may be misleading...


 Unfortunately I've noticed that Fl_tile shrinks the other widgets: for
 example if I enlarge Widget 0 completely to the very bottom, widget 1
 and widget 2 disappear, i.e. their height becomes zero.


Yup, the issue here is (I think) that Fl_Tile, like many container widgets, is 
striving to maintain a fixed outer dimension, so as widget 1 grows, the other 
widgets in the container need to shrink...

I guess that what you want is a container widget that will grow/shrink as it's 
children grow/shrink.

And that's not quite the same thing as an Fl_Tile.

 
 My question: is there a way to extend Fl_tile so that it shifts the
 other widgets below Widget 0, instead of shrink them? Possibly Fl_tile
 should also expand itself vertically to make room for the other widgets.

Yes, though Fl_Tile may be the wrong place to start. I'd probably just start 
form an Fl_Group then modify the resize behaviour to match the changing sizes 
of the groups children...

Hmm, now, I seem to recall that Jason Bryan's FLU widget extensions for fltk 
had something like that - they would be worth a look.

OK; his pages at OSC.edu appear to be down, but there's a mirror here that 
still seems to work:

http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/ 


Maybe his collapsible group widget might give you some starting hints?




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


Re: [fltk.general] Fl_tile: don't shrink, just shift

2013-04-21 Thread Martin Kroeker
 Hmm, now, I seem to recall that Jason Bryan's FLU widget extensions =
 for fltk had something like that - they wo uld be worth a look.

 OK; his pages at OSC.edu appear to be down, but there's a mirror here =
 that still seems to work:

This came up a year ago - check STR2795
Latest FLU is hosted on sourceforge http://sourceforge.net/projects/flufltk/
Jason gave permission to integrate them, Fabien Constantini reported
that he had ported the full FLU2.14 widget set to 1.3 and volunteered
to integrate (at least?) its Fl_Tree implementation in 1.3/3.0

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


Re: [fltk.general] Fl_tile: don't shrink, just shift

2013-04-21 Thread Duncan Gibson
 I would like to make each widget vertically resizable, so an Fl_tile
 seems a good choice for a container.

IIRC, Fl_Tile imposes some constraints on how its children resize.

For a general description of how resizing works in FLTK, see
resizable()  at http://fltk.org/doc-1.3/classFl__Group.html

and then there's also Article #415: How does resizing work?
http://fltk.org/articles.php?L415

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


Re: [fltk.general] Fl_tile: don't shrink, just shift

2013-04-21 Thread Greg Ercolano
On 04/20/13 14:04, dirac wrote:
 Hi guys,
 
 I'm building a stack of horizontal widgets, like that (I hope the ASCII
 art works):
 
 +---Fl_tile---+
 | +-+ |
 | | widget 0| |
 | +-+ |
 | +-+ |
 | | widget 1| |
 | +-+ |
 | +-+ |
 | | widget 2| |
 | +-+ |
 |++
 
 I would like to make each widget vertically resizable, so an Fl_tile
 seems a good choice for a container.
 Unfortunately I've noticed that Fl_tile shrinks the other widgets: for
 example if I enlarge Widget 0 completely to the very bottom, widget 1
 and widget 2 disappear, i.e. their height becomes zero.
 
 My question: is there a way to extend Fl_tile so that it shifts the
 other widgets below Widget 0, instead of shrink them? Possibly Fl_tile
 should also expand itself vertically to make room for the other widgets.

I made one of these once; in my case I didn't use a tile,
just used a regular Fl_Group in which the widgets were positioned,
and put a thin widget between each that acted as a 'resizer' which:

1) enlarged/shrunk the widget above it
2) enlarged/shrunk the parent group
3) moved all the children below it up/down

The resizer class responded to FL_MOVE so that the cursor would
turn into a north/south cursor, and responded to FL_DRAG to handle
dragging. So basically:

 +---Fl_tile---+
 | +-+ |
 | | | |
 | | widget 0| |
 | | | |
 | +-+ |
 | | resizer | |
 | +-+ |
 | | | |
 | | widget 1| |
 | | | |
 | +-+ |
 | | resizer | |
 | +-+ |
 | | | |
 | | widget 2| |
 | | | |
 | +-+ |
 +-+

You can either have resizer make assumptions about parent() being
an Fl_Group and assume all widgets within that parent are inspected
to see if the widgets are above or below the current 'resizer' being
moved, so that only the widget immediately above is resized, and widgets
below are moved, and all the other child widgets are left alone.
Then just call the parent's init_sizes() to let it know the children
have changed size.

I suppose you could then put this entire group inside an Fl_Scroll, so
that if the children resize off the screen, a scroller will appear..
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk


Re: [fltk.general] Fl_tile: don't shrink, just shift

2013-04-21 Thread dirac
Thank you all so much for your hints: now I understand the real purpose and 
design of Fl_tile!
I think I'll opt for a derived Fl_Group as suggested by Ian and Greg.

All the best,

John



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


Re: [fltk.general] How to make a 3 position toggel switch

2013-04-21 Thread Greg Ercolano
On 04/21/13 02:09, Ian MacArthur wrote:
 Can someone to point me to a toggle switch widget?
 
 There's no 3-position switch that I'm aware of.
 When I needed this, I just put 3 radio-buttons in a group and that was fine - 
 and trivial to do.

Ya, or an Fl_Menu_Button with three items in it -- less screen real 
estate.
Use that if the user only needs to see which state the switch is in.

Otherwise, use the radio button approach if it's more useful that the 
user
see all three things, and which one of the three is on.

A toggle switch or 3 position dial would simulate the real world 
better,
but is perhaps not a good paradigm visually.

But if you really want to go that route, paint three images of the 
switch
in the various positions, and derive a class from Fl_Button that has one
of the switch images assigned as the image() for the button, and each 
hit
of the button switches the image() to show the other painting of the 
switch.
Set it up so that each hit toggles to the next of the three states. Use 
a char
or int to keep track of the current state, and just cycle through it 
each click;
0-1-2-1-0-1-2.. or 0-1-2-0-1-2.. whichever is best.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk