1748 replies to this topic

[littlesat]

When you want this... why not directlu mod the default spinner...?????

[SpaceRat]

Well, as it actually has a fallback to the default spinner, I don't think the idea is too bad.

Replacing the spinner after a reflash always involves uninstalling the pre-installed one and putting new ones ...
User defined spinners in /etc/enigma2 would simply restore when restoring settings ...

[Taapat]

When you want this... why not directlu mod the default spinner...?????

 

Correct me if I'm wrong, but the spinner is included in enigma package.
If it is changed in /usr/share/enigma2/skin_default/spinner, then after every enigma update it replaces with the original from enigma package.

This patch allows own spinner placed in /etc/enigma2/spinner. It will keep when creating backup, and nothing will be changed after enigma update.

Edited by Taapat, 6 June 2015 - 22:43.

[Erik Slagter]

Did you post a patch?

[Taapat]

Take a look at the previous page: http://forums.openpl...-43#entry493721
And just I imagine. Spinner is a design element like skin, perhaps he right place is in /usr/share/enigma2/spinner instead of /etc/enigma2/spinner. But then it automatically will not be included in the backup copy.

[littlesat]

If we change this the best solution is to replace it permanently to /usr/share/enigma2/spinner.... We do not need a 'fallback' or so... but than our oe needs also some changes...

[Taapat]

I do not agree that there is no need a 'fallback'.
I think that the sinner must work just like skin. If the user uses his own, then the enigma use it, if not, then from skin_default.

[Taapat]

And I can not imagine how you create dependencies in packages, to enigma always use the spinner.

If enigma will depend on spinner package, then it will not be able to change without conflict.
If the 'fallback' spinner remains as it is now- in skin_default, then user can independently use theirs, and you can change your when you want, without disturbing the user.

[littlesat]

The fallback is not required at all when you move the complete spinner to that specific location.... 

Note the skinner is already required far before the skin is required and parsed... even before the settings are loaded...  So you can not compare it 'simply' as it should work as a skin.

I saw e.g. in ViX they made an ugly patch so you can add it to your skin... the big disadvantage of this patch is that they parse the /etc/enigma/setting file twice...

In general you already can change the spinner as it is now. There were also aleady plugins existing that replace the spinner png's.... 

I can follow you to put it on a more logic location... But not with differet fall backs etc.. As basically it does not have any added value at all.

[Taapat]

I think that if you do not want to add an alternative location for user spinner, it is better not to change anything.
For default spinner skin_default it is the right place, and changing something can break plugins and hacks for spinner.

[littlesat]

You get it!!!

[Taapat]

I'm sorry, but I'll get alternative location for user spinner, or I'll get that nothing has changed?
I ask because I see that in git no changes, but I understood that I have satisfied you about the alternative location.

[ims]

alternative location was made there long time ago, but was not accepted... problem is, that in time, when is loaded spinner's png, then does not exist skins.

Edited by ims, 8 June 2015 - 10:12.

[Taapat]

About spinner responsible enigma.cpp and therefore I propose modifications in this file.

For skin responsible skin.py, and I do not see any problem here.

The fact, that I think that the spinner should work just like skin, does not mean that it should be used the same methods.
But seems to me that on these issues, I've written here too much, so I must stop with this.

[ims]

@Taapat: for example (see date) http://forums.openpl...inner-as-globe/

Edited by ims, 8 June 2015 - 15:06.

[Dimitrij]

@Taapat: for example (see date) http://forums.openpl...inner-as-globe/

excellent spinners

Let's really make a custom version of the location of the spinners.

[Taapat]

@Taapat: for example (see date) http://forums.openpl...inner-as-globe/

Oh now I understand why the skin is mentioned.
I agree that the spinner can be related to the skin, but why no one worried that picons (except picon_default) is not related to the skin?
Maybe spinner like picons, can be installed as an independent package and not associate it with the skin?
But I really think that this discussion should stop, allowing openpli team decide whether to make the following changes or not.
I myself use the default spinner, and propose the changes just because I again was reading the user question- why after the update missing his previous spinner.

[peteru]

Another way to do this, is to have the default spinner packaged with enigma2 and use it as is during early startup. i.e no  change to the existing method. Later on during the startup, after the user configuration is parsed, the spinner can be replaced with a user selected alternative. It would be nice to package this and a UI for selecting a spinner into a plugin.

 

The way to replace a spinner is to call:

virtual void setSpinner(eRect pos, ePtr<gPixmap> *pic, int len);

This method would change the spinner (and possibly the location where it is displayed) at some stage during the boot process. I don't see that as much of a problem.

 

Another alternative is to make the spinner an optional skin element, so a skin can supply the spinner. I'm not in favour of that, because then you couple the skin and the spinner unnecessarily.

[Persian Prince]

 

You could always choose to ignore my patches. You could instead google my nickname

and checkup on my opensource experience.

 

 

I just want to say I did

 

http://xdandroid.com...evelopment_Team

 

CaptNoord : Kernel Developer

 

Keep up the good work

Edited by Persian Prince, 13 June 2015 - 06:26.

[SpaceRat]

Merge request:

I'm not a big fan of whitespace fixes, but for xmltvimporter/EPGImport it is really necessary.
The code is almost unreadable unless one makes insane adjustments to the editor.
A mixture of spaces, tabs, "half tabs", trailing whitespaces and so on ...

 0001_xmltvimport-whitespace.patch   75.73KB   8 downloads

You might need to search and replace the path specs inside the diff/patch, as I made the patch against persian pro's OpenPLi-Github.
Sorry about that, but I would have preferred simply creating a pull request on Github ...