| Monday, December 27th, 2010, 04:42 UTC | ||
| [04:42:28] | rooaus (rooaus!~cameron@ppp59-167-126-229.static.internode.on.net) has quit (Remote host closed the connection) | |
| [04:45:37] | rooaus (rooaus!~cameron@ppp59-167-126-229.static.internode.on.net) has joined #mythtv-theming | |
| [11:49:48] | paul-h_ (paul-h_!~Paul@5ad84320.bb.sky.com) has joined #mythtv-theming | |
| [11:50:42] | paul-h (paul-h!~paulh@5ad84320.bb.sky.com) has quit (Remote host closed the connection) | |
| [11:50:50] | paul-h_ is now known as paul-h | |
| [11:59:24] | paul-h: | stuartm: http://mythtv.pastebin.com/PNM3C8JE – Makes the <group> widget usable by fixing MythUIType::GetChild() to re-curse through any groups looking for a widget. |
| [11:59:43] | paul-h: | Also fixes MythScreenType::SetTextFromMap() and ResetMap() to work properly with groups |
| [12:01:00] | paul-h: | I thought I might have to fix MythUIType::SetVisible() to work properly as well but that seems to already work as intended |
| [12:17:29] | stuartm: | it should probably only re-curse for group widgets otherwise it's going to cause some unintended behaviour on screens with buttonlists/statetypes etc |
| [12:19:28] | paul-h: | it does only re-curse into MythUIGroup's, |
| [12:19:29] | stuartm: | I think that will mean replacing qChildHelper() with a loop in GetChild() and overriding GetChild() in MythUIGroup |
| [12:19:56] | stuartm: | paul-h: right, sorry, missed that bit |
| [12:21:45] | stuartm: | yeah, completely overlooked the qChildHelper() modification |
| [12:22:09] | stuartm: | and I forgot that we imported that function from the QT libs when moving from QT3 to QT4 |
| [12:34:09] | paul-h: | It works well with the patch to allow including another base.xml file. I create a group with the playback controls, add that group to another group with most of the other controls needed on most of the music screens then all I need to do is add that to each of the music windows like this <group name="infopanel" from="baseinfopanel"> <area>0,440,1250,260</area> </group> |
| [12:43:38] | stuartm: | the group stuff was what I had intended to allow from the start, but it fell through the cracks, feel free to commit that straight away |
| [12:46:38] | stuartm: | I haven't really had time to think about the 'include' patch yet, the only reason I want to give that some extra thought is that going forward I want the markup to remain stable, users should be able to use a 0.25 theme with 0.26 – new xml is fine but we should get it right from the start |
| [12:48:30] | stuartm: | part of me is wondering if we should allow widgets to be defined globally in the body of the normal -ui.xml files, there would still be room for the concept of 'includes' but it wouldn't be a requirement for sharing widget definitions between windows |
| [13:04:25] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 276 seconds) | |
| [13:22:29] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (*.net *.split) | |
| [13:22:30] | anykey_ (anykey_!~guedel@46-126-244-251.dclient.hispeed.ch) has quit (*.net *.split) | |
| [13:22:30] | mag0o (mag0o!20001@slackhost.lynchmv.com) has quit (*.net *.split) | |
| [13:27:14] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv-theming | |
| [13:27:14] | anykey_ (anykey_!~guedel@46-126-244-251.dclient.hispeed.ch) has joined #mythtv-theming | |
| [13:27:14] | mag0o (mag0o!20001@slackhost.lynchmv.com) has joined #mythtv-theming | |
| [13:56:53] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv-theming | |
| [14:14:16] | anykey_ (anykey_!~guedel@46-126-244-251.dclient.hispeed.ch) has quit (Read error: Operation timed out) | |
| [14:29:54] | anykey_ (anykey_!~guedel@46-126-244-251.dclient.hispeed.ch) has joined #mythtv-theming | |
| [15:16:30] | abqjp (abqjp!~abqjp@174-28-182-216.albq.qwest.net) has quit (Quit: abqjp) | |
| [17:16:54] | iamlindoro: | I must admit to some confusion about groups-- I haven't ever been able to understand when it's appropriate to use one, in the absence of scroll bars |
| [17:17:19] | iamlindoro: | ie, if you could group items and they had scrollbars, then they'd be a powerful tool to convert setup to mythUI |
| [17:17:27] | iamlindoro: | but in the absence of that, I'm ot sure when one should be used |
| [17:17:29] | iamlindoro: | er not |
| [17:19:54] | iamlindoro: | stuartm: paul-h: ^^ If you could explain how/when one should be used when you have a moment, would be much appreciated |
| [17:20:41] | stuartm: | iamlindoro: the idea behind groups was to allow attributes to be applied to a collection of items, e.g. you're laying out a form and need to adjust positioning of every spinbox and it's label, use a <group> and you can then adjust one set of coordinates to move the whole lot |
| [17:21:27] | stuartm: | or with movement animation you can group images/text to move together |
| [17:21:34] | iamlindoro: | hmm, ok, I see. Thanks. |
| [17:21:42] | iamlindoro: | Ah, ok, I can see its use in the context of animation |
| [17:21:43] | stuartm: | statetypes are groups underneath |
| [17:21:59] | iamlindoro: | makes sense |
| [17:22:19] | iamlindoro: | Any thought to allow optional scrollbars to a group? |
| [17:22:26] | stuartm: | iamlindoro: or to set alpha etc for multiple items with three lines instead of multiple <alpha> tags |
| [17:22:51] | iamlindoro: | Would also save me/other themers a lot of heartache when new options are added to a windows that are already jammed full |
| [17:23:35] | stuartm: | iamlindoro: I'm not too sure how that would work with a remote, so far we've aimed to fit everything onto the screen and if that isn't possible to split it across multiple screens |
| [17:24:24] | iamlindoro: | hmm |
| [17:25:00] | iamlindoro: | Guess it's a matter of taste in the end-- I guess I personally would prefer to scroll one long list of semi-like settings than to have to navigate many screens |
| [17:25:02] | stuartm: | for the TV use-case I'd have to say I prefer a multiple page/screen approach to adding scrolling |
| [17:25:55] | iamlindoro: | I just think we have *soooooo* many settings pages that it would be nice to say "Go to Playback settings" instead of "go to playback settings, page three, then next next next next next next FINISH |
| [17:26:07] | stuartm: | if you get to the point where it's 'many' screens then IMHO something is wrong and you need to think again |
| [17:26:26] | iamlindoro: | or even worse, having many single screens accessible from the menu so menu option proliferation replaces menu page proliferation |
| [17:26:38] | iamlindoro: | We already have many screens, the question is how to fix it :) |
| [17:26:48] | stuartm: | iamlindoro: see the schedule editor? each 'screen' is accessible directly, it's not linear |
| [17:26:57] | iamlindoro: | ie, we're deadlocked not moving forward with MythUI settings, but not removing Qt ones |
| [17:27:15] | iamlindoro: | stuartm: Yeah, but functionally speaking that's still menu option proliferation |
| [17:27:46] | iamlindoro: | ie, you're still creating tons of screens, you've just flattened the tree a bit |
| [17:30:08] | stuartm: | well that's why I say that we've too many settings etc :) I don't want to start an argument two days after Christmas, today is still officially a holiday and I just want to watch TV and eat seasonal treats ;) |
| [17:30:26] | iamlindoro: | Nah, not arguing at all, I'm sure we agree with one another |
| [17:30:44] | iamlindoro: | And I know it hasn't been lost, but I've been doing my level best to rip out settings :) |
| [17:31:32] | stuartm: | yeah, several of us have and I know I appreciate that effort |
| [17:31:58] | iamlindoro: | And lucky you having a holiday, I'm at work :) |
| [17:33:03] | stuartm: | I still think that so far we've made the easy, uncontroversial decisions, next we need to make some sacrifices and cut out settings that we might miss – for a while anyway |
| [17:35:23] | iamlindoro: | poor sphery has taken some heat :) |
| [17:35:39] | iamlindoro: | But yeah, going forward there's going to be some need to offend |
| [17:35:40] | stuartm: | as a poorly considered example, the mythvideo filter screen is crazy, the only thing you can't filter by is the eye colour of the leading actors first born child :) |
| [17:35:46] | iamlindoro: | haha |
| [17:36:00] | iamlindoro: | At least it's MythUI'd ;) |
| [17:36:31] | iamlindoro: | I personally am hoping to remove the last of the Qt settings screens this go-round, and if I can get those done, I'll go on removing the unusable stuff in MV |
| [17:36:40] | iamlindoro: | last of the MythVideo Qt settings screens, that is |
| [17:36:58] | iamlindoro: | I am still torn as to whether to dump videodlg.cpp entirely, though |
| [17:37:07] | iamlindoro: | well, not torn, just overwhelmed with how much work it will be |
| [17:41:55] | iamlindoro: | Since I want to allow what XBMC does, namely for one to be able to create as many libraries as one wishes, divided however one wishes, and for them all to be theoretically themed individually too |
| [17:42:54] | iamlindoro: | So we could have TV Shows and Movies as default libraries, and have most themes theme that, but allow one to create a "Kids" library and theme it, or an Adult library and theme that if they were so inclined, etc. |
| [17:46:04] | iamlindoro: | My biggest frustration with MythVideo right now is that how you might theme for TV Shows is not necessarily appropriate for Movies, and vice versa-- moreover, How you view your list of shows versus the seasons of that show versus the episodes of that show might not necessarily be the same.... just not quite sure the best way within MythUI to fix that |
| [17:47:38] | iamlindoro: | Guess the answer might be extremely liberal use of statetypes, such that the buttonlist could exist within the statetype itself... not that I've experimented to see if that's even possible |
| [17:49:39] | stuartm: | iamlindoro: it might simply be desirable to either force or allow a different view to be used depending on whether you are browsing television or films |
| [17:50:16] | stuartm: | personally I'd not try to make the distinction within a single screen |
| [17:50:41] | stuartm: | that would make theming far too complex |
| [17:51:22] | stuartm: | e.g. I might use the tree/list view for TV series and the gallery view for films |
| [17:51:43] | iamlindoro: | It needn't *be* that complex, but it would be nice to have the option |
| [17:51:57] | iamlindoro: | Since personally I'd lay out the episode view and Season view differently |
| [17:52:59] | iamlindoro: | ie, I might just put four or five seasons on the screen to allow use of large graphics, and force coverart view... and in the context of episodes, force screenshot, and use the space to fit more episodes, and subtitles, and season/episode values, etc. |
| [17:53:01] | stuartm: | you might even ask whether we need 4 different layouts, how are people using those views? They are probably picking one and sticking with it in most cases and they pick one which best suites their video collection makeup |
| [17:54:25] | iamlindoro: | One of the most unsightly parts of MythVideo/theming MythVideo is trying to do the calculus of what will be visible under which conditions, and putting info like, say, subtitle in where it will never be visible under movie and folder conditions, leading to big ugly blanks spaces |
| [17:54:29] | stuartm: | iamlindoro: well this is what I'm saying, drop the existing four-view setup, instead settle on fixed views (layed out differently between themes to suite all tastes) then you can have a 'film' view, a 'season' view and an 'episode' view |
| [17:54:57] | iamlindoro: | hmm |
| [17:55:04] | iamlindoro: | I'll think about that, might achieve the effect |
| [17:55:15] | iamlindoro: | I also have often felt that all the views were redundant |
| [17:55:23] | iamlindoro: | but speaking of changes that would piss people the hell off :) |
| [17:55:29] | iamlindoro: | I WANT MY LIST VIEW! |
| [17:55:31] | iamlindoro: | ;) |
| [17:55:35] | iamlindoro: | (/me hates list view) |
| [17:56:27] | stuartm: | that would also save themers a lot of work, the existance of 4 different views has always been redundant as no-one will use them all, it seems like they existed to begin with because the old UI themes weren't flexible enough to all them all in the XML alone |
| [17:58:44] | iamlindoro: | Yeah, could always fall back to "film" view when no other option is available |
| [17:59:17] | iamlindoro: | so could make theming mythvideo as economical as simply writing a film view and leaving it at that |
| [18:00:26] | stuartm: | apologies for the unintelligible wording at the end there, 'flexible enough to allow them all' |
| [18:02:58] | stuartm: | e.g. before mythui you couldn't achieve all those different layouts without supporting code, the old UI code didn't allow a 'one per screen' list for browse mode or a grid-view instead of a vertical list |
| [18:03:45] | stuartm: | since porting to mythui mythvideo is a single screen not four, at least from the code POV |
| [18:08:22] | iamlindoro: | yeah |
| [18:18:43] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (*.net *.split) | |
| [18:18:43] | mag0o (mag0o!20001@slackhost.lynchmv.com) has quit (*.net *.split) | |
| [18:19:36] | stuartm: | IMHO it says a lot that no-one is bemoaning the lack of 4 different possible layouts for recordings, between the existing themes there is already plenty of variety and probably enough to satisfy most tastes |
| [18:21:17] | iamlindoro: | I take your point, however, when I use that same logic about external players, it tends to fall on deaf ears |
| [18:21:48] | iamlindoro: | ie, "You can't use an external player in mythmusic, you can't use an external player for recordings, and soon, you won't be able to use an external player in MythVideo-- and that's consistent with how myth works" |
| [18:21:52] | iamlindoro: | Nobody seems to get that one |
| [18:22:20] | iamlindoro: | I think people are just change averse, and any time we ask them to change their muscle memory, or the way they have baselessly "always done it," they're going to freak out |
| [18:22:35] | stuartm: | iamlindoro: I could be wrong but that's because they still assume that they need an external player for some reason ... |
| [18:22:51] | iamlindoro: | I'm sure that in most cases, that's true |
| [18:23:14] | iamlindoro: | Nobody has caught on to the fact that I don't allow an external player for Bluray yet :) |
| [18:23:37] | iamlindoro: | or rather, nobody has yet caught on (as opposed to the other, which implies that I ever will) |
| [18:23:40] | stuartm: | I don't think what we're (I'm) proposing goes against the trend, Ubuntu and Apple being far more radical in dictating to their users and it actually seems to be working really well for them |
| [18:24:42] | iamlindoro: | Yeah, I really think the only one that will get a lot of complain is the removal of list/tree view |
| [18:25:44] | stuartm: | all we're doing is taking away options that users never needed to begin with, on the surface all they see is less choice but ultimately they'll appreciate the more user-friendly experience |
| [18:27:29] | stuartm: | the list/tree view will remain an option to themers and that's all we have to say, they won't understand but they'll quiet down as soon as a theme using that layout becomes available :) |
| [18:28:04] | iamlindoro: | Well, I guess I had thought to require that the widget be a MythUIButtonList |
| [18:28:31] | iamlindoro: | versus all the if (DLG_TREE)... else ... stuff |
| [18:31:34] | stuartm: | iamlindoro: just make both the buttonlist and buttontree optional, I assume you're going to keep the MythGenericTree container so it's just a couple of extra LOC to allow for both |
| [18:32:03] | stuartm: | it's actually easier to maintain support for buttontree than it is to maintain the buttonlist |
| [18:32:22] | iamlindoro: | yeah, need to take some time to actually think through all the implications of these changes... you have likely noticed that MythVideo code tends towards the needlessly complicated :) |
| [18:32:30] | iamlindoro: | well yeah |
| [18:33:19] | stuartm: | iamlindoro: it's a nightmare that code, you should have seen it just after I re-wrote it for mythui, I cleaned the whole thing up so that it was actually readable but then Anduin got hold of it again :( |
| [18:34:02] | iamlindoro: | I was thinking a few weeks ago of just rewriting from scratch |
| [18:34:04] | iamlindoro: | which I may yet |
| [18:34:33] | iamlindoro: | use the libmythmetadata elemtents, but just write the UI portions, which I think I'm competent to do at this point, especially when the aim is to make it as simple as possible |
| [18:35:26] | iamlindoro: | I feel like if I try to take what I've got and rework the UI, it might just end up more of a mess-- versus rewriting from scratch I have a chance of creating something clean (if maybe not as efficient as Anduin might be able to write) |
| [18:36:22] | stuartm: | at this point I really do want to slim down the whole frontend, not taking away useful functionality but just making the whole thing more cohesive instead of a sprawling mess |
| [18:37:21] | stuartm: | of course what I want to do and what I have time to do are completely different |
| [18:43:20] | iamlindoro: | Wonder if I could come up with a way to do filtering in a new UI |
| [18:43:27] | iamlindoro: | a clean/sensible way, that is |
| [18:44:43] | stuartm: | I wonder if you can apply some of the ideas from the mythmusic smart playlist/search feature, I wouldn't hold it up as an example of perfect UI design but it is extremely powerful and I use it all the time |
| [18:45:36] | iamlindoro: | I'd love for playlists to be consistent, but it would be nice if playlist editing was a base window |
| [18:46:19] | iamlindoro: | ie, invoking a playlist editor for mythmusic, mythvideo, and recordings was all the same UI |
| [18:47:15] | iamlindoro: | might be a pipe dream since I guess a Music playlist editor might need different features from a Video one |
| [18:47:58] | iamlindoro: | But you're right, I should probably think about playlists from the very beginning in a UI rewrite |
| [18:48:35] | stuartm: | the smart (dynamic) playlist stuff in mythmusic is great, it would be better still if it auto-updated the playlist based on the chosen criteria but that's easy enough to add later |
| [18:50:03] | stuartm: | I have smart playlists for 'Great, but not recently heard', 'Brand New or Unplayed', 'Brilliant 90s' etc |
| [18:51:27] | mag0o (mag0o!20001@slackhost.lynchmv.com) has joined #mythtv-theming | |
| [18:52:27] | stuartm: | first pulls together 'rating >= 7 AND last played > 90 days', second 'import date < 30 days OR playcount == 0', third 'decade/year ~199* AND rating > 7' |
| [18:53:09] | stuartm: | and it's not arduous to create a new smart playlist, it can do done in a minute with a remote |
| [18:53:21] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv-theming | |
| [19:09:16] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (*.net *.split) | |
| [19:30:50] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv-theming | |
| [19:32:12] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has quit (*.net *.split) | |
| [19:36:34] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-57-109.hr.hr.cox.net) has joined #mythtv-theming | |
| [19:36:34] | Captain_Murdoch (Captain_Murdoch!~cpinkham@ip72-218-57-109.hr.hr.cox.net) has quit (Changing host) | |
| [19:36:35] | Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv-theming | |
| [22:37:12] | anykey_ (anykey_!~guedel@46-126-244-251.dclient.hispeed.ch) has quit (Ping timeout: 255 seconds) | |
| [23:03:22] | paul-h (paul-h!~Paul@5ad84320.bb.sky.com) has quit (Remote host closed the connection) | |
| [23:03:44] | paul-h (paul-h!~paulh@5ad84320.bb.sky.com) has joined #mythtv-theming | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.