added features, compiler warning fix, and gitignore .dep files

[gravity-addiction]

gslc_SetScreenDisableRedraw(pGui, true); // skips screen draws while true, default: false
gslc_SetTouchDisabled(pGui, true); // skips executing touch events while true, default: false

[ImpulseAdventure]

Hi @gravity-addiction -- thank you for these updates!

Regarding the SetTouchDisabled() and SetScreenDisableRedraw(), I would be interested in hearing a bit about your use-case for these calls.

For nTickArr, I am am wondering if we might adjust the API parameter slightly so that it accepts an array of uint16_t instead of double? eg. the user could supply placements in units of 0.1% (ie. 0..1000). My only reason for suggesting this is that GUIslice is often used on small embedded devices where it makes sense to avoid pulling in floating point support whenever possible. ie.:

void gslc_ElemXSliderSetTicks(gslc_tsGui* pGui, gslc_tsElemRef* pElemRef, uint16_t* anTickArr,
     uint8_t nTickArrLen);

thanks!

[gravity-addiction]

I am am wondering if we might adjust the API parameter slightly so that it accepts an array of uint16_t instead of double?

Yep! Good catch on that. I'll update that commit.

The use case I have is a touchscreen arm sbc connected to hdmi for a desktop and sdl1 for user interaction with a 3.5 touchscreen. At times i'll map the hdmi video to the framebuffer and you then control the desktop mouse with the touchscreen. while guislice is very much actively executing click events and refreshing the framebuffer while the user interacts with the desktop.

[gravity-addiction]

i'm open to any insight on type casting this line, thanks!

int16_t xOffset = ((pElem->rElem.w - (nMargin * 2)) * nTickArr[i]) / 1000;

[ImpulseAdventure]

Hi @gravity-addiction -- sorry for the delay.

I have pushed a few adjustments to your branch that I think may simplify the implementation.

In particular, I have added a SetStyleCustom() API that enables one to:

• Provide a custom array of tick position percentages (0..100). I decided using partial percentages didn't seem worth it for the added confusion it may introduce.
• User can specify whether tick marks are drawn above and/or below the line. I noticed in your code that you had drawn above & below, so this seemed to address your intent.
• The code now reuses the existing rendering logic, so it should also support horizontal & vertical slider arrangements.
• If the custom positioning mode is enabled (by specifying anTickPos!=NULL), the length of the array is specified by the nTickDiv parameter in the existing SetStyle() API.
• The custom tick position array should be instantiated as static uint8_t anTickPos[xx]

Example of original API:

// Draw 10 tick divisions evenly along length of control, with height 5 below line (default)
gslc_ElemXSliderSetStyle(&m_gui,pElemRef,true,GSLC_COL_RED_DK4,10,5,GSLC_COL_GRAY_DK2);

Example using new feature:

// Draw 10 tick marks with a custom positioning, with height 5 above and below line
gslc_ElemXSliderSetStyle(&m_gui,pElemRef,true,GSLC_COL_RED_DK4,10,5,GSLC_COL_GRAY_DK2);
static uint8_t anTickPos[10] = {0,19,36,51,64,75,84,91,96,100};
gslc_ElemXSliderSetStyleCustom(&m_gui,pElemRef,anTickPos,true,true);

Let me know if the adjusted API works for you,
Cal

[gravity-addiction]

Hi @ImpulseAdventure .. no worries I get a little delayed myself.

I do like your implementation of the tick marks by percentage. However that won't work for my use case, my thumb slider is supposed to center align with the ticks. I now believe it is the wrong approach to use percentages. As the tick marks should be the same resolution as the thumb slider, pixels from the edge. Basically with the ability to put a tick mark on every pixel of the slider.

Let the developer translate percentage to pixels, maybe making a helper function in XSlider.c to help translate percentage to pixel value, internally grabbing the element size and doing the math.

What do you think of ditching percentage and using uint16 with values being pixels from the edge?

P.S. this is a reposting of this message, I was logged into the wrong account: strictd is my old company account.

[ImpulseAdventure]

Hi Gary -- you raise a good point with the use-case.

In that case, let me take a look at the API and post a followup.
thanks for the feedback!

[ImpulseAdventure]

Hey @gravity-addiction -- can you let me know if the latest version (pixel-oriented ticks array) that I pushed to your repo works for you?

thanks!