[sphere]

argh, tried to split your post, but it only would create a new topic. All I could do is to increase the max post length to fix it

edit: just increased the max length for posts, so you should be able to edit it again.

Works, thanks!

[zag]

Some great suggestions here.

In terms of 7.1 Wiki Documentation we are looking for some people to write:

- An example video streaming plugin
- An example audio streaming add-on
- An example game plugin (tic-tac-toe or something like that)

There is already a hello world article here. http://wiki.xbmc.org/index.php?title=HOW...orld_addon

[leechguy]

Please allow me to add two of my personal frustrations

5.15 Allow filling in setting defaults using a callback function
For example the labelenum values in the settings.xml file are now hardcoded. It would be great if the possible values of the labelenum could be set during runtime using a callback function.

5.16 Service addons that start on XBMC startup should read settings from the Master User profile
When using multiple profiles and not using the login screen, the user that was logged in during the last session will login. As such, the service addon that starts at startup (start="startup" in addon.xml) will read its settings from that user profile. This means that a service addon which runs at startup must be configured the same for all user profiles or the behaviour of the service is unknown.
If such a service would always use the settings from the Master User profile the service addon would always use the correct settings.

5.16 I find especially annoying because it requires a lot of code to work arround this issue.

[pieh]

2.1 always included skin graphics
It would beautify and unify the look of most plugin add-ons if skins would include (and this should be a requirement) reusable graphics (with a defined naming scheme) like:
- "NextPage.png"
- "PreviousPage.png"
- "MoreItems.png"
- "Search.png"
- ...
Then add-on devs could trust on that such graphics exist on EVERY skin and could start using them for their pagination (and search).

I wouldn't force skins to include these graphics but rather make it suggestion. If skin wouldn't have such images we would fallback to graphics provided by plugin (we would need to add some mechanism to do it this way). This would be short term, long term I would like to add nice pagination handling in xbmc gui (maybe something like infinite scroll, so we stay in same list and items are being appended on demand) and same with search (so user could use global search that would search local library and addons that support searches and show results from different sources in same list)

2.2 View-IDs
In some cases a Plugin view looks better (or even only makes sense) if the skin is forced to use a thumbnail-view (the default view in most skins is "list view").
At the moment you can do - but you need to know the view-id for the wanted "style" (thumb/list/...) for the skin the user is using.
Example, if you want to force any kind of thumbnail-like view you need to have a look to EVERY skin manually to find a matching view (and recheck on every update of the skin!) and hardcode it in the add-on code. Here is an example for the a "thumbnail"-view for some major skins:

Code:

'thumbnail': {
        'skin.confluence': 500,
        'skin.aeon.nox': 551,
        'skin.confluence-vertical': 500,
        'skin.jx720': 52,
        'skin.pm3-hd': 53,
        'skin.rapier': 50,
        'skin.simplicity': 500,
        'skin.slik': 53,
        'skin.touched': 500,
        'skin.transparency': 53,
        'skin.xeebo': 55,
    },

One possible solution would be if skin authors would be able to (and pleased to do so *g*) define some "basic" view-IDs for plugin-usage by name in their addon.xml. And this defines should be accessable by plugins.
One simpler (at least I guess it is simpler...) solution would be to allow view-ids to be strings and add the convention that every skin needs to have some basic views defined.
Example:

PHP Code:

return xbmcplugin.endOfDirectory(success=True, default_view='thumbnail') 


We have <viewtype> that specify how given view look like (from wiki: "The type of view. Choices are list, icon, wide, wrap, biglist, bigicon, bigwide, bigwrap, info and biginfo."). I think this could be used by plugins to state what viewtype is prefered, "thumbnail" would be "icon" viewtype I guess.

2.3 Big Text Dialog/Window
It would be a good addition for add-on developers if every skin would include one additional xml defined dialog: A "Big Text Dialog" Something like a huge OK-Dialog. Add-ons could open that dialog modal to show a changelog or a small how-to-use-this-addon-text on their own - but with matching the look of the current in use skin.

I think we should try to make standard Ok-Dialog auto-sizable instead to avoid adding yet another dialog that need maintaining

2.4 Skin defined fonts and font sizes (thanks to bossanova808)
Some definition of standard fonts and font sizes - so that a WindowXML will at least somewhat across most skins without awful font overlaps etc. At the moment if you do a WindowXML of any complexity you basically need all the skinners to hop on board for it to be usable. If there were some standardised options:
- Very Large
- Large
- Normal
- Small
- Very Small
....always the same sized, then addons would instantly be at least usable on other skins...

Something like this is obviously needed, WindowXML has great potential but because of lack of some standards it usually looks awful on non-confluence skins. I think that we need more than just font sizes here - at very least we need to describe what font styles (font family + font size + font weight/italics + upper/lower case + color) are used for in skin - some dialog headings might use same font size as button labels but mixing it will still make WindowXML look not as nice as it could.

[sphere]

2.1 always included skin graphics

I wouldn't force skins to include these graphics but rather make it suggestion. If skin wouldn't have such images we would fallback to graphics provided by plugin (we would need to add some mechanism to do it this way). This would be short term, long term I would like to add nice pagination handling in xbmc gui (maybe something like infinite scroll, so we stay in same list and items are being appended on demand) and same with search (so user could use global search that would search local library and addons that support searches and show results from different sources in same list)

Regarding images:
I also don't thing that forcing is needed, but the skin authors need to be informed about such a convention. I bet every skin author is interested in having plugin's look more unified to his skin.

Regarding Pagination: Pagination mechanism included in the add-ons api would be great, but this is def. long term and needs most plugins/plugin frameworks changed.

2.2 View-IDs

We have <viewtype> that specify how given view look like (from wiki: "The type of view. Choices are list, icon, wide, wrap, biglist, bigicon, bigwide, bigwrap, info and biginfo."). I think this could be used by plugins to state what viewtype is prefered, "thumbnail" would be "icon" viewtype I guess.

Sounds good Then only a method (and any kind of priorizing cause some skins provide multiple views for one view-type) is needed to get these IDs readable by add-ons.

2.3 Big Text Dialog/Window

I think we should try to make standard Ok-Dialog auto-sizable instead to avoid adding yet another dialog that need maintaining

auto-sizing sounds good but the ok-dialog needs three lines in the api. So we have to choices: 1. change the ok-dialog in gui and code (to accept one multiline-text argument) or 2. keep the ok-dialog in code and gui but add another dynamic sized (with auto close please) dialog.

May I pin your name next to some topics? *g*

[hippojay]

Nice list - a lot of cross over with my own personal 'want' list.

[pieh]

2.1 always included skin graphics

I wouldn't force skins to include these graphics but rather make it suggestion. If skin wouldn't have such images we would fallback to graphics provided by plugin (we would need to add some mechanism to do it this way). This would be short term, long term I would like to add nice pagination handling in xbmc gui (maybe something like infinite scroll, so we stay in same list and items are being appended on demand) and same with search (so user could use global search that would search local library and addons that support searches and show results from different sources in same list)

Regarding images:
I also don't thing that forcing is needed, but the skin authors need to be informed about such a convention. I bet every skin author is interested in having plugin's look more unified to his skin.

Ok, this can be taken to Skin Development forum and presented to skinners to comment on. I'm not sure if we already can say "try in skin's graphics and fallback to graphics provided by plugin" - this might be possible with thumb / icon stuff (I'm always a little confused about that ). If not possible, I will see what's needed to do it.

2.2 View-IDs

We have <viewtype> that specify how given view look like (from wiki: "The type of view. Choices are list, icon, wide, wrap, biglist, bigicon, bigwide, bigwrap, info and biginfo."). I think this could be used by plugins to state what viewtype is prefered, "thumbnail" would be "icon" viewtype I guess.

Sounds good Then only a method (and any kind of priorizing cause some skins provide multiple views for one view-type) is needed to get these IDs readable by add-ons.

I'll look into it. I'm thinking xbmcplugin.xbmcplugin.endOfDirectory(success=True, view_priority=['bigicon', 'icon', 'info']) (not all skins might include most desired viewtype, so we could define fallbacks and if none of defined views are there we just fallback to default list view). There might be one glitch: if we change from default view to something else we save it in ViewModesX.db database - so plugins that used workaround to pick thumbnail view will have already defined view id for given path - this means that this would have no effect (as we will want to use view that user defined and not one that is defined by plugin). We could clean saved views for plugins but I don't like this as it would remove view preferences of users

2.3 Big Text Dialog/Window

I think we should try to make standard Ok-Dialog auto-sizable instead to avoid adding yet another dialog that need maintaining

auto-sizing sounds good but the ok-dialog needs three lines in the api. So we have to choices: 1. change the ok-dialog in gui and code (to accept one multiline-text argument) or 2. keep the ok-dialog in code and gui but add another dynamic sized (with auto close please) dialog.

I'm thinking that we could replace 3 labels with textbox control (skinning wise), leave current api methods to not break addons (we would just concatenate those 3 lines and put it in textbox) and add new api method that would take single text block. Autoclose could be added as optional named param to existing ok-dialog.

May I pin your name next to some topics? *g*

Sure, but I'd prefer seperate trac tickets

[jmarshall]

Regarding viewtypes, none of XBMC's filesystem layers require this, so I'd question whether it is the best method to apply for VFS add-ons.

ATM all switching is generally done by the skin based on content type. It might be better to make the content type more fine-grained would be a good way to deal with this (e.g. content type should probably be a set of content types that apply).

If we need a way to specify views specifically, then it could be done with something like video|art.wide|info or some such.

[sphere]

So jmarshall, you questioned whether it would be the best method. Any decisions already made?

Personally I don't mind the solution in detail, I only wrote down the imo easiest solution - I would be happy with both of that

[Nuka1195]

I have a patch for 5.4 background progress dialog.

[Martijn]

I have a patch for 5.4 background progress dialog.

Does it use an existing skin xml file because we don't want to add new ones.

[Nuka1195]

It adds the ability to call the same dialog the cd ripper and library scanner uses. It's a a very simple/small patch

---

While I have your attention why don't you open my pr's you closed on git. I also need those.

---

dialog.h diff

PHP Code:

diff --git "a/C:\\DOCUME~1\\NukaBolt\\LOCALS~1\\Temp\\TortoiseGit\\Dia44.tmp\\Dialog-8f3fecd-left.h" "b/D:\\Development\\source\\XBMC\\xbmc\\interfaces\\legacy\\Dialog.h"
index 66c6269..b54a3f0 100644
--- "a/C:\\DOCUME~1\\NukaBolt\\LOCALS~1\\Temp\\TortoiseGit\\Dia44.tmp\\Dialog-8f3fecd-left.h"
+++ "b/D:\\Development\\source\\XBMC\\xbmc\\interfaces\\legacy\\Dialog.h"
@@ -28,6 +28,7 @@
 #include "AddonString.h"
 #include "ApplicationMessenger.h"
 #include "dialogs/GUIDialogProgress.h"
+#include "dialogs/GUIDialogExtendedProgressBar.h"
 #include "Alternative.h"
 
 namespace XBMCAddon
@@ -285,5 +286,67 @@ namespace XBMCAddon
       bool iscanceled();
     };
 
+    /**
+     * DialogProgressBG class
+     */
+    class DialogProgressBG : public AddonClass
+    {
+      CGUIDialogExtendedProgressBar* dlg;
+      CGUIDialogProgressBarHandle* handle;
+
+    protected:
+      virtual void deallocating();
+
+    public:
+
+      DialogProgressBG() : AddonClass("DialogProgressBG"), dlg(NULL), handle(NULL) {}
+      virtual ~DialogProgressBG();
+
+
+      /**
+       * create(heading[, message]) -- Create and show a background progress dialog.\n
+       *\n
+       * heading : string or unicode - dialog heading\n
+       * message : [opt] string or unicode - message text\n
+       *\n
+       * *Note, Use update() to update heading, message and progressbar.\n
+       *\n
+       * example:\n
+       * - pDialog = xbmcgui.DialogProgressBG()\n
+       * - pDialog.create('Movie Trailers', 'Downloading Monsters Inc. ...')\n
+       */
+      void create(const String& heading, const String& message = emptyString) throw (WindowException);
+
+      /**
+       * update(percent[,heading, message]) -- Update's the background progress dialog.\n
+       *\n
+       * percent        : integer - percent complete. (0:100)\n
+       * heading        : [opt] string or unicode - dialog heading\n
+       * message        : [opt] string or unicode - message text\n
+       *\n
+       * *Note, To clear heading or message, you must pass a blank character.\n
+       *\n
+       * example:\n
+       * - pDialog.update(25, message='Downloading Finding Nemo ...')\n
+       */
+      void update(int percent, const String& heading = emptyString, const String& message = emptyString) throw (WindowException);
+
+      /**
+       * close() -- Close the background progress dialog\n
+       *\n
+       * example:\n
+       * - pDialog.close()\n
+       */
+      void close();
+
+      /**
+       * isFinished() -- Returns True if the background dialog is active.\n
+       *\n
+       * example:\n
+       * - if (pDialog.isFinished()): return\n
+       */
+      bool isFinished();
+    };
+
   }
 } 


dialog.cpp diff

PHP Code:

diff --git "a/C:\\DOCUME~1\\NukaBolt\\LOCALS~1\\Temp\\TortoiseGit\\Dia31.tmp\\Dialog-8f3fecd-left.cpp" "b/D:\\Development\\source\\XBMC\\xbmc\\interfaces\\legacy\\Dialog.cpp"
index af0941c..40c4563 100644
--- "a/C:\\DOCUME~1\\NukaBolt\\LOCALS~1\\Temp\\TortoiseGit\\Dia31.tmp\\Dialog-8f3fecd-left.cpp"
+++ "b/D:\\Development\\source\\XBMC\\xbmc\\interfaces\\legacy\\Dialog.cpp"
@@ -305,6 +305,66 @@ namespace XBMCAddon
     {
       return dlg->IsCanceled();
     }
+
+    DialogProgressBG::~DialogProgressBG() { TRACE; deallocating(); }
+
+    void DialogProgressBG::deallocating()
+    {
+      TRACE;
+
+      if (dlg)
+      {
+        DelayedCallGuard dg;
+        dlg->Close();
+      }
+    }
+
+    void DialogProgressBG::create(const String& heading, const String& message) throw (WindowException)
+    {
+      DelayedCallGuard dcguard(languageHook);
+      CGUIDialogExtendedProgressBar* pDialog = 
+          (CGUIDialogExtendedProgressBar*)g_windowManager.GetWindow(WINDOW_DIALOG_EXT_PROGRESS);
+      CGUIDialogProgressBarHandle* pHandle = pDialog->GetHandle(heading);
+
+      if (pDialog == NULL)
+        throw WindowException("Error: Window is NULL, this is not possible :-)");
+
+      dlg = pDialog;
+      handle = pHandle;
+
+      pHandle->SetPercentage(0);
+      pHandle->SetTitle(heading);
+      if (!message.empty())
+        pHandle->SetText(message);
+    }
+
+    void DialogProgressBG::update(int percent, const String& heading, const String& message) throw (WindowException)
+    {
+      DelayedCallGuard dcguard(languageHook);
+      CGUIDialogExtendedProgressBar* pDialog = dlg;
+      CGUIDialogProgressBarHandle* pHandle = handle;
+
+      if (pDialog == NULL)
+        throw WindowException("Error: Window is NULL, this is not possible :-)");
+
+      if (percent >= 0 && percent <= 100)
+        pHandle->SetPercentage((float)percent);
+      if (!heading.empty())
+        pHandle->SetTitle(heading);
+      if (!message.empty())
+        pHandle->SetText(message);
+    }
+
+    void DialogProgressBG::close()
+    {
+      DelayedCallGuard dcguard(languageHook);
+      handle->MarkFinished();
+    }
+
+    bool DialogProgressBG::isFinished()
+    {
+      return handle->IsFinished();
+    }
+
   }
 }
- 


---

shortly.

---

5.4 https://github.com/xbmc/xbmc/pull/2462

---

martijin, you have pm disabled, so:

https://github.com/xbmc/xbmc/pulls/nuka1...ate=closed

[sphere]

Nice - exactly what I meant in 5.4.

I see no GitHub PR for this, will you open one?

[Nuka1195]

<supportsearch> in addon.xml, or a parameter passed in xbmcplugin.endOfDirectory, then when selecting the search button, it would call your script with a search parameter provided, by the addon.

same with actor, when in video info dialog and press actor, it calls your addon with a search parameter,

i think there is a way for xbmc to tell if the current listing is from a plugin.

[sphere]

Since 5.4 got merged (https://github.com/xbmc/xbmc/pull/2484) (thanks Nukka) maybe we can delete the other 7 redundant replies now?