[fltk.commit] [Library] r9837 - branches/branch-1.3/examples
Author: greg.ercolano
Date: 2013-03-16 23:06:52 -0700 (Sat, 16 Mar 2013)
New Revision: 9837
Log:
Small fix to column max width calculation: take into account width of header.
Modified:
branches/branch-1.3/examples/table-sort.cxx
Modified: branches/branch-1.3/examples/table-sort.cxx
===
--- branches/branch-1.3/examples/table-sort.cxx 2013-03-17 05:24:58 UTC (rev
9836)
+++ branches/branch-1.3/examples/table-sort.cxx 2013-03-17 06:06:52 UTC (rev
9837)
@@ -39,7 +39,7 @@
#ifdef WIN32
// WINDOWS
# define DIRCMD dir
-# define DIRHEADER { Date, Time, Size, Filename, , , ,
, }
+static const char *G_header[] = { Date, Time, Size, Filename, , ,
, , , 0 };
# ifdef _MSC_VER
#define popen _popen
# endif
@@ -47,9 +47,15 @@
// UNIX
# include ctype.h
# define DIRCMD ls -l
-# define DIRHEADER { Perms, #L, Own, Group, Size, Date, ,
, Filename }
+static const char *G_header[] = { Perms, #L, Own, Group, Size,
Date, , , Filename, 0 };
#endif /*WIN32*/
+// Font face/sizes for header and rows
+#define HEADER_FONTFACE FL_HELVETICA_BOLD
+#define HEADER_FONTSIZE 16
+#define ROW_FONTFACEFL_HELVETICA
+#define ROW_FONTSIZE16
+
// A single row of columns
class Row {
public:
@@ -147,12 +153,11 @@
switch ( context ) {
case CONTEXT_COL_HEADER:
fl_push_clip(X,Y,W,H); {
-static const char *head[] = DIRHEADER;
fl_draw_box(FL_THIN_UP_BOX, X,Y,W,H, FL_BACKGROUND_COLOR);
if ( C 9 ) {
- fl_font(FL_HELVETICA_BOLD, 16);
+ fl_font(HEADER_FONTFACE, HEADER_FONTSIZE);
fl_color(FL_BLACK);
-fl_draw(head[C], X+2,Y,W,H, FL_ALIGN_LEFT, 0, 0);
// +2=pad left
+fl_draw(G_header[C], X+2,Y,W,H, FL_ALIGN_LEFT, 0, 0);
// +2=pad left
// Draw sort arrow
if ( C == _sort_lastcol ) {
draw_sort_arrow(X,Y,W,H);
@@ -166,7 +171,7 @@
// Bg color
Fl_Color bgcolor = row_selected(R) ? selection_color() :
FL_WHITE;
fl_color(bgcolor); fl_rectf(X,Y,W,H);
- fl_font(FL_HELVETICA, 16);
+ fl_font(ROW_FONTFACE, ROW_FONTSIZE);
fl_color(FL_BLACK); fl_draw(s, X+2,Y,W,H, FL_ALIGN_LEFT);
// +2=pad left
// Border
fl_color(FL_LIGHT2); fl_rect(X,Y,W,H);
@@ -181,13 +186,17 @@
// Automatically set column widths to widest data in each column
void MyTable::autowidth(int pad) {
-fl_font(FL_COURIER, 16);
-// Initialize all column widths to lowest value
-for ( int c=0; ccols(); c++ ) col_width(c, pad);
+int w, h;
+// Initialize all column widths to header width
+fl_font(HEADER_FONTFACE, HEADER_FONTSIZE);
+for ( int c=0; G_header[c]; c++ ) {
+ w=0; fl_measure(G_header[c], w, h, 0); // pixel width
of header text
+col_width(c, w+pad);
+}
+fl_font(ROW_FONTFACE, ROW_FONTSIZE);
for ( int r=0; r(int)_rowdata.size(); r++ ) {
-int w, h;
for ( int c=0; c(int)_rowdata[r].cols.size(); c++ ) {
-fl_measure(_rowdata[r].cols[c], w, h, 0); // get pixel
width of text
+w=0; fl_measure(_rowdata[r].cols[c], w, h, 0); // pixel
width of row text
if ( (w + pad) col_width(c)) col_width(c, w + pad);
}
}
___
fltk-commit mailing list
fltk-commit@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-commit
Re: [fltk.general] Alpha blending with Fl_PNG_Image
On 16.03.2013 03: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. As Ian and Greg pointed out already, alpha blending works with FLTK 1.3 (and even with 1.1), but there are some restrictions. Unfortunately you chose to use fl_draw_image(), but this function does support alpha blending only on Mac OS X with FLTK 1.3 (this is not intended, but currently that's how it is :-( ). In FLTK 1.1 and 1.3 you can use the image drawing methods instead, and *these functions* support alpha blending. So you can use the png image directly, as Greg did in his example (see his posting). You can also take a look at the source file test/unittest_images.cxx to see how it is done there. Note that this is a *unittest* code and not an example for good FLTK programming. However, the comments show what I stated above, and the code shows how you can use arbitrary image data, convert it to a RGB image, and use the image drawing method to draw it (selected by preprocessor macro IMG) vs. using fl_draw_image(), which would work only on OS X). As I said before, that's not the recommended way for your problem, since you could use the image drawing method with the png image. Upon further investigation, the documentation says that the only way to get transparency (and 100% transparency at that) is with an Fl_Pixmap (say, a GIF file), and that is definitely NOT RGB. Even so, would that work where this fails, albeit without the kinds of shadows I'm trying to cast in the PNGs? That's not up-to-date anymore, could you give a pointer where you read it exactly? This documentation should better be updated, but as I wrote before, the current state of image drawing was not intended and should be more consistent across platforms. However, it's not as easy to do it as it might seem, and somebody has to do it. Patches always welcome... The documentation also points out a function called fl_read_image() where I could copy out the area underneath where the PNG is destined to be drawn. Therefore I could do the alpha blend myself and then do a regular fl_draw_image() to put the blended image in place. Is this the only way it will work? No, see above. This is something you could do if the background changed outside of your control, but I wouldn't do it in your case. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
On 16.03.2013 09:24, Ian MacArthur wrote:
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.
And so would I. The visibility property could make an entire group
visible (show()) or invisible (hide()).
The redraw would then be sent to the group, hopefully that would work...!
I assume it would - however, the group would need a solid background,
e.g. one of the BOX types, probably FL_FLAT_BOX.
With judicious use of groups, you can possibly arrange for some of the
widgets to be in another group to reduce the redrawing somewhat...
Just as I wrote above? One group for _one_ image, bargraph, and whatever
else is needed for one station.
...
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...
This ought to be doable with damage(), but could indeed be a little
tricky to do it right. redraw() implicitly sets FL_DAMAGE_ALL in any
widget, but here you'd have to set FL_DAMAGE_CHILD for the parent
group and redraw() for the widget to be drawn or something like this
http://www.fltk.org/doc-1.3/classFl__Widget.html#ac92191cba5d17ae34bfc346d2126c9f2
to damage a particular region (like invalidateRect would do).
So, it CAN be done, but ...
If the update rate is low, it is probably not worth the extra effort - just
redrawing the lot will be simpler!
Agreed 100% ! Don't optimize prematurely. It's much easier and saves
a lot of trouble and testing to (re)draw entire groups, unless you
(the OP) really need(s) it.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
As Ian and Greg pointed out already, alpha blending works with FLTK 1.3 (and even with 1.1), but there are some restrictions. Greg's method works like a champ and I actually found it about 1/2 hour after I posted this in the forum. Thanks! Upon further investigation, the documentation says that the only way to get transparency (and 100% transparency at that) is with an Fl_Pixmap (say, a GIF file), and that is definitely NOT RGB. Even so, would that work where this fails, albeit without the kinds of shadows I'm trying to cast in the PNGs? That's not up-to-date anymore, could you give a pointer where you read it exactly? This documentation should better be updated, but as I wrote before, the current state of image drawing was not intended and should be more consistent across platforms. However, it's not as easy to do it as it might seem, and somebody has to do it. Patches always welcome... Here's the link to the documentation that says it: http://fltk.org/doc-1.3/drawing.html Search on the page for the word transparency... The documentation also strongly discourages people from using the -draw() method of widgets. My problem is solved, thank you. But the docs are, shall we say, confusing. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
