| Monday, July 18th, 2011, 00:10 UTC | ||
| [00:10:30] | jpabq: | What is the trick in getting a white background for a textedit box? It seems like as soon as the box is selected the background disappears. |
| [07:18:50] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 260 seconds) | |
| [07:21:52] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv-theming | |
| [07:38:03] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv-theming | |
| [10:01:57] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 264 seconds) | |
| [10:26:17] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv-theming | |
| [15:42:48] | abqjp (abqjp!~abqjp@71-38-208-26.albq.qwest.net) has joined #mythtv-theming | |
| [21:27:04] | stuartm: | jpabq: did you figure it out in the end? |
| [21:29:17] | abqjp: | stuartm: The textedit background? Yeah, I think so. Although I noticed that even in Terra, in customedit, the background disappears when the multiline textedit box is selected. |
| [21:30:22] | abqjp: | Also noticed that a fixed width font must be used with textedit, or the cursor does not track the text. |
| [21:32:28] | stuartm: | the textedit is flaky and I really don't know why, the cursor issue seems to be a QT bug |
| [21:33:14] | stuartm: | the disappearing background with the multiline text edit is probably just a theme issue in Terra |
| [21:34:00] | abqjp: | stuartm: maybe, although most themes seem to have that problem — but not all. |
| [21:34:22] | stuartm: | I didn't theme it, and I've never spent any time trying as I kept expecting that I'd have a proper, working multiline textedit written beforehand |
| [21:34:50] | abqjp: | multiline textedit not working is a Qt or a mythui problem? |
| [21:35:10] | stuartm: | I need to come up with an alternative mechanism for the textedit, hinging it on QT's font metric stuff was a mistake |
| [21:35:52] | stuartm: | abqjp: there actually isn't a multiline textedit, the widget that exists now was written and designed to function as a single line widget only |
| [21:36:15] | abqjp: | I would be willing to take a crack at it --- but if it should not be based on Qt's font stuff, how should it be done? |
| [21:36:35] | stuartm: | it can be made to appear multiline by stretching the area but internally it's still working on the basis of a single line |
| [21:36:55] | abqjp: | The current single-line stuff would not be so bad, if it support scrolling. |
| [21:37:05] | stuartm: | abqjp: that's the question I got stuck on, I really don't know how to make it work as intended |
| [21:37:51] | stuartm: | unless I'm missing a trick with QFontMetrics, it just isn't up to the job |
| [21:39:25] | sphery: | stuartm: didn't you mention that we may have an issue with MythUITextEdit due to assuming that width("c") + width("a") + width("t") = width("cat") (when it's not, due to kerning and such--as mentioned in the comment on http://bugreports.qt.nokia.com/browse/QTBUG-10507 ) |
| [21:39:45] | sphery: | or maybe you've already updated mythuitextedit for that |
| [21:40:57] | stuartm: | sphery: I honestly cannot remember, I lost interest in that widget after spending far too long trying and failing to come up with a working solution so I don't know if I ever went back and addressed that issue |
| [21:41:53] | stuartm: | I might be motivated to work on it again now, if only so I can put the whole sorry mess behind me :) |
| [21:42:45] | sphery: | heh, I know the feeling |
| [21:43:20] | sphery: | though your mythui conversion time eclipses any time I've spent on mythtv coding |
| [21:44:11] | sphery: | anyway, abqjp , maybe that may be related? |
| [21:45:41] | paul-h: | I did look at the cursor problem and sphery is correct in what he says about the the widget adding up the individual widths of the characters which doesn't match the actual string width so the cursor gets further out of line the more you move |
| [21:46:00] | abqjp: | sphery: could be. I may look into that, unless stuartm plans to — he certainly has a lot more Qt knowledge than I do, but I should be able to figure it out eventually. |
| [21:47:31] | sphery: | also, don't know if the new cutdown code (which is commingled with a new feature) in the patch on http://code.mythtv.org/trac/ticket/9295 may be usable |
| [21:48:09] | abqjp: | stuartm: I assume http://doc.qt.nokia.com/latest/qtextedit.html is too "heavy"? |
| [21:54:29] | stuartm: | abqjp: it was going to be my fallback option, I wasn't sure that it was going to themable enough |
| [21:54:53] | stuartm: | i.e. we'd have to sacrifice some things to use it |
| [21:58:10] | paul-h: | QT widgets don't play nicely with MythUI ones, you run into problem showing popups over them for example |
| [21:58:47] | paul-h: | unless you render it to a bitmap but then I think you would loose the cursor |
| [21:59:07] | stuartm: | yeah, we'd have to paint to an intermediary image etc, it's definitely not the simplest approach and we can't guarentee consistent behaviour between QT releases |
| [22:06:17] | stuartm: | iamlindoro: playing with the date/time formatting I started thinking about whether we should permit themers to specify, as much as possible, whether the short or long dates are used in the same way we do now for the clock widget |
| [22:06:35] | stuartm: | is that something you think is worth having? |
| [22:08:22] | paul-h: | abqjp: If you do go down that route you may want to look at how the MythUIWebBrowser widget works, basically if it has focus it is a qt widget but when it isn't focused or not at the top of the stack it hides the qt widget and renders to a MythImage and paints that |
| [22:09:58] | stuartm: | everywhere we display a date we'd be able to use <template>%SHORTDATE%</template> to decide which format was used instead of having the format hardcoded – in theory it would simplify ProgramInfo::ToMap() since we'd not be generating so many different strings to allow the same flexibility |
| [22:14:30] | stuartm: | abqjp, paul-h: if we went with that you would be unable to have any image/shape overlapping an active textedit, which doesn't sound so bad given the fact that you naturally don't want to obscur the text anyway but it could become a serious pain for themers |
| [22:16:22] | stuartm: | I know in metallurgy iirc I played with having a glass effect in front of the text which I ultimately decided against, but it wouldn't work at all if the widget was based on the QTextEdit |
| [22:17:21] | stuartm: | I'd like for it to be the last resort once we're out of other ideas |
| [22:27:38] | paul-h: | I'd much prefer a proper mythui widget as well but this will be something like the the 3rd or 4th release with a broken multiline edit so it's about time something was done and if abqjp is volunteering to look at it at least we could get something that's usable |
| [22:39:07] | iamlindoro: | stuartm: Sorry, was commuting-- I think that being able to specify at least that level (short v long) would be nice, it's one thing to make space for a small variety of user specified strings, it's another to have to inflate a textarea to huge proportions to accommodate every single one |
| [22:39:22] | iamlindoro: | especially when you had conceived of something using the short-short form |
| [22:40:08] | iamlindoro: | ISTR a couple instances of users having meltdowns over their giant date formats not fitting in one theme or another |
| [23:01:31] | paul-h: | abqjp: the problem with the disappearing backgrounds in the multil-line edits is because the color is missing from the active state's background shape, at least that is what it was in MythCenter-wide |
| [23:02:02] | stuartm: | yeah, what prompted the thought for me was noting that certain screens pick one or the other but don't offer both, so even when I'd prefer the longer form and I have the space I don't have the option |
| [23:03:11] | stuartm: | in the guide grid I just added a second textarea showing the date in the other format, but that's messy and would need to be done for every place we currently display a date |
| [23:06:37] | stuartm: | I'll see how difficult it would be to have MythUIText accept a QDate(Time) directly, for mapped text I'm thinking we might have to read in the date in string form, convert to QDateTime then spit out a string again which isn't exactly efficient |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.