465 replies to this topic

[Huevos]

Main problem for me is that we have to submit code to develop branch but there is not a develop image available. So when the develop file differs from the RC file it is impossible to properly test it.

Edited by Huevos, 24 January 2018 - 19:02.

[littlesat]

I think submitters (=contributes) must have develop image access....

[WanWizard]

If you are not building yourself, that is the most logical alternative.

 

For larger developments, I would like to use separate development branches as well, so it is possible to have larger periodes of instability without impact on the main development train. Obviously, we need buildserver support for that, and the option for contributors to trigger a build for a specific branch and box, something we've been talking about, but I haven't gotten around to (only two hands and limited time).  

[littlesat]

Self building is not relevant here. You have to be able to check the outcome in the orriginal...

[WanWizard]

Self building is not relevant here. You have to be able to check the outcome in the orriginal...

 

Huh?

[Huevos]

Self building is not relevant here. You have to be able to check the outcome in the orriginal...

You are going off topic now. I just need an image so I can test python changes. If I was working on C++ code I would set up my own build for PLi. But just for testing Python changes that is over the top.

[IanSav]

Hi,

One of the things I'm thinking about is to start some sort of "developer programme" to which you can subscribe, which gives you access to a developers-only forum for technical discussions, development images and the issue trackers, which we can limit to people that actually know what they are doing. But no decision has been taken about this yet.

As an active Beyonwiz developer (Australian Enigma2 devices) and an OpenViX contributor I would live to be able to work with OpenPLi to integrate some of my enhancements.  (I developed the international time and date display system for OpenViX and Beyonwiz.  I am now working on enhancements and cleanups to Setup.py and soon Menu.py.)

I don't have a build environment I just use developer images and feed to install and text my code changes.

+1 for a development access program.

Regards,
Ian.

 

[littlesat]

Huh?... I think I just reached the point here... think about someone who reports an issue or suggest improvements or offer a merge is able to (let) check his thoughts, suggestions and contribution in a genuine develops image... not everyone who wants to contribute does really like or is able to build and feed for his own and with this way you also sure your contribution works 100% in genuine Pli (as own builds could unexpectically deviate)
I also think it might promote more international devs contributing here....

Edited by littlesat, 25 January 2018 - 07:59.

[WanWizard]

I understand that, but that wasn't my point.

 

If you home build an image from the develop branch, it is equal to a genuine image, apart from our artwork. We don't have any offline code in the image.

 

I didn't say (or meant) that we shouldn't make develop images available, on the contrary, the "test and dev programme" was my idea.

[Huevos]

@WanWizard, if you build your own image the first screen that you reach says "this is not a genuine image".

[Huevos]

Huh?... I think I just reached the point here... think about someone who reports an issue or suggest improvements or offer a merge is able to (let) check his thoughts, suggestions and contribution in a genuine develops image... not everyone who wants to contribute does really like or is able to build and feed for his own and with this way you also sure your contribution works 100% in genuine Pli (as own builds could unexpectically deviate)
I also think it might promote more international devs contributing here....

Yes, exactly. Previously all we needed to do was check our submissions in a standard PLi build. Now that is not possible because there maybe be differences.

[Rob van der Does]

Anyway: my looking for button-related issues in PLi has stopped. My previously reported issues where solely found by reading the code, but now a live-image is required (at least for me).

[WanWizard]

@WanWizard, if you build your own image the first screen that you reach says "this is not a genuine image".

 

Yes. Meaning: it is an image WE haven't build, and therefore WE don't support. Code wise the image is identical, like I said, apart from the artwork.

[Persian Prince]

Solo4K (with updates, feeds and plugins?). Or OS Mega.

vusolo4k is ready (develop branch): http://www.mediafire...usolo4k_usb.zip

No feed sorry ...

[Huevos]

@Littlesat,

 

Continued from Github...

 

Please look at this suggestion.

 

https://github.com/A...d8de779893b0144

https://github.com/H....py#L1057-L1062

https://github.com/H...in.py#L306-L309

 

For the common good I suggest we share this (tested) solution for the reasons mentioned on Github.

 

I have closed the pull request.

[Huevos]

Or we can change this so the first parameter of objectTypes is the key to test.

[Huevos]

Or we can change this so the first parameter of objectTypes is the key to test.

That would look something like this:

	def process_screen(widget, context):
		for w in widget.getchildren():
			conditional = w.attrib.get('conditional')
			if conditional and not [i for i in conditional.split(",") if i in screen.keys()]:
				continue
			objecttypes = w.attrib.get('objectTypes')
			if objecttypes and len(objecttypes.split(",")) > 1:
				key = objecttypes.split(",")[0]
				if key and key in screen and not [i for i in objecttypes.split(",")[1:] if i == screen[key].__class__.__name__]:
					continue
			p = processors.get(w.tag, process_none)
			try:
				p(w, context)
			except SkinError, e:
				print "[Skin] Skin error in screen '%s' widget '%s':" % (name, w.tag), e

[Huevos]

That would mean the first argument of objectTypes is the object to check, and the subsequent arguments are the object types to test against.

[littlesat]

I recommend to make the code a bit more simple by just splitting it once...?

Edited by littlesat, 27 January 2018 - 16:14.

[Huevos]

I recommend to make the code a bit more simple by just splitting it once...?

I don't think it simplifies it. Look...

	def process_screen(widget, context):
		for w in widget.getchildren():
			conditional = w.attrib.get('conditional')
			if conditional and not [i for i in conditional.split(",") if i in screen.keys()]:
				continue
			objecttypes = w.attrib.get('objectTypes')
			objecttypes_split = objecttypes and len(objecttypes.split(",")) > 1 and objecttypes.split(",")
			if objecttypes_split:
				key = objecttypes_split(",")[0]
				if key and key in screen and not [i for i in objecttypes_split[1:] if i == screen[key].__class__.__name__]:
					continue
			p = processors.get(w.tag, process_none)
			try:
				p(w, context)
			except SkinError, e:
				print "[Skin] Skin error in screen '%s' widget '%s':" % (name, w.tag), e