Image 01


Ate Nine Vilnius, Lithuania
Jump to time Previous frame v3

VLC Extensions 49 comments

Score 58.0%
Aug 28 2018
lua environment detection code example - Sep 23 2015
-- get OS unix way
d:add_label(io.popen("uname -s"):read("*l") , 1,4,2,1)

-- get exact version OS X way
v = assert ( io.popen("sw_vers") )
row = 5;
for s in v:lines() do
d:add_label( s , 2,row,1,1)
row = row + 1

-- tostring(os.getenv("OSTYPE")), returns nill
-- user config dir is dependent on user name and typically is /Users/username/Library/Application Support/org.videolan.vlc

Screenshots, layouts and env. detection

1. [it's quite ok with default fonts]
2. [if wide version, then I'd vote for this]
3. [as drop down does not seam to react at colspan]

4. [enviroment]

Ampersands "&", keyboard shortcuts do not work at all. Probably best is to remove them.
There is no "default" submit button. I can tab only in between inputs, pressing enter does nothing, dialog or inputs have no default action attached.

- Sep 23 2015
Stacking focusable elements one on another may seem as a good workaround, still it isn't. If you target multi-platform environment you can't rely on default behavior of such elements stacking, especially if you have no direct control of their z-ordering.

In this case on os x, rightmost buttons were hiding behind inputs only if doing something in that input (focusing, entering text, pressing other button). What happened, I think, OS or library simply recreated/redraw input element, and it became top on a stack. Should it be left at a same creation order, yea probably, you may hope so.

Imho, unless and until vlc lua dialog code implement explicit z-order parameter for elements stacking and vlc coders enforce it's behavior in any of supported os gui - relying, on inexplicit z-ordering (creation order in source code), is erroneous. You simply can't rely on initial elements creation order if something is changing latter. What we have faced here - last focused element in OS X is always on top :), and no way back, button is deep behind with no way to click through. Is it bad default behavior of gui kit? No, actually, it is quite useful and logical behavior - get focused on top.

P.S. simply cols span 1 instead of 2 was not a better solution. Left input twice wide, to keep current time input text visible even if it is shown in its longest format with widest weirdest user font :)

Let it be a feature, not a bug - as we say ;)

Attaching screens:
1. [ just launched ]
2. [after focusing input, editing, pressing get time]
3. [after focusing input, selecting time format from drop, pressing use selected]

4. [after a, erroneous stacking workaround, fix] - Sep 19 2015
Hi, mederi (or someone who can commit into the code). Have fixed a bug for all us. Dialog elements colspan and col positions needed some adjustments as two buttons were overlapped with inputs. Here is the right code:

function Create_dialog()
d = vlc.dialog(descriptor().title)

d:add_label(string.rep(" ",27),1,1,1,1)
d:add_label(string.rep(" ",27),2,1,1,1)
d:add_label(string.rep(" ",27),3,1,1,1)

d:add_button("&Get time >>", click_Get_time, 1,1,1,1)
textinput_time = d:add_text_input(Time2string(0), 2,1,2,1) -- "00:00:00,000"
d:add_button(">> &Set time", click_Set_time, 4,1,1,1)

d:add_button("&Time format", click_Switch_time_format, 1,2,1,1)
dropdown_jump = d:add_dropdown(2,2,1,1)
for i,v in ipairs(jumps) do
d:add_button("&Use selected", click_Use_jump, 3,2,1,1)

d:add_button("&Backward <<", function() click_Jump(-1) end, 1,3,1,1)
textinput_jump = d:add_text_input(jumps[1][2], 2,3,2,1) -- default jump length (1-st in the list)
d:add_button(">> &Forward", function() click_Jump(1) end, 4,3,1,1)

- Sep 15 2015