Jump to content

Could you please add this to the hextorgb output plugin?

Recommended Posts

Thanks. To anyone who needs this in the near-term, the hook is literally just what I posted. Code hook on IPS\System\Output\Plugin\Hextorgb.

The plugin itself seems to have changed recently-ish (4.2? Sooner) so the actual hook is on a function within now.

	static public function convertToRGB( $data, $opacity )
      // Patch to allow app and plugin settings to parse through
      	if ( isset( \IPS\Settings::i()->$data ) )
			$data = \IPS\Settings::i()->$data;
		return call_user_func_array( 'parent::convertToRGB', func_get_args() );

You're just front running on $data, getting the app/plugin setting before throwing it back into the function.

Link to comment
Share on other sites

Plugins (or apps) that have theme hooks. Hook to change color on element or whatever. That's what i'm using it for. 

Suppose I have a plugin that changes the background color on an div element that is above the page body which has a nice background image. If I want to just change the color of the element I can use the standard color form element, save it in the plugin settings, and toss out some css like so:

background: {setting="my_plugin_bg_color_setting"};

But, if I want this element to carry some transparency on it so some of that nice body background comes through, I need to add transparency. Note I cannot just do an straight up opacity css call on this element as that will make the div and all of the contents within that opacity. So this background color needs to go rgba. In the early 4x days if we wanted to do this and allow users to change stuff up we added a text field and told them to enter the rgba themselves (text form element) and then we would jack that in the css with essentially the same css as above. Problems being users entering it incorrectly, no color picker, etc. 

When you secretly added the hextorgb plugin we got halfway there to solving this. This output plugin still won't allow me to let users choose an opacity along with a color directly - that would make this thing perfect - but right now I can do the following:

Color picker to plugin/app setting

Select box with a couple opacity options (solid, 80%, 50% matching to 1, .8, and .5 respectively)

Then in the plugin/app css I do the following

{{if settings.boxtrans == 0}}

.thing {
background: {setting="boxtrans_bgcolor"} !important;


{{if settings.boxtrans == 1}}

.thing {
background: {hextorgb="boxtrans_bgcolor" opacity=".8"} !important;


{{if settings.boxtrans == 2}}

.thing {
background: {hextorgb="boxtrans_bgcolor" opacity=".5"} !important;


This allows the user to use the color picker, and still gives them some easy opacity options. Having them paste in the rgba directly is still better from a customization standpoint but we lose the color picker.

Of course, there is no reason not to include the same theme/plugin/app settings check on the opacity option on hextorgb. Right now we can't as there are no checks for theme or app/plugin settings on that variable in the method.

If you do add those checks I can use two settings then - one for color, the other for opacity amount (number form helper instead of the hard-coded opacity options like I give above) and then pass those settings respectively through hextorgb. Please strongly consider this - it would make life a ton easier for a lot of people.

I could hook in the same checks on opacity myself and "complete" this hextorgb plugin but I really don't want to come to rely on it in the long term. I would have to include it as a separate plugin from whatever app/plugin I'm working on to cut down on just my own instances of this hook and that doesn't take into account anyone else who starts copying this technique.

I'm sure having 10 to 20 hooks on convertToRGB all doing the same thing would work fine. Hilarious, but would work. Maybe not the best practice though...

Thanks for giving this a look - a couple of lines and a ton more functionality (until the day you refactor the colorpicker to include opacity - yes, I know the history of why you have what you have right now - I can still dream though :) ).

EDIT: If I really wanted to get around this I suppose I could skip using hextorgb in css and instead plaster it on as a style call on elements directly in phtml templates. In that case I could grab the settings and stick them in as {$var} elements and that would probably parse fine. 

{{$color = IPS\Settings::i()->bgcolor;}}
{{$opacityamount = IPS\Settings::i()->opacity_number;}}
<div class="whatever" style='background:{hextorgb="{$color}" opacity="{$opacityamount}"};'>

But I'm not sure those nested vars would parse. Maybe?.

Link to comment
Share on other sites

  • 2 weeks later...

Just a bump to those still following this. One of the recent 4.2 alphas has done this. You can now pass through a plugin/app setting for the color component instead of just a theme setting.

Opacity still must be a hard-coded value.

It really is a nothing burger to allow theme/app/plugin settings to be parsed on opacity as well. I *strongly* encourage you to consider including this before 4.2 goes final.

As is, I've already written a derpy plugin to account for these guys on opacity and will be releasing to the Marketplace said plugin with the release of 4.2 and will be including it with my apps/plugins by default.

I'd rather have a single hook tackling this than everyone else writing the same and traffic-jamming hextorgb with the same calls over and over again. Unless, of course, you include this stuff in hextorgb by default...

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...