Jump to content


Photo

Proposal for extension


  • Please log in to reply
25 replies to this topic

#1 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 16 February 2023 - 07:33

Hello,

 

I write here with an idea for extension so to be discussed and eventually approved. If it goes approved i will make a PR in the repo.

 

The idea is extending the skinning engine to supports attaching renderer to any screen gui component (not only to Sources).

I propose this because currently when you use renderer you have to connect it to specific source and there is no chance to have linked/connected visual components without it.

Implementation of Source however have some requirements that in my opinion limits users when they want completely custom functionality.

 

All this is in connection to my skin and my wish to attach a custom page to listbox instead of scroller, but it can be used for any other functionality that somebody can wish.

Attached File  pagerexample.jpg   124.08KB   8 downloads

 

So this to work the Skin.py have to be slightly extended with new widget parameter (i name it "connection")

wname = widget.attrib.get("name")
		wsource = widget.attrib.get("source")
		wconnection = widget.attrib.get("connection")
		source = None
		if wname is None and wsource is None and wconnection is None:
			raise SkinError("The widget has no name, no source and no connection")
			return
		if wname:
			# print("[Skin] DEBUG: Widget name='%s'." % wname)
			usedComponents.add(wname)
			try:  # Get corresponding "gui" object.
				attributes = screen[wname].skinAttributes = []
			except Exception:
				raise SkinError("Component with name '%s' was not found in skin of screen '%s'" % (wname, name))
			# assert screen[wname] is not Source
			collectAttributes(attributes, widget, context, skinPath, ignore=("name",))
		elif wsource or wconnection:
			if wsource:
				# print("[Skin] DEBUG: Widget source='%s'." % wsource)
				while True:  # Get corresponding source until we found a non-obsolete source.
					# Parse our current "wsource", which might specify a "related screen" before the dot,
					# for example to reference a parent, global or session-global screen.
					scr = screen
					path = wsource.split(".")  # Resolve all path components.
					while len(path) > 1:
						scr = screen.getRelatedScreen(path[0])
						if scr is None:
							# print("[Skin] DEBUG: wsource='%s', name='%s'." % (wsource, name))
							raise SkinError("Specified related screen '%s' was not found in screen '%s'" % (wsource, name))
						path = path[1:]
					source = scr.get(path[0])  # Resolve the source.
					if isinstance(source, ObsoleteSource):
						# If we found an "obsolete source", issue warning, and resolve the real source.
						print("[Skin] WARNING: SKIN '%s' USES OBSOLETE SOURCE '%s', USE '%s' INSTEAD!" % (name, wsource, source.newSource))
						print("[Skin] OBSOLETE SOURCE WILL BE REMOVED %s, PLEASE UPDATE!" % source.removalDate)
						if source.description:
							print("[Skin] Source description: '%s'." % source.description)
						wsource = source.new_source
					else:
						break  # Otherwise, use the source.
				if source is None:
					raise SkinError("The source '%s' was not found in screen '%s'" % (wsource, name))
			wrender = widget.attrib.get("render")
			if not wrender:
				if wsource:
					raise SkinError("For source '%s' a renderer must be defined with a 'render=' attribute" % wsource)
				elif wconnection:
					raise SkinError("For connection '%s' a renderer must be defined with a 'render=' attribute" % wconnection)
			for converter in widget.findall("convert"):
				ctype = converter.get("type")
				assert ctype, "[Skin] The 'convert' tag needs a 'type' attribute!"
				# print("[Skin] DEBUG: Converter='%s'." % ctype)
				try:
					parms = converter.text.strip()
				except Exception:
					parms = ""
				# print("[Skin] DEBUG: Params='%s'." % parms)
				try:
					converterClass = my_import(".".join(("Components", "Converter", ctype))).__dict__.get(ctype)
				except ImportError:
					raise SkinError("Converter '%s' not found" % ctype)
				c = None
				for i in source.downstream_elements:
					if isinstance(i, converterClass) and i.converter_arguments == parms:
						c = i
				if c is None:
					c = converterClass(parms)
					c.connect(source)
				source = c
			try:
				rendererClass = my_import(".".join(("Components", "Renderer", wrender))).__dict__.get(wrender)
			except ImportError:
				raise SkinError("Renderer '%s' not found" % wrender)
			renderer = rendererClass()  # Instantiate renderer.
			if source:
				renderer.connect(source)  # Connect to source.

In that way you can connect 2 visual elements by name. "connection" parameter takes a name of element to connect to. For example in the skin:

<screen name="OSD3DSetupScreen" position="fill" title="Select Location" flags="wfNoBorder" backgroundColor="transparent">
    <panel name="Screen_Menu1" />
    <widget name="config" position="396,210" size="1130,635" itemHeight="45" font="Regular;28" scrollbarMode="showNever" selectionPixmap="selections/sel_1130x45.png" />
    <widget render="Pager" connection="config" position="396,849" size="1130,25" transparent="1" backgroundColor="background" pagerForeground="white" pagerBackground="background" />
  </screen>

Ofcource there have to be custom renderer made. But that renderer can be completely custom with only requirement to handle "connection" attribute. For example:

def applySkin(self, desktop, parent):
		attribs = [ ]
		for (attrib, value) in self.skinAttributes:
			if attrib == "pagerForeground":
				self.pagerForeground = parseColor(value).argb()
			elif attrib == "pagerBackground":
				self.pagerBackground = parseColor(value).argb()
			elif attrib == "picPage":
				pic = LoadPixmap(resolveFilename(SCOPE_GUISKIN, value))
				if pic:
					self.picDotPage = pic
			elif attrib == "picPageCurrent":
				pic = LoadPixmap(resolveFilename(SCOPE_GUISKIN, value))
				if pic:
					self.picDotCurPage = pic
			elif attrib == "connection":
				self.source = parent[value]
				parent.onShow.append(self.onShowed)
			else:
				attribs.append((attrib, value))
		self.skinAttributes = attribs
		return Renderer.applySkin(self, desktop, parent)

In my opinion this will be handy for skin creators that also write renderers. But tell me your thoughts about it.


Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #2 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 19 February 2023 - 07:01

Well since nobody from openpli is interested or express any opinion about it... I decided to iclude this with my skin as an extension. Unfortunately since i get no support from Openpli i decided that extension to be closed source.

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #3 neo

  • PLi® Contributor
  • 712 posts

+45
Good

Posted 19 February 2023 - 15:18

Bit impatient are you?

 

Not everyone is able to express an opinion (like me), not everyone is online every day.



Re: Proposal for extension #4 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 19 February 2023 - 15:49

Well sorry about that... Just i saw some people respond in other threads (dev oriented) but nobody gives any single comment about it.  ( i kind of expected some delay but 3 days is big time in my opinion and i post here since @littlesat told me to discuss changes here first...but nobody want to discuss)

So I thought 3 days waiting without single comment or opinion even if they respond to other dev threads is enough.

Well finally I have decided to prepare a PR with this change and you guys decide should it be merged.


Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #5 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 19 February 2023 - 17:41

Sorry Insee some code and a lot of text but I somehow do not understand what exactly you try to do, why, the need and eg a clear example. I tried to read it multiple times but sorry I need a bit more info to understand you thoughts. Yep

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Proposal for extension #6 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 19 February 2023 - 17:45

Do you mean that you can put renderer code in a plugin instead of putting extra renderer code in the image…. Sorry that I do not understand it.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Proposal for extension #7 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 19 February 2023 - 17:54

I see a picture that has instead of a scrollbar in the right on the bottom of the list a kind of ‘page dots’ like we usually current see on modern tablets etc…. This look nice but isn’t this not something that can be made optional… so instead of the old fashionned scrollbar you show these dots… ?

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Proposal for extension #8 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 19 February 2023 - 18:07

@littlesat No problem i will try to explain.

 

As you can see in the screenshot in the red square

 

Attached File  configwithcustomscrollbar1.jpg   144.6KB   5 downloads

 

I am trying to make that pager (yes, that 3 dots) control based on renderer. However currently when you define a renderer is required to supply a "source" parameter to the widget. So Renderers can not work without "source".

But that source have to be inherited from Components.Sources.Source. So in the screen code have to be defined such a element.

So in general if i want to connect a renderer to the ConfigListScreen "config" element i cant because the self["config"] is of type ConfigList which doesnt inherit from Components.Sources.Source.

So i am limited by this.

My idea is Renderes to be possible to be connected to every element in screen no matter what is  its type so to not be limited to only Components.Sources.Source.

 

Do you get my idea?

 

So in the skin to be possible to define this

<widget name="config" position="396,210" size="1130,635" itemHeight="45" font="Regular;28" scrollbarMode="showNever" valign="center" selectionPixmap="selections/sel_1130x45.png" />
    <widget render="Pager" connection="config" position="396,849" size="1130,25" transparent="1" backgroundColor="background" pagerForeground="white" pagerBackground="background" />

The widget with <widget render="Pager" is connected to the widget with name="config" and that is widget that doesn't inherit from Components.Sources.Source.

 

That gives freedom to skinners to write whatever renderer they wants without need the screen/widget to be explicitly designed that to be possible.

 

In this way i made that pager from the screenshot above connected with the config eListbox and rendering to be controlled by the selection and data in config eListbox.

 

P.S. Well its optional ofcource. If you dont define this in the skin you can use old fashioned scrollbars instead. It can be made when this is defined normal scrollbars to be disabled. You can freely define this in the renderer because you have complete access to the connected widget.


Edited by DimitarCC, 19 February 2023 - 18:14.

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #9 Dimitrij

  • PLi® Core member
  • 10,023 posts

+338
Excellent

Posted 20 February 2023 - 06:21

A very interesting idea.

For test, should I add this to the skin?


GigaBlue UHD Quad 4K /Lunix3-4K/Solo 4K


Re: Proposal for extension #10 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 20 February 2023 - 06:33

You can test it... But you need a corresponding renderer. There is PR open for this. You can take the modifications in skin.py and renderer.py
And if you are interested i can provide you with my custom renderer for that pager.

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #11 Dimitrij

  • PLi® Core member
  • 10,023 posts

+338
Excellent

Posted 20 February 2023 - 06:36

 

And if you are interested i can provide you with my custom renderer for that pager.

yes


GigaBlue UHD Quad 4K /Lunix3-4K/Solo 4K


Re: Proposal for extension #12 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 20 February 2023 - 06:50

I have sent you a personal message


Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #13 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 21 February 2023 - 14:58

@littesat @Dimitrij

 

Is there any news regarding this? I mean any statement is it going to be considered to be included in the image?

That is the only point stopping my skin development so far since if this is not included i have to provide/overwrite the default .py files by plugin which i wish not generally ;)


Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #14 Dimitrij

  • PLi® Core member
  • 10,023 posts

+338
Excellent

Posted 21 February 2023 - 20:20

DimitarCC

I checked.

This code works.

But in my opinion, then the  render Pager.py and icons should be added to the image.

 

P.S.I do not answer for adding the PR.


Edited by Dimitrij, 21 February 2023 - 20:21.

GigaBlue UHD Quad 4K /Lunix3-4K/Solo 4K


Re: Proposal for extension #15 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 21 February 2023 - 20:24

Thank you! Ok that is ok for me if it is added to the image. But also that extension open possibilities for other renderers to be written. For example synchronized list boxes, chart widgets that get data from another widget and so on ;)

Edited by DimitarCC, 21 February 2023 - 20:31.

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #16 Aliraza63

  • PLi® Tester
  • 250 posts

+23
Neutral

Posted 23 February 2023 - 16:08

These extensions will be the part of default skins only .  Right ?


 DM-900 ,DM-520, Vu+Duo2


Re: Proposal for extension #17 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 23 February 2023 - 18:20

Its is not approved anything. And also not intended to be in any skin by default. The idea is if somebody want to use it to put it in their skin.

But as i said devs didnt approve that.....(yet)


Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #18 littlesat

  • PLi® Core member
  • 56,274 posts

+691
Excellent

Posted 4 March 2023 - 07:42

Please put it in de standard skins…. For the configs (not channel list etc) finally a real good added value.

Edited by littlesat, 4 March 2023 - 07:42.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Proposal for extension #19 DimitarCC

  • PLi® Contributor
  • 1,333 posts

+46
Good

Posted 4 March 2023 - 07:52

I will provide the renderer, images and propose modifications for standard skins once i get better, because i am sick last few days and feel not well...
Thank you for accepting this.

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & Triax 78 (39E)


Re: Proposal for extension #20 Abu Baniaz

  • PLi® Contributor
  • 2,441 posts

+62
Good

Posted 5 March 2023 - 16:20

Get well soon.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users