Murga-Projects Forums
feedback please - Printable Version

+- Murga-Projects Forums (http://www.murga-projects.com/forum)
+-- Forum: Project Forums (/forumdisplay.php?fid=1)
+--- Forum: MurgaLua - General (/forumdisplay.php?fid=2)
+--- Thread: feedback please (/showthread.php?tid=370)


feedback please - mikshaw - 06-29-2009 11:51 AM

I'm trying to work out something useful from Fl_Positioner, and so far have something that will reposition a secondary window on the desktop according to the location of the positioner's axis in the primary window. Unfortunately when the secondary window reaches the right or bottom side of the screen it jumps back halfway across the screen. At this time I don't know if it's because of a bug in FLTK or a limitation of my tiling window manager. I appreciate any feedback from people using more traditional desktop environments.

Code:
ww=Fl:w()/4
wh=Fl:h()/4

w=fltk:Fl_Double_Window(ww,wh+50,"positioner.lua")
w:callback(function() os.exit() end) -- forces both windows to close

posy=fltk:Fl_Positioner(0,0,ww,wh,"fltk:Fl_Positioner")

posy_xvalue=fltk:Fl_Output(0,wh+25,ww/2,25)
posy_yvalue=fltk:Fl_Output(ww/2,wh+25,ww/2,25)

posy:xstep(1)
posy:ystep(1)
posy:xbounds(0,Fl:w()) -- uses screen sizes for maximum values
posy:ybounds(0,Fl:h())

posy:callback(
function()
  posy_xvalue:value(" X: "..posy:xvalue())
  posy_yvalue:value(" Y: "..posy:yvalue())
  w2:position(posy:xvalue(),posy:yvalue()) -- set w2 position on desktop
end
)
fltk:Fl_End()
w2=fltk:Fl_Window(0,0,8,8)
w2:color(1)
w2:border(0)
w2:box(fltk.FL_UP_BOX)
fltk:Fl_End()
w:show()
w2:show()
Fl:run()




RE: feedback please - mikshaw - 06-30-2009 01:13 AM

Also having trouble with this one. The original had changed color index 15 in order to display a color chosen with fl_color_chooser(). That was annoying to me, and more annoying after I included the rgb and hex values in the tooltips of the colored boxes. I started using fl_rgb_color() to change the color of the color_chooser button so the initial 256 indexed colors wouldn't be bothered, and that seemed to work well until I noticed something weird.

There seems to be a bug in the way fl_rgb_color() is applying the colors in the red spectrum. Regardless of which color is chosen from the red side of the picker, the button always ends up being colored 128 0 0. The fl_color_cube button seems to receive the proper color from that chosen in the color picker, so I suspect either a bug in fl_rgb_color, or I'm not using it right.

EDIT: So far it looks like fl_rgb_color succeeds as long as the R value is less than 128. The G and B values can be whatever you want, but anything over 127 for R will cause the function to return 128 0 0. I'm surprised this hasn't come up before...no mention of it from a web search...so maybe something went weird in the murgaLua bindings?

Code:
w=fltk:Fl_Double_Window(500,400,"colors.lua")

-- make a 16x16 array of 20px boxes, 10px from the left edge
colors = {}
row=20;switch=15;bw=20;left=10
for i = 0,255 do
  colors[i]=fltk:Fl_Box(left+bw,row,bw,bw)
  colors[i]:color(i)
  colors[i]:box(fltk.FL_THIN_UP_BOX)
  local r,g,b=Fl:get_color(i,r,g,b) -- get RGB values of current color
  -- show color index, rgb, and html values in tooltip
  colors[i]:tooltip("Color index: "..i.."\nRGB: "..r.." "..g.." "..b.."\nHTML: "..string.format("#%.2X%.2X%.2X",r,g,b))
  left=left+bw -- next box will be placed 20px to the right
  if i == switch then -- if we have reached 16 boxes
    switch = switch+16  -- next switch position will be in 16 loops
    row = row+bw        -- move to next row
    left = 10           -- move back to first column
  end
end


colormap=fltk:Fl_Button(380,20,100,80,"fl_show_colormap")
colormap:align(fltk.FL_ALIGN_BOTTOM)
colormap:callback(
function(colormap_cb)
-- pick an indexed color and apply it to the button
  local newcolor=fltk.fl_show_colormap(colormap:color())
  colormap:color(newcolor)
  colormap:label("FLTK Color "..newcolor)
  w:redraw()
end
)

colorchooser=fltk:Fl_Button(380,125,100,80,"fl_color_chooser")
colorchooser:align(fltk.FL_ALIGN_BOTTOM)
colorchooser:callback(
function(colorchooser_cb)
  local color_ok,r,g,b -- initialize local variables
  r,g,b=Fl:get_color(colorchooser:color(),r,g,b)
  color_ok,r,g,b=fltk.fl_color_chooser("starting color: "..r.." "..g.." "..b,r,g,b)
  if color_ok == 1 then -- color_ok represents the first value (exit status) returned by fl_color_chooser
    hexcolor=string.format("#%.2X%.2X%.2X",r,g,b) -- convert the rgb values to hex
    colorchooser:color(fltk.fl_rgb_color(r,g,b)) -- apply rgb color to button
    -- set the color_cube box color
    color_cube:color(fltk.fl_color_cube(r * (fltk.FL_NUM_RED - 1) / 255,g * (fltk.FL_NUM_GREEN - 1) / 255,b * (fltk.FL_NUM_BLUE - 1) / 255))
    color_cube:label("fl_color_cube: "..color_cube:color())
    colorchooser:label("Color "..colorchooser:color().."\nRGB "..r.." "..g.." "..b.."\nHTML "..hexcolor)
    w:redraw()
  end
end
)

color_cube=fltk:Fl_Box(380,260,100,80,"fl_color_cube")
color_cube:align(fltk.FL_ALIGN_BOTTOM)
color_cube:box(fltk.FL_UP_BOX)

w:show()
Fl:run()




RE: feedback please - jpjacobs - 06-30-2009 06:01 AM

The first one works as expected here (even with a tiling wm Wink)
There is indeed something weird going on in the second snippet, however, I don't see where it comes from...
JP


RE: feedback please - mikshaw - 06-30-2009 12:28 PM

Thanks for testing. I was planning eventually to test the first one on a more traditional desktop,but I've been pitifully lazy about it. Which tiling window manager did you test? I'm using dwm 5.4.1...downloaded 5.5 but haven't installed it yet. I've seen other weird things with 5.4, but as I said I'm lazy =o)

I spent a couple of hours poking at the second one and never came up with a solution. All I can say is it seems like a bug somewhere.

Did make a few more changes to the second one, to make it a little more useful..

Code:
w=fltk:Fl_Double_Window(500,420,"colors.lua")

function col_cb(self)
col_outpoot:value(self:tooltip())
colormap:color(self:color())
w:redraw()
end

-- make a 16x16 array of 20px boxes, 30px from the left edge
colors = {}
row=20;switch=15;bw=20;left=10
for i = 0,255 do
  colors[i]=fltk:Fl_Button(left+bw,row,bw,bw)
  colors[i]:type(fltk.FL_RADIO_BUTTON)
  colors[i]:selection_color(i)
  colors[i]:color(i)
  colors[i]:box(fltk.FL_THIN_UP_BOX)
  local r,g,b=Fl:get_color(i,r,g,b) -- get RGB values of current color
  -- show color index, rgb, and html values in tooltip
  colors[i]:tooltip("Color index: "..i.."\nRGB: "..r.." "..g.." "..b.."\nHTML: "..string.format("#%.2X%.2X%.2X",r,g,b))
  colors[i]:callback(col_cb)
  left=left+bw -- next box will be placed 20px to the right
  if i == switch then -- if we have reached 16 boxes
    switch = switch+16  -- next switch position will be in 16 loops
    row = row+bw        -- move to next row
    left = 10           -- move back to first column
  end
end

col_outpoot=fltk:Fl_Multiline_Output(30,17*bw,16*bw,60)

colormap=fltk:Fl_Button(380,20,100,80,"fl_show_colormap")
colormap:align(fltk.FL_ALIGN_BOTTOM)
colormap:callback(
function(colormap_cb)
-- pick an indexed color and apply it to the button
  local newcolor=fltk.fl_show_colormap(colormap:color())
  colormap:color(newcolor)
-- colormap:label("FLTK Color "..newcolor)
  colors[newcolor]:setonly()
  colors[newcolor]:do_callback()
end
)

colorchooser=fltk:Fl_Button(380,125,100,80,"fl_color_chooser")
colorchooser:align(fltk.FL_ALIGN_BOTTOM)
colorchooser:callback(
function(colorchooser_cb)
  local color_ok,r,g,b,cube_color -- initialize local variables
  r,g,b=Fl:get_color(colorchooser:color(),r,g,b)
  color_ok,r,g,b=fltk.fl_color_chooser("starting color: "..r.." "..g.." "..b,r,g,b)
  if color_ok == 1 then -- color_ok represents the first value (exit status) returned by fl_color_chooser
    hexcolor=string.format("#%.2X%.2X%.2X",r,g,b) -- convert the rgb values to hex
    colorchooser:color(fltk.fl_rgb_color(r,g,b)) -- apply 24-bit rgb color to button
    --colorchooser:color(fltk.fl_rgb_color(127,192,33)) -- debug
    -- set the color_cube box color
    cube_color=fltk.fl_color_cube(r * (fltk.FL_NUM_RED - 1) / 255,g * (fltk.FL_NUM_GREEN - 1) / 255,b * (fltk.FL_NUM_BLUE - 1) / 255)
    color_cube:color(cube_color)
    color_cube:label("fl_color_cube: "..cube_color)
    colors[cube_color]:setonly()
    colors[cube_color]:do_callback()
    colorchooser:label("Color "..colorchooser:color().."\nRGB "..r.." "..g.." "..b.."\nHTML "..hexcolor)
    w:redraw()
  end
end
)

color_cube=fltk:Fl_Box(380,260,100,80,"fl_color_cube")
color_cube:align(fltk.FL_ALIGN_BOTTOM)
color_cube:box(fltk.FL_UP_BOX)

w:show()
Fl:run()




RE: feedback please - jpjacobs - 07-01-2009 04:21 AM

I tested on awesome 2.3.2 (Morning Yearning).


RE: feedback please - MrBill - 07-02-2009 03:34 AM

All seem to work ok here on a Mac, can't seem to see any of those bugs you are trying to get around.

The only time I get 128 0 0 is if I close the color picker with its default picked color.


RE: feedback please - mikshaw - 07-02-2009 12:33 PM

There's just the one bug now...after jp mentioned no trouble I tried the positioner on a couple of other window managers without trouble, so I'm assuming my problem there is related to dwm being very strict about keeping windows onscreen....though it seems it could just stop the window from moving further rather than moving back to the center of the screen.

Quote:
The only time I get 128 0 0 is if I close the color picker with its default picked color.

This still seems related...you shouldn't get 128 0 0 unless that's the color you intentionally picked. There is no default color beyond defaulting to the last chosen color. The color chooser starts out with the color of the button (originally just the default background gray), and is supposed to change the button's color to whatever you chose (or stick with the previous color if canceled). It seemed to use the right color when I applied the RGB color to one of the FLTK color indexes before setting the color of a widget (which changed the color of everything using that index, so I didn't like that behavior), but it's having trouble applying certain RGB colors directly to a widget.


RE: feedback please - jpjacobs - 11-29-2010 10:08 PM

Well, I've been investigating a bit on the red colorchannel thing, and it seems that fltk itself (tested in C++) has no problems with 255,0,0 , but murgaLua does... so it seems something has gone wrong :color() method. (it's not in the fl_rgb_color(r,g,b) function, I tested with :color(0xff000000)).
I'll try to find the culprit in the sources.

Edit: After looking around in the code, I guess the error would be in the lua_call2_Fl_Widget__color function near line 18584 in bind-fltk.cxx. My C++ foo is a bit low, so I can't actually spot the error. (I've got a hunch its something with the elaborate casting being done there...).

In the meantime, I've come up with a script which also demonstrates the problem:

Code:
-- proggie to gradually change a window of color between 3 colors listed below
colors = {{255,0,0},{0,255,0},{0,0,255}}
w=fltk:Fl_Double_Window(300,300,"ColorCube")
w:color(fltk.fl_rgb_color(unpack(colors[1])))

function mix(x,colors) -- in radians, 0 = c1, 2pi/3 = c2 4pi/3=c3
    local function sel(x,rot)
        local res= math.max(0,math.sin(x*3/2+rot))
        return res
    end
    local r,g,b,r1,r2
    r1=2*math.pi/3;r2=r1*2
    r=math.floor(colors[1][1]*sel(x,0)+colors[2][1]*sel(x,r1)+colors[3][1]*sel(x,r2))
    g=math.floor(colors[1][2]*sel(x,0)+colors[2][2]*sel(x,r1)+colors[3][2]*sel(x,r2))
    b=math.floor(colors[1][3]*sel(x,0)+colors[2][3]*sel(x,r1)+colors[3][3]*sel(x,r2))
    return fltk.fl_rgb_color(r,g,b)
end

function run_anim_cb()
    pos=math.fmod(pos+math.pi/100,2*math.pi)
    w:make_current()
    local cur_col = mix(pos,colors)
    w:color(cur_col)
    print(string.format("set color 0x%08x , got color 0x%08x .",cur_col,w:color()))
    w:redraw()
    Fl:wait()
    murgaLua.sleep(50)
end

w:callback(run_anim_cb);
w:show()

pos=0
while (Fl:event_key() ~= fltk.FL_Escape)  do
    Fl:check()
    w:do_callback()
end


This should give a nice colorchanging window, but it get's stuck when it starts printing out 2 different numbers.

PS: this problem is still present in the 0.7 snapshot.

greetings, JP


RE: feedback please - mikshaw - 11-30-2010 01:55 PM

That's a really good demonstration of the problem, and would be a really good demonstration in general =o)

This is another good example of something i'd enjoy doing if I didn't suck at maths.


RE: feedback please - JohnMurga - 12-06-2010 07:05 AM

jpjacobs Wrote:
This should give a nice colorchanging window, but it get's stuck when it starts printing out 2 different numbers.

PS: this problem is still present in the 0.7 snapshot.

greetings, JP

Thanks for the demonstration ...

I will look into fixing this for the final release (this month).

Cheers
John de Murga


RE: feedback please - mikshaw - 12-06-2010 08:08 AM

On a possibly related note...
I tried to set the default selection color and ran into this problem then as well.

Non of these worked...resulted either in black or 128-0-0
Fl:set_color(fltk.FL_SELECTION_COLOR,120)
Fl:set_color(fltk.FL_SELECTION_COLOR,Fl:get_color(120))
Fl:set_color(fltk.FL_SELECTION_COLOR,Fl:get_color(some_widget:color()))

This one, however, worked:
Fl:set_color(fltk.FL_SELECTION_COLOR,Fl:get_color(120,r,g,b))
I don't know how the r,g,b comes into play, but I noticed earlier that the same thing is needed for fl_color_cube. I'm guessing the function must be applying values to those variables itself, but it seems odd that we would have to even be aware of this...wouldn't it be simpler (and less confusing) for fltk to have those variables be declared within the function, where we don't have to care about them?


RE: feedback please - jpjacobs - 12-06-2010 10:05 AM

The FLTK documentation says:

Quote:
void set_color(Fl_Color, uchar, uchar, uchar);
void set_color(Fl_Color, unsigned);

Sets an entry in the fl_color index table. You can set it to any 8-bit RGB color. The color is not allocated until fl_color(i) is used.


That might explain that you don't see a change directly

For the getcolor thing: the FLTK docs give 2 possible uses of getcolor: one with 1 argument, one with 4.
The one argument version simply returns 1 value (the Fl_Color, which in fact is 0xRRGGBBII where RR,GG,BB are the RGB values, and II is the index of the color in the palette).
The 3 last arguments of the 4 argument version are references to variables where the function will leave the RGB values, at least that's in C++. If I'm interpreting the fltk binding code correctly, in Lua it just returns the RGB components, and the 4 argument thing is just for signalling we want the seperate components too. As such, it's just an artifact of a limitation in C++ that doesn't exist in Lua, so I think it wouldn't be bad to simply always return everything (so Fl_Color, R,G,B). More generally it wouldn't be a bad idea to look for other functions which have references (or whatever the &var is), I think lots of times they are used for emulating a multi-value return.

So putting it shortly: merge these functions to one, returning the Fl_color and 3 components, without requiring the 4 arguments.

Greetings,

Jan-Pieter


RE: feedback please - mikshaw - 12-07-2010 01:37 AM

That makes some amount of sense to me, though it will take some time and experimentation for it to sink in.

I incorrectly assumed Fl_Color constants were used simply to store a Fltk color index, which would explain why trying to use a single integer results in failure.