[fltk.commit] [Library] r9836 - branches/branch-1.3/src
Author: greg.ercolano
Date: 2013-03-16 22:24:58 -0700 (Sat, 16 Mar 2013)
New Revision: 9836
Log:
Added examples for Fl::option() methods
Modified:
branches/branch-1.3/src/Fl.cxx
Modified: branches/branch-1.3/src/Fl.cxx
===
--- branches/branch-1.3/src/Fl.cxx 2013-03-10 15:14:03 UTC (rev 9835)
+++ branches/branch-1.3/src/Fl.cxx 2013-03-17 05:24:58 UTC (rev 9836)
@@ -1931,6 +1931,14 @@
There should be an application that manages options system wide, per user, and
per application.
+ Example:
+ \code
+ if ( Fl::option(Fl::OPTION_ARROW_FOCUS) )
+ { ..on.. }
+ else
+ { ..off.. }
+ \endcode
+
\note As of FLTK 1.3.0, options can be managed within fluid, using the menu
iEdit/Global FLTK Settings/i.
@@ -1992,6 +2000,12 @@
This function does not change any system or user settings.
+ Example:
+ \code
+ Fl::option(Fl::OPTION_ARROW_FOCUS, true); // on
+ Fl::option(Fl::OPTION_ARROW_FOCUS, false);// off
+ \endcode
+
\param opt which option
\param val set to true or false
\see enum Fl::Fl_Option
___
fltk-commit mailing list
fltk-commit@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-commit
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-feature
Attached file fltk-1.3.x-r9835-gleam-4.3.patch...
Link: http://www.fltk.org/str.php?L2672
Version: 1.4-featureIndex: src/fl_gleam.cxx
===
--- src/fl_gleam.cxx(revision 0)
+++ src/fl_gleam.cxx(revision 0)
@@ -0,0 +1,131 @@
+//
+// Gleam drawing routines for the Fast Light Tool Kit (FLTK).
+//
+// Copyright 1998-2010 by Bill Spitzak and others.
+//
+// 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 on the following page:
+//
+// http://www.fltk.org/str.php
+//
+// These box types provide a sort of Clearlooks Glossy scheme
+// for FLTK.
+//
+// Copyright 2001-2005 by Colin Jones.
+//
+// Modified 2012-2013 by Edmanuel Torres
+// This is a new version of the fl_gleam. The gradients are on the top
+// an the bottom, the text area looks like in the classic FLTK way.
+//
+
+#include FL/Fl.H
+#include FL/fl_draw.H
+#include iostream
+
+using namespace std;
+
+static void gleam_color(Fl_Color c) {
+ if (Fl::draw_box_active()) fl_color(c);
+ else fl_color(fl_inactive(c));
+}
+
+static void shade_rect_top_bottom(int x, int y, int w, int h, Fl_Color fg1,
Fl_Color fg2, float th) {
+ // Draws the shiny using maximum limits
+ int h_top = min(h/2,20);
+ int h_bottom = min(h/6,15);
+ int h_flat = h-(h_top+h_bottom);
+ int j = 0;
+ float step_size_top = h_top1?(0.999/(float)(h_top)):1;
+ float step_size_bottom = h_bottom1?(0.999/(float)(h_bottom)):1;
+ // This loop generates the gradient at the top of the widget
+ for (float k = 1; k = 0; k -= step_size_top){
+gleam_color(fl_color_average(fl_color_average(fg1, fg2, th), fg1, k));
+fl_line(x, y+j, x+w, y+j);
+j++;
+ }
+ gleam_color(fg1);
+ fl_rectf(x, y+h_top, w+1, h_flat);
+ // This loop generates the gradient at the bottom of the widget
+ for (float k = 1; k = 0; k -= step_size_bottom){
+gleam_color(fl_color_average(fg1,fl_color_average(fg1, fg2, th), k));
+fl_line(x, y+j+h_flat-1, x+w, y+j+h_flat-1);
+j++;
+ }
+}
+
+static void shade_rect_top_bottom_up(int x, int y, int w, int h, Fl_Color bc,
float th) {
+ shade_rect_top_bottom(x,y,w,h,bc,FL_WHITE,th);
+}
+
+static void shade_rect_top_bottom_down(int x, int y, int w, int h, Fl_Color
bc, float th) {
+ shade_rect_top_bottom(x,y,w,h,bc,FL_BLACK,th);
+}
+
+static void frame_rect(int x, int y, int w, int h, Fl_Color fg1, Fl_Color fg2,
Fl_Color lc) {
+ gleam_color(fg1);
+ fl_line(x, y+h-1, x, y+1); //Go from bottom to top left side
+ fl_line(x+w, y+h-1, x+w, y+1); //Go from bottom to top right side
+ fl_line(x+1, y, x+w-1, y); //Go across the top
+ fl_line(x+1, y+h, x+w-1, y+h); //Go across the bottom
+ gleam_color(fg2);
+ fl_line(x+1, y+h-2, x+1, y+2); //Go from bottom to top left side
+ fl_line(x+w-1, y+h-2, x+w-1, y+2); //Go from bottom to top right side
+ gleam_color(lc);
+ fl_line(x+2, y+1, x+w-3, y+1); //Go across the top
+ fl_line(x+2, y+h-1, x+w-3, y+h-1); //Go across the bottom
+}
+
+static void frame_rect_up(int x, int y, int w, int h, Fl_Color bc, Fl_Color
lc, float th1, float th2) {
+ frame_rect(x,y,w,h,fl_color_average(fl_darker(bc), FL_BLACK,
th1),fl_color_average(bc, FL_WHITE, th2),lc);
+}
+
+static void frame_rect_down(int x, int y, int w, int h, Fl_Color bc, Fl_Color
lc, float th1, float th2) {
+ frame_rect(x,y,w,h,fl_color_average(bc, FL_WHITE,
th1),fl_color_average(FL_BLACK, bc, th2),lc);
+}
+
+static void up_frame(int x, int y, int w, int h, Fl_Color c) {
+ frame_rect_up(x, y, w-1, h-1, c, fl_color_average(c, FL_WHITE, .25f), .55f,
.05f);
+}
+
+static void up_box(int x, int y, int w, int h, Fl_Color c) {
+ shade_rect_top_bottom_up(x+2, y+1, w-5, h-3, c, .15f);
+ frame_rect_up(x, y, w-1, h-1, c, fl_color_average(c, FL_WHITE, .05f), .15f,
.05f);
+}
+
+static void thin_up_box(int x, int y, int w, int h, Fl_Color c) {
+ shade_rect_top_bottom_up(x+2, y+1, w-5, h-3, c, .25f);
+ frame_rect_up(x, y, w-1, h-1, c, fl_color_average(c, FL_WHITE, .45f), .25f,
.15f);
+}
+
+static void down_frame(int x, int y, int w, int h, Fl_Color c) {
+ frame_rect_down(x, y, w-1, h-1, fl_darker(c), fl_darker(c), .25f, .95f);
+}
+
+static void down_box(int x, int y, int w, int h, Fl_Color c) {
+ shade_rect_top_bottom_down(x+1, y+1, w-3, h-3, c, .65f);
+ frame_rect_down(x, y, w-1, h-1, c, fl_color_average(c, FL_BLACK, .05f),
.05f, .95f);
+}
+
+static void thin_down_box(int x, int y, int w, int h, Fl_Color c) {
+ shade_rect_top_bottom_down(x+1, y+1, w-3, h-3, c, .85f);
+ frame_rect_down(x, y, w-1, h-1, c, fl_color_average(c, FL_BLACK, .45f),
.35f, 0.85f);
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature Gleam 4.3 against fltk-1.3.x-r9835 with some improvements as suggested by Albrecht. Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.general] R: Bargraph object with Fl_Group
So good speaking with you, boys.
Greg wrote:
If the image is assigned to the bargraph's group, then just telling the
bargraph widget to redraw() will do it.
But if the image is assigned to the parent window, then you'll have to tell
the parent window to redraw.
Be sure to use an Fl_Double_Window to prevent flickering during redraws.
This is exactly what I am doing now.
Ian wrote:
So long as the background is drawn by your app, then it is feasible to
composite the bar graphs and etc on top of it.
But: If the background is drawn by some other app, or is otherwise outside
the control of your app windows, then compositing the graphs and so forth on
top becomes Very Tricky.
For now the simplest solution I can imagine is to redraw the whole parent of
my object.
Quite possibly: I think we need to understand more about the nature of
the backgrounds, how they are drawn etc, and from there we can figure
out how to render the graphs on top of them...
Well, there is no window manager ; I have microwindows sitting over the
framebuffer and a single fltk application which does everything, so the
situation is conceptually simple,
because everything is drawn from one single app. Background programs to acquire
remote variables, but only one app writing on lcd.
I manage all the firmware, from bios to Linux kernel to user interface, so I
have full control on the machine.
I am trying to create objects as simple as possible : generally speaking every
object has some functions to animate itself, requesting variables from a
remotely connected machine.
For example:
Think of a plant which, in its full realization, is composed of 4 identical
stations (tanks, motors, etc.) .
For each station the plant supervision designer will put:
- one background image (the drawing of the station) with a visible boolean
coming from remote
- one bargraph (value, min, max, visible boolean)
- one box displaying a numeric value (value, format, visible boolean)
- one multiple-image box representing the run status (off, on, waiting, etc.)
- (image index, visible boolean)
- one start/stop button
- etc. etc.
Now a plant is smaller and has only two stations: the remote machine will put
some visible booleans to zero... and the graphics app
will show only the installed stations.
So one can think: I create a group with image, bargraph, boxes and it's done.
I can't do this, because my app has to be general: it's the plant installer who
knows how the plant is made.
He will create the configuration file for my app (we created a Windows software
for this), specifying where (x, y) and how big the objects are.
It's the classic supervision software : as general as possible. Windows
software to visually design the plant -- configuration file -- my embedded
software
to parse it and show / animate objects.
-
Coming back to the problem: instead of redrawing all the bargraph parent, IMHO
the key point could be the ability to invalidate only one small portion of
the parent,
the rectangular portion under the bargraph.
Bargraph::RedrawObject()
{
parent()-invalidateRect(xBar, yBar, wBar, hBar);
redraw();
}
First instruction tells the parent to redraw only the part under the bargraph,
and the second redraws the bargraph.
Obviously this is general: all objects needing some sort of transparency should
behave this way.
Thanks
Lucio
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
On 16 Mar 2013, at 02:21, Chris Russ wrote: I've been working on a widget that can show images zoomed in and out at arbitrary percentages, and that part works. Now, in the middle of my ::draw() function I want to overlay some RGBA PNG images -- these have transparency where I'd like the underlying image to show up. I can make the images show up in the right places, but the alpha channel is being completely ignored in this little snippet: void *baseaddr = (void *)(head-image_-data()[0]); int imagew = head-image_-w(); int imageh = head-image_-h(); int imaged = head-image_-d(); fl_draw_image((const uchar *)baseaddr, x, y, imagew, imageh, imaged); head-image_ in this case was an Fl_PNG_Image that should have 4 channels. It has been cast into an Fl_RGB_Image, which should be a compatible type. But alpha blending isn't happening. I'm getting white where there should be transparency to the pixels previously drawn in the buffer. Instead, I should be getting a blend using the variable opacity in the A channel. Hi Chris, I think this pretty much ought to work, at least with fltk-1.3.x. What version are you using? Anyway, take a look at the unittests demo from the test folder,one of the tabs there is about image blending and such (IIRC the tab is titled drawing images. Does that work on your system? ISTR it maybe only works on W32 and OSX, not sure about X11... Anyway, the code for that tab is in the file unittest_images.cxx, so that might yeild some clues! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
Correction: I hinted that the unittest_images demo did not work right on X11, but I just fired up a VM to check and it worked fine for me (Ubuntu-12.10 VM) with fltk-1.3.x-r9835 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
On 16 Mar 2013, at 06:28, memoryl...@tin.it wrote:
Now a plant is smaller and has only two stations: the remote machine will put
some visible booleans to zero... and the graphics app
will show only the installed stations.
So one can think: I create a group with image, bargraph, boxes and it's done.
I can't do this, because my app has to be general: it's the plant installer
who knows how the plant is made.
He will create the configuration file for my app (we created a Windows
software for this), specifying where (x, y) and how big the objects are.
I *think* what I'd do is create a group (probably with a FLAT_BOX type) that
contained just the required widgets - I'd populate this at runtime with widgets
as required based on reading the config file.
The redraw would then be sent to the group, hopefully that would work...!
With judicious use of groups, you can possibly arrange for some of the widgets
to be in another group to reduce the redrawing somewhat...
What sort of update rate are you looking for?
If the rate is slow, then redrawing the whole lot, in a double_buffered window,
will be smooth and relatively painless.
Will depend on how powerful your device is of course, but if it is plant
control, then animating at a few Hz may be fast enough, without taking too much
resource away from other tasks? Humans can't actually respond to inputs much
faster anyway, so refreshing at more than a 2 or 3 FPS is just wasting cycles -
we are not making a movie or a video game here, so we don't need 60 FPS to make
things work!
Coming back to the problem: instead of redrawing all the bargraph parent,
IMHO the key point could be the ability to invalidate only one small
portion of the parent,
the rectangular portion under the bargraph.
Bargraph::RedrawObject()
{
parent()-invalidateRect(xBar, yBar, wBar, hBar);
redraw();
}
First instruction tells the parent to redraw only the part under the
bargraph, and the second redraws the bargraph.
Obviously this is general: all objects needing some sort of transparency
should behave this way.
You can manage this by controlling the damage regions for your widgets - but
you still need to do the redrawing of the damaged regions yourself, the toolkit
will not do it for you...
If the update rate is low, it is probably not worth the extra effort - just
redrawing the lot will be simpler!
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
On 03/15/13 19:21, Chris Russ wrote: But alpha blending isn't happening. This technique works for me: http://seriss.com/people/erco/fltk/#AlphaBlend ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
