:: #mythtv-theming

Daily chat history

Current users (21):

abqjp, anykey__, Beirdo, brfransen, Captain_Murdoch, DjMadness, gbee, gbutters, gregl, jams, jpabq, jpabq-, laga, mag0o, mrand, MythLogBot, okolsi, paul-h, rooaus, sphery, wagnerrp
Monday, April 5th, 2010, 07:20 UTC
[07:20:56] natanojl (natanojl! has joined #mythtv-theming
[15:11:01] mag0o: in config-ui.xml, is it possible to have the buttonimage outside of the button, like on the bottom part of the page? I never can remember
[15:11:14] mag0o: (not really specific to config-ui.xml i don't guess)
[15:16:06] iamlindoro: Not really, within a buttonlist each button's elements have to exist (when done properly) within the button area
[15:16:34] iamlindoro: but most windows that use a buttonimage also provide for the selected item's preview/image/whatever to be used as a seperate imagetype
[15:16:57] iamlindoro: don't know what specifically you are working on
[15:21:03] mag0o: in config-ui.xml, channeloverview
[15:22:56] iamlindoro: Right, so that particular window doesn't have a "preview" or similar imagetype
[15:23:16] iamlindoro: though it would be exceedingly trivial to add, a great first project for aspiring MythUI contributors ;)
[15:23:39] mag0o: I see what you're doing there :)
[15:24:22] gbee: those are the sort of small additions, to add flexibility, which I expected to see far more of
[15:24:53] gbee: but I guess many people are just happy to work within the existing confines :/
[15:25:46] ** iamlindoro actually has the patch done if mag0o doesn't want to man up **
[15:26:06] iamlindoro: I understand if he's busy changing his dress or picking out his panties
[15:26:09] iamlindoro: I mean... ummm
[15:27:19] mag0o: i can see what i can do
[15:27:20] mag0o: :)
[15:27:56] mag0o: so, where can it be done, then i can compare that against where I am and see if I can add it
[15:30:15] iamlindoro: the code you want to change is programs/mythtv-setup/channeleditor.cpp/h
[15:30:39] iamlindoro: the code you can compare against is pretty much anywhere a buttonlist affects an outside imagetype, but look for a simple example
[15:31:06] iamlindoro: specifically, you can look at slotitemchanged in mythnetvision/nettree.cpp/h
[15:31:21] iamlindoro: I'll also post my patch in half a second if you want to see a finished product to compare against
[15:31:28] iamlindoro: well, finished but untested
[15:31:37] mag0o: ok
[15:32:09] mag0o: i was trying to figure out if i needed to be in libs/libmythui or programs/mythtv-setup
[15:32:13] mag0o: got that one answered :)
[15:34:27] abqjp (abqjp! has quit (Quit: abqjp)
[15:45:43] iamlindoro: mag0o:
[15:45:56] iamlindoro: Whether that's picture-perfect or not I can't know without being at a mythbox, but should be mostly right
[15:46:00] iamlindoro: imagetype is "preview"
[15:46:36] iamlindoro: Feel free to let me know if it works ;)
[15:48:42] gbee: iamlindoro: I'd dispute the need for the SetVisible() – an m_preview->Reset() would cause the image to disappear, but crucially if the themer specified a default, something to be shown if no image was available then it with SetVisible() it would never be seen
[15:49:02] iamlindoro: true
[15:51:09] iamlindoro: gbee: more to your liking?
[15:52:49] gbee: yeah thanks :)
[15:52:55] iamlindoro: np, thank you
[15:54:12] gbee: I give this sort of thing way too much thought ;)
[15:54:38] iamlindoro: mag0o: So anyway, you could expand on the above and also add MythUIText areas (patterning after the creation of m_preview) for each piece of information and enclose the updates in itemChanged() so that you could use those for the selected item outside the buttonlist, too
[15:55:01] mag0o: heh
[15:55:10] iamlindoro: Though I would probably write itemChanged slightly differently (or at least order it slightly differently) if we were handling more than one thing
[15:55:27] mag0o: so, i need to take that and see if i can understand what you're doing there
[15:55:36] mag0o: gimmie a day or two
[15:55:38] mag0o: :)
[15:56:32] iamlindoro: I'll add one more textarea to it, then you can look at the difference and it may make more sense
[15:57:13] mag0o: m_preview = dynamic_cast<MythUIImage *>(GetChild("preview")); that looks in the xml to find a MythUIImage type named preview, right?
[15:58:25] mag0o: (flying by the seat of my pants here, but I consider myself somewhat good at being able to figure out what's going on)
[15:58:32] mag0o: in most code types
[15:59:27] iamlindoro: correct
[16:00:49] mag0o: don't post code for the textarea
[16:00:56] mag0o: i'll be too tempted to look
[16:01:47] iamlindoro: Heh, it's already pastebinned ;)
[16:03:37] mag0o: i think i see how it works though, so I should be able to add the textarea myself
[16:06:49] iamlindoro: Just below "m_preview = dynamic_cast<MythUIImage *>(GetChild("preview"));" you'll see an evaluation of the required widgets, adding your widget to that would be how you would make it required
[16:07:33] iamlindoro: also, any time you use a *non* required widget, you need to remember to check that it exists, otherwise if the themer doesn't use the textarea and the code attempt to operate on it, you'll get segfaults
[16:07:43] gbee: mag0o: correct, GetChild() looks for the widget called preview, dynamic_cast<MythUIImage *> is harder to explain if you don't have a background in a 'typed' programming language, but for our purposes lets just say that it's checking that 'preview' is a MythUIImage and not say a MythUITextArea with the same name
[16:08:17] mag0o: ok, lunch and i'll be back in an hour or so
[16:08:37] iamlindoro: Even more confusingly, there are two ways of doing the XML assignment
[16:08:54] gbee: if it wasn't an imagetype, then m_previewImage would be NULL (empty) and the "if (m_previewImage)" checks would return false, e.g. nothing happens because the imagetype isn't in the theme
[16:28:10] abqjp (abqjp! has joined #mythtv-theming
[17:13:38] mag0o: iamlindoro: so since m_preview isn't required, the first thing the itemChanged (function?) does is check to see if there is no m_preview, so it doesn't segfault, right?
[17:14:18] mag0o: and if it was required, it would go in that big list of items to check for that are required
[17:14:19] iamlindoro: mag0o: Right, though I would do it slightly different for multiple widgets being changed in that function
[17:14:23] iamlindoro: yes
[17:15:07] mag0o: ok
[17:16:07] iamlindoro: Sure you don't want that last pastebin?
[17:16:30] mag0o: positive
[17:16:43] iamlindoro: Basically, remove the if (!m_preview) return; bit
[17:16:55] iamlindoro: and enclose the stuff working on m_preview in:
[17:17:04] iamlindoro: if (m_preview) { }
[17:17:58] iamlindoro: so if you add, say, a m_channame, enclose anything operating on m_channame in itemchanged with:
[17:18:04] iamlindoro: if (m_channame) { }
[17:18:07] iamlindoro: etc.
[17:18:15] mag0o: right, so they will be used if there, and if not, ignored
[17:18:22] mag0o: or continue rather
[17:18:24] iamlindoro: right
[17:18:37] mag0o: makes sense
[17:33:13] natanojl (natanojl! has left #mythtv-theming ("Quit")
[17:34:15] natanojl (natanojl! has quit (Quit: Quit)
[18:06:50] mag0o: here is what I've come up with:
[18:07:28] iamlindoro: Grab the buttonlistitem once, outside of the changes
[18:07:37] iamlindoro: and return if it doesn't exist
[18:07:45] iamlindoro: (ie, copy from my code above)
[18:07:51] mag0o: ah
[18:08:07] iamlindoro: Also don't need the SQL
[18:08:20] iamlindoro:
[18:09:01] iamlindoro: otherwise looks good
[18:10:10] iamlindoro: In my example, we pull the text out that was set on the buttonlistitem in ChannelEditor::fillList()
[18:10:36] iamlindoro: So that the query is just done once when building the buttonlist, and then never needed again
[18:12:03] mag0o: ah, so that object(?) holds the data we need?
[18:12:16] mag0o: the item object
[18:13:10] mag0o: was the sql stuff right, even though it wasn't needed?
[18:13:43] gbee: yes it was
[18:14:05] mag0o: i grabbed that from further down and just reused it
[18:14:15] mag0o: so i was definately on the right track, good to know :)
[18:14:18] gbee: the item points to the button object and the button does contain the information
[18:14:29] iamlindoro: ^ Beat me to it
[18:14:45] mag0o: ah
[18:15:05] iamlindoro: yes, you were on the right track
[18:15:17] iamlindoro: and not knowing the most efficient way to do it is most a matter of familiarity
[18:15:20] iamlindoro: er more a
[18:15:45] mag0o: yeah
[18:16:16] mag0o: i could read the sql stuff and see what it did, so i went with it. now that i know that item holds the info for the current button there, i can play with that
[18:17:12] gbee: m_channelList->GetItemCurrent(); – gives the currently selected button in the list
[18:17:38] gbee: channelID = item->GetData().toInt(); << Buttonlist buttons have a special 'data' storage which in this case is used to store the channel ID, but it could be another object, a string, anything that's useful in that scenario
[18:19:05] brfransen (brfransen! has joined #mythtv-theming
[18:21:25] gbee: I'd make a change to the patch in light of the m_channelText addition –
[18:21:48] gbee: N.B. The patch won't apply, I hand edited it so the line numbers are wrong
[18:22:12] iamlindoro: If we used "channel" as the textarea name, we should use it in the button as well
[18:22:16] iamlindoro: button textarea is "name"
[18:22:24] iamlindoro: </consistencyNazi>
[18:22:49] iamlindoro: gbee: Change to which patch? Think mine already handles that text
[18:23:22] gbee: the itemSelected signal can send the 'item' which is selected, by using that we avoid two additional calls to GetItemCurrent() and one null pointer check on 'item'
[18:23:49] iamlindoro: oh, yeah, I had intended to make that change, oh well
[18:24:52] brfransen (brfransen! has quit (Quit: brfransen)
[18:25:02] mag0o: so, instead of itemChanged(void) you get itemChanged(???)
[18:25:14] iamlindoro: MythUIButtonListItem *item
[18:25:27] mag0o: oh
[18:25:29] mag0o: i see
[18:26:19] mag0o: and do you still need to check for item in the function?
[18:27:11] iamlindoro:
[18:27:17] iamlindoro: That actually will apply/compile
[18:36:10] gbee: mag0o: yes you still need to check, although it's more out of an abundance of caution than the chance that itemSelected will be sent without 'item' being valid
[18:36:40] gbee: that didn't sound right, but you get the gist
[18:38:17] mag0o: yeah
[18:51:20] mag0o: and with those changes, all i have to recompile would be mythtv, not plugins, right?
[18:51:48] iamlindoro: correct, since it doesn't change any core libraries/the API
[19:24:21] mag0o: yay!
[19:24:49] iamlindoro: yup, nice
[19:25:09] mag0o: so now svn diff and a ticket?
[19:25:12] iamlindoro: If you submit a patch, probably best to flesh out the textareas with anything else in the buttonitem
[19:25:17] iamlindoro: but after that, sure
[19:25:20] mag0o: cool
[19:27:09] mag0o: and would i find those in libs/libmythui/mythuibuttonlist.cpp?
[19:27:21] iamlindoro: ?
[19:27:27] iamlindoro: Don't understand the question :)
[19:27:33] iamlindoro: same exact file
[19:27:48] mag0o: the other textareas for the buttonitem
[19:28:03] iamlindoro: channeledit.cpp-- look at the other ->SetText()s in fillList
[19:28:03] mag0o: i guess my q is, what items are held in the button object
[19:28:09] mag0o: ok
[19:28:12] iamlindoro: they are custom
[19:29:05] iamlindoro: You set named textareas in a buttonitem/buttonlist by creating the buttonobject and calling SetText on it
[19:30:00] iamlindoro: so, for example, the buttonlist you were asking about the other day has a couple of ->SetText("url", somevalue) and ->SetText("name", somevalue) type things
[19:31:05] mag0o: ahhh
[19:55:34] brfransen (brfransen! has joined #mythtv-theming
[20:23:07] mag0o: that's got the channel icon and 6 textareas that i could find
[20:26:18] iamlindoro: works for me
[20:26:51] iamlindoro: Fair warning that one of us might change variable/textarea names, but I'd only do that for consistency
[20:27:24] mag0o: fine by me :)
[20:27:51] mag0o: anything particular I should title the ticket?
[20:28:11] iamlindoro: Whatever sounds descriptive and specific is fine
[20:29:15] gbee: Beirdo: another tool to add to the automated tests/reports –
[20:30:19] ** iamlindoro would sort of like an update re: licensing **
[20:31:25] iamlindoro: mag0o: The *only* thing I'd change in your patch is something I think you emulated from elsewhere, so not your fault
[20:31:26] iamlindoro: m_compoundname = dynamic_cast<MythUIText *>(GetChild("compoundname"));
[20:31:34] iamlindoro: Think we use "channel" for that everywhere else
[20:31:35] mag0o: yeah
[20:31:43] Beirdo: cool
[20:31:45] mag0o: it shows the whole thing there
[20:31:56] iamlindoro: mag0o: But leave it, if anything chances I'd want to change the buttonlist too
[20:32:01] iamlindoro: changes
[20:32:05] mag0o: channel name, number and source
[20:32:15] iamlindoro: hmm, guess source is different
[20:32:21] iamlindoro: oh well, nice job, looks great
[20:32:26] mag0o: i think it was source
[20:32:33] mag0o: thanks for walking me through it
[20:32:45] iamlindoro: Welcome to hell, now you'll be expected to fill all your own feature requests ;)
[20:33:15] mag0o: lol
[20:35:42] gbee: Beirdo: that was supposed to be in #mythtv, but at least you are in here too ;)
[20:36:07] Beirdo: heh, and this gets logged, so I can find it later too :)
[20:37:00] gbee: I don't fully understand what lcov/gcov does, but it sounds good :D
[20:37:17] Beirdo: that's a code coverage tool, no?
[20:39:07] gbee: yeah it is, I was half joking when I said I don't understand it, I'm just not familiar with gcov as a coverage tool, what sort of type of coverage reports it produces
[20:39:20] mag0o: so, actually with compoundname, i only need one textarea :)
[20:39:40] gbee: but I don't believe we have a coverage tool in the mix yet?
[20:40:10] iamlindoro: mag0o: So long as you agree with compoundname's format, sure
[20:40:31] mag0o: true
[20:40:54] iamlindoro: mag0o: so if I apply it, you get to wikify it ;)
[20:42:25] gbee: I I remember right, 'compound name' only exists because we have a user-defined setting for the channel format, otherwise that could have been handled with a map + templates
[20:42:42] gbee: if
[20:43:33] iamlindoro: gbee: You asked the other day about settings removal, Sphery and I got five between us yesterday \o/
[20:43:39] iamlindoro: woo hoo
[20:48:28] gbee: more
[20:48:45] iamlindoro: greedy little...
[20:48:55] gbee: nah, nice work
[20:49:00] iamlindoro: heh
[20:54:19] iamlindoro: If the web setup thing really works out, I still think we can take every minor toggle that we can't get away with getting rid of and move it to a per-host config page
[20:54:36] iamlindoro: leaving us with a very lean set of UI settings that we could actually MythUI/whatever
[20:55:09] iamlindoro: ie http://backend:6549/advancedConfig=hostname
[21:04:22] sphery: where "five between us" means iamlindoro: 4, sphery: 1
[21:04:32] iamlindoro: teamwork, buddy, welcome to it
[21:04:49] iamlindoro: where value of settings removed by iamlindoro = 1/4th the one removed by sphery
[21:04:56] sphery: heh, just making sure you get your share of credit for doing lots of work
[21:05:04] iamlindoro: pfft, you did FAR more than I
[21:05:06] sphery: heh, not so much
[21:06:29] iamlindoro: So I was thinking about building microblogging into the protocol
[21:07:01] iamlindoro: As much as I don't care about twitter et al that much, I do think that social networking is becoming a popular part of our competitors
[21:08:02] iamlindoro: and the only way I can think of to allow the recommending of shows/tweeting during watching/etc. in a clean, easy, user friendly way is to build it into the backend
[21:32:47] gbee: we allow backend plugins, allow plugins to expand the protocol through special handling and allow for some interesting things to be done without cluttering the core application/protocol
[21:33:07] iamlindoro: presume that's "we *should*"
[21:34:15] iamlindoro: I'd want to get pretty integrated, like adding recommendation info to programinfo, allow for recommending of a show from any pginfo using screen, etc.
[21:34:39] gbee: there is nothing which actually prevents the existing plugin architecture from being used by the backend, plugins aren't required to have a UI, with appropriate event system hooks and callbacks it would be doable for them to use the protocol too
[21:37:03] gbee: iamlindoro: I'm not saying that this particular feature, or at least parts of it shouldn't be integrated, but at least for now I'm reluctant to hinge the whole thing on commercial social networking sites that may be the cool thing today but which can become uncool just as fast
[21:37:33] gbee: facebook replaced myspace, myspace replaced friends reunited etc
[21:37:55] iamlindoro: gbee: Well, the idea would be to use a twitter-API speaking site, but doesn't need to be twitter, there are lots
[21:38:09] iamlindoro: including getting the source and running our own on services if it came down to taht
[21:38:47] iamlindoro: Put more succinctly, the twitter API is open and adopted by many sites, and the source for running an analogue is available
[21:40:07] iamlindoro: could even run our own backend for recommendations and use one of the "established" ones for public announcements/social portion
[21:40:18] gbee: if at least the parts concerning recommedation in ProgramInfo were generic they might actually be populated in other ways, e.g. from listings sources by xmltv grabbers etc
[21:40:57] iamlindoro: don't see any reason not to be generic
[21:41:37] iamlindoro: was thinking something like boolean recommended, Qstring recommendSource, QString recommendMessage
[21:41:57] iamlindoro: although I guess int recommended would be better
[21:42:07] iamlindoro: 0 = NULL, 1 = recommended, 2 = avoid
[21:44:03] iamlindoro: or going even further, one of the container classes for each so that you could have multiple sources weighing in on the same show, etc.
[21:44:38] iamlindoro: ie sphery says avoid this show with message "foo" and gbee says watch this show with message "bar"
[21:51:14] ** gbee says ignore everything sphery says **
[21:51:35] ** sphery says ignore everything sphery says **
[21:51:53] ** iamlindoro ignores anyone who disagrees with him anyway **
[21:51:56] sphery: (and watched gbee's scheduler fall to its knees with indecision)
[21:51:57] iamlindoro: ;)
[21:52:52] iamlindoro: Just imagine how excited bjm et al would be to include TwitWeight into the scheduler!!  ;)
[21:55:42] gbee: iamlindoro: the thread in xmltv-devel titled "[Xmltv-devel] Extend DTD to allow for dedicated recommended/review elements" might be of interest
[21:56:34] iamlindoro: I'll have a look

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.