#pyqt | Logs for 2019-03-02

Back
[00:00:08] <altendky> storgance: hitbox?
[00:02:51] -!- storgance_ has joined #pyqt
[00:03:11] <altendky> storgance_: hitbox?
[00:03:22] <storgance_> Sorry, bad wifi here.
[00:03:32] <storgance_> If I hover over the box at a smaller size, it hides its lower line as seen in the screenshot
[00:03:54] <storgance_> However, if I make it larger, my mouse has to be higher than the box in order to hide the line
[00:04:06] <altendky> storgance_: I'm telling you, irccloud is a decent free alternative :]
[00:04:19] -!- storgance has quit [Ping timeout: 256 seconds]
[00:04:20] <altendky> Hmm...
[00:05:16] <storgance_> I just really need to set up my own bouncer at school. I just need to borrow a car and spend 4 hours setting it up. Not easy moving a poweredge r710 unfortunately
[00:05:36] <storgance_> Maybe I should try that for now, though
[00:08:42] <altendky> storgance_: if you mouse over an item in a regular list do you get a highlight?
[00:09:01] <storgance_> I see...Wait a second.
[00:09:06] <altendky> Either border or background or both
[00:09:35] <altendky> I'm not at my computer or I'd just be trying myself. That'll have to wait for tomorrow at this point
[00:10:41] <storgance_> there's a blue box which suggests it, but the blue box isn't the same height as the widget for the last one
[00:15:20] <altendky> storgance_: you could try commenting out the show and close in the new delegate method and just self.widget.show() in the prepare method
[00:15:38] <altendky> Program won't quit, you'll have to kill it, but as a test
[00:21:31] <storgance_> altendky: The blue background box and much more are the wrong size, but no disappearing
[00:29:28] -!- storgance_ has quit [Quit: Page closed]
[02:44:47] -!- kushal has quit [Remote host closed the connection]
[02:45:03] -!- kushal has joined #pyqt
[03:14:11] -!- Dave_Elec has joined #pyqt
[04:27:49] -!- kushal has quit [Read error: Connection reset by peer]
[04:29:32] -!- kallesbar has joined #pyqt
[04:29:38] -!- kushal has joined #pyqt
[06:39:26] -!- Dave_Elec has quit [Ping timeout: 250 seconds]
[06:47:26] -!- BPL has joined #pyqt
[06:49:39] -!- Dave_Elec has joined #pyqt
[07:11:26] -!- mintograde has joined #pyqt
[08:44:53] -!- Dave_Elec has quit [Ping timeout: 255 seconds]
[14:06:23] -!- storgance has joined #pyqt
[16:03:31] <altendky> storgance: how's this? https://gist.github.com it's bad and is constantly updating itself... but seems to work the best here. i hadn't recreated everything you described yet.
[16:04:19] <storgance> Ooo functools
[16:04:33] <altendky> mm, unused. forgot to remove it
[16:04:45] <storgance> Oh okie
[16:05:27] <altendky> storgance: i haven't given up, but i am getting a bit worried about actually finding a tidy and general solution to this.
[16:07:26] <altendky> also, the widget .layout attribute is shadowing the .layout() method of QWidget... isn't inheritance fun?
[16:07:35] <altendky> hmm, i wonder if that's causing any trouble...
[16:13:03] <storgance> Goodness this is a mess...I would have thought this would be simpler given the whole MVP paradigm Qt ascribes to...
[16:13:31] <altendky> size hints that depend on the size given to them... isn't the simplest thing ever.
[16:13:45] <altendky> i suspect that in a normal layout it has a better chance to iterate to a solution
[16:14:04] <altendky> but i'm trying to cheat here so... trying to figure out how to be less cheaty about it
[16:14:18] <storgance> but this is something I figure would be common enough that it would be easy, hence why I thought that the sizeadjust features were meant exactly for this
[16:14:47] <altendky> storgance: i wouldn't be surprised if it's one little thing i've got wrong. maybe...
[16:15:16] <storgance> Perhaps...it's just strange to me still
[16:15:30] <storgance> Also, I jsut realized that irccloud shows you the names of who you're talking to
[16:15:33] <storgance> *just
[16:15:44] <storgance> meaning you see me as Papa John's Pizza
[16:15:55] <altendky> mm? i see `storgance`
[16:16:19] <storgance> I see your real name next to altendky
[16:16:28] <altendky> hmm. i dunno
[16:17:01] <altendky> i guess i do have my full name entered though, forgot about that
[16:18:50] <altendky> https://bugreports.qt.io i still don't like this bug even though it claims to be fixed
[16:21:57] <altendky> i'm not even clear what fixed it supposedly
[16:22:32] <storgance> Ooo Russian
[16:31:24] * Avaris hmmm... constant sizeHint calls
[16:32:00] <altendky> Avaris: and the constant width being passed to the delegate size hint via option.rect...
[16:32:24] <altendky> doesn't seem like i should be calculating a width there myself
[16:33:05] <Avaris> option.rect.width() isn't the right answer?
[16:33:28] <altendky> Avaris: by my diagnostics the width is always 256 regardless how wide the view is
[16:33:48] <altendky> but it isn't in the paint call
[16:34:11] <altendky> and you end up with a single resize event delay getting the proper size hint calculated
[16:34:34] <altendky> quite like https://bugreports.qt.io "for QStyledItemDelegate the mismatch also exists, though only for one pixel"
[16:35:17] <Avaris> super().sizeHint(...)?
[16:36:21] <altendky> Avaris: as in don't define sizeHint at all on the delegate?
[16:36:38] <Avaris> no, no. take width from that
[16:37:15] <altendky> Avaris: to return the proper height i need to know the actual width i will be. what with wrapping and all
[16:37:37] <altendky> not what width i 'want' to be
[16:38:09] <Avaris> am i misunderstanding? you want the "usable" width inside view, right?
[16:38:29] <altendky> Avaris: right. i'll print super().sizeHint() and see what it is
[16:39:29] <Avaris> hmm... actually no. that might not give you that
[16:40:23] <Avaris> it will be in the paint, but not necessarily in sizeHint
[16:40:27] <altendky> seems to be 0,14 always
[16:41:04] <Avaris> right, because your items are empty
[16:41:32] <altendky> is there a good reason for the fixed option.rect.width()?
[16:41:42] <Avaris> fixed?
[16:41:50] <altendky> it's always the same 256
[16:42:03] <altendky> err
[16:42:07] <altendky> lemme check again
[16:44:00] <altendky> i knew i shouldn't have removed my diagnostic prints :[
[16:44:25] <Avaris> i get 183 and 256
[16:44:58] <altendky> does the width change as you resize horizontally?
[16:45:17] <Avaris> no
[16:46:22] <Avaris> but height did
[16:48:22] <altendky> there seem to be a few calls now at each resize that get something closer to a sensible width
[16:48:47] -!- kallesbar has quit [Remote host closed the connection]
[16:49:08] -!- kallesbar has joined #pyqt
[16:49:55] <altendky> i guess i should be subtracting the view's contents margins in the delegate size hint as well?
[16:50:19] <altendky> (in so much as i should be calculating anything :[ )
[16:51:55] <altendky> or contentsRect()?
[16:53:26] <altendky> the last item (regardless if there's one and it's the first, or three and it's the third) also doesn't seem to collapse properly below seemingly four rows of text
[16:54:32] <altendky> contectsRect seems to get the same width i was calculating
[16:55:05] <altendky> until their's a scrollbar...
[16:55:59] <Avaris> did you try view.viewport()?
[16:56:48] <Avaris> that should have usable area... i think
[16:57:40] <altendky> viewport.contentsRect()?
[16:58:05] <Avaris> viewport.width()
[16:58:19] <altendky> also, did you notice despite having a totally custom render we had to enable word wrap on the view? otherwise it wouldn't resize the heights for horizontal window resizes
[16:59:13] <altendky> viewport().width() looks good with and without the scrollbar. thanks
[17:01:57] <altendky> maybe the size stuff passed by option shouldn't be considered to mean anything. only mention in docs is "taking into account the style information provided by option" https://doc.qt.io
[17:02:14] <altendky> where i guess 'style information' might not be considered to include the rect? maybe
[17:03:39] <Avaris> i thought it would have the correct size for given text to fit
[17:04:10] <altendky> hmm, i hadn't actually looked at what the view might see as text (the display role)
[17:04:13] <Avaris> so not necessarily connected to the view sizes but what's required to display text
[17:04:25] <Avaris> well, not only text. decoration, icon, etc
[17:04:30] <altendky> looks like nothing is set
[17:04:41] <Avaris> yeah, your items are empty
[17:05:08] <Avaris> probably why widths are same. but not sure whats up with the heights
[17:08:12] <altendky> hmm, i'm also returning a fixed width for the size hint :|
[17:18:38] <altendky> size hinting from the widget having it's present width seems to make the option.rect at least closer
[17:19:44] <altendky> though i'm not quite sure why it isn't delayed by one cycle
[17:19:58] <altendky> but i guess i don't have complete tracing prints at the moment
[17:24:58] <altendky> On its own I'm not sure it makes sense to report your present width as your size hint, but in this case it's the only thing that makes sense given how the height is calculated
[17:35:04] <Avaris> i'm still not sure why sizeHint gets called over and over
[17:38:15] <Avaris> also, there is a blue rectangle over the right view visible when you have no items.
[17:47:41] <altendky> at the bottom? isn't that the separate text entry thing?
[17:47:52] <Avaris> no for the top right view
[17:48:32] <altendky> https://usercontent.irccloud-cdn.com
[17:49:14] <altendky> i've mostly been working without the `self.widget.setParent(self.parent())` line. with it it does clean some stuff up
[17:49:21] <altendky> at the cost of constantly updating
[17:49:26] <altendky> well, constantly something'ing
[17:50:57] <altendky> as to the last item remaining tall... it seems to get the size hint the proper height and the rect passed to paint seems right
[17:55:47] <altendky> and when you click on it there's a little glimmer of a highlight off to the right
[17:55:58] <altendky> that is the proper height which is less than the blue background height
[17:56:51] <altendky> ok, actually yes, there is a blue block at the top of the right hand column when i have the parent set. sorry.
[18:04:27] <altendky> the text browser height is actually sticking at 70 (the four rows)
[18:06:59] <Avaris> btw, did you see this? https://stackoverflow.com
[18:10:35] <altendky> i should probably read up on that style stuff
[18:11:01] <altendky> trying to figure out at the moment why the option.rect is 52 high and the widget ends up 70 high
[18:14:44] <altendky> minimum size is 70x70. and setMinimumHeight doesn't seem to stick
[18:15:43] <Avaris> hmm?
[18:16:43] <altendky> in the widget's setup_ui i set both itself and the msg minimum height to 0, but in paint it still reported 70x70 for minimum size. so, no wonder it was 4 rows high regardless. setting minimum height at the beginning of paint 'fixed' that
[18:19:45] <altendky> https://gist.github.com
[18:20:26] <Avaris> oh you changed widget.sizeHint, i was gonna suggest that :)
[18:21:53] <altendky> Yeah, that got the right option.rect to be passed to the delegate size hint seemingly
[18:22:32] <altendky> So at least I can see that connection. Though I think the viewport check _might_ still be good
[18:23:49] <altendky> Though I don't really like reaching out through the parent
[18:24:01] <Avaris> also, why don't you use a QLabel instead of QTextBrowser?
[18:24:17] <altendky> Supposedly something about wrapping?
[18:24:23] <Avaris> it has wrapping
[18:24:23] <altendky> I didn't fiddle with that
[18:24:43] <altendky> Specifically about long 'words'
[18:24:48] <altendky> Iirc
[18:24:57] <altendky> storgance: ^^^
[18:25:17] <storgance> hello
[18:26:26] <storgance> Avaris: it has word wrapping but not character wrapping. If someone sends a message in my chat with "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" it breaks
[18:26:29] <Avaris> i mean, qtextbrowser is designed to have a fixed size regardless of its contents (scrollable and such), and that add extra complexity to your calculations
[18:28:00] <Avaris> ok, fair enough
[18:28:36] <Avaris> but i gotta say, this "experiment" starts to get real close to manually painting :)
[18:29:01] <storgance> The reason why I went to QTextBrowser is because I saw QTextEdit had this kind of "character wrapping" without having to modify the user input, and I figured since QTextBrowser comes from QTextEdit that whatever solution worked for it would also work for the user input box
[18:31:32] <altendky> Avaris: I think, without having carefully reviewed, that many of the issues would have been present regardless. As long as I eventually get to generic solutions I'm happy. But yeah, it's not a slam dunk here, sure
[18:32:01] <altendky> Hopefully the delegate is just being refined and works out better next time...
[18:32:23] -!- BPL has quit [Quit: Leaving]
[18:32:49] <storgance> There _has_ to be an easier way to do this. This is a common feature people want, group chats are common enough, like...It's getting to the point of spending 3 days reading source code for other apps or something
[18:33:03] <altendky> Avaris: and I do very much appreciate your time and help especially since it isn't how you would do this...
[18:33:28] <altendky> storgance: have you found one that does this?
[18:33:30] <altendky> In qt
[18:34:14] <storgance> https://github.com
[18:34:21] <storgance> The very client I am trying to model mine after
[18:34:58] <storgance> And one of the tools I was going to piggy back off of for my secure communications)
[18:35:26] <altendky> storgance: and how does it do it?
[18:35:43] <storgance> I'm...not sure. as I said, it's getting to the point of reading their source code for 3 days
[18:36:14] <altendky> storgance: and you haven't found the widget yet?
[18:36:29] <storgance> Not yet, I was hoping QTextBrowser was it...
[18:37:49] <altendky> storgance: do they use a list view? Any idea where anything related is?
[18:39:34] <storgance> I don't know. Telegram Desktop is known a bit by the Telegram community as a whole as a disgusting mess. It's really only the basic functions of the UI I am fond of
[18:40:47] <altendky> storgance: have you asked them?
[18:42:27] <storgance> I don't know if they have a public channel or something of the likes...
[18:43:08] <storgance> ...well, by the looks of it
[18:43:14] <storgance> they may even just not use QT for that
[18:43:19] <storgance> maybe they use unity
[18:43:27] <storgance> I know they use QT, but not sure if for that
[18:45:19] <storgance> tg desktop has a twitter :|
[18:45:52] <storgance> and they tweet like 5 times a year
[18:46:27] <altendky> GitHub issue?
[18:47:39] <storgance> there are 936 issues my goodness
[18:48:18] <altendky> storgance: have you searched for`Write a message...` and traced from there?
[18:48:32] <storgance> That's a good idea
[18:48:53] <Avaris> that's a lot of code...
[18:50:15] <storgance> Yeah
[18:51:46] <storgance> What in the world...
[18:53:35] <storgance> https://github.com
[18:53:44] <storgance> they have a page....just for all of the strings?
[18:54:22] <altendky> storgance: if you want to have translations...
[18:54:46] <storgance> that's nutty
[19:01:54] <Avaris> but just judging from the screenshots, qlistview on left, qlistview on right, custom delegates all over
[19:06:00] <storgance> yep
[19:33:59] -!- kallesbar has quit [Quit: Konversation terminated!]
[19:43:54] <altendky> hmm, seems high and left by one pixel. no dark blue border at the very top or left
[19:45:27] <altendky> but that SO link earlier looked like some of the style stuff might be relevant
[19:50:46] <altendky> mapping from the viewport() seems to fix that `target_offset = option.widget.viewport().mapTo(top_level, option.rect.topLeft())`
[19:51:36] <altendky> storgance: want to try again? https://gist.github.com
[19:53:46] <storgance> Nothing is disappearing or glitching...
[19:54:40] <storgance> I can't find anything wrong with it
[19:54:52] <altendky> storgance: must not have read the code yet :]
[19:54:59] <altendky> there's some nagging things there
[19:55:02] <storgance> Not yet
[19:55:28] <altendky> at least the need to set the minimum height outside the widget.
[19:56:51] <storgance> minimum height of 0...
[19:57:22] <altendky> storgance: yeah, but if you set it in the widget's .setup_ui() it gets changed
[19:57:33] <altendky> that's why the last item wasn't collapsing vertically
[19:57:57] <altendky> so i was setting it in the delegate paint()
[19:58:45] <altendky> which aside from seeming hacky is bad because then a widget can't enforce a minimum height. though hmm, it'd have to do it through the size hint anyways... hmm...
[19:59:24] <altendky> it's not like the 70 worked properly, it only affected the widget but not the actual item height or the highlight height
[20:00:23] <storgance> I'll be honest, I don't know nearly enough about the internals of Qt to know what's happening at this point :|
[20:00:36] <altendky> ok, not the last one only, i think all of them were having that issue
[20:00:47] <altendky> storgance: you say that like i do :]
[20:00:58] <storgance> wellll, better than I haha
[20:01:23] <storgance> this is the first ever thing I've made in Qt, and frankly you're making as much of it as I am
[20:02:14] <altendky> i can't stand that seemingly simple things like this are not simple. that you have to figure out all these offsets and so on etc just to stick some text somewhere.
[20:02:35] <altendky> or the model stuff, bah. though that side of what i've done is still pretty messy.
[20:05:11] <storgance> uff
[20:05:15] <altendky> next diagnostic, translucent background. yeah, not just the last one being too tall without the minimum height set
[20:09:47] <altendky> https://doc.qt.io so the delegate doesn't have a size policy or a minimum size etc. just the size hint. so i guess widgets that want to enforce a minimum size must be expected to do so themselves via their size hint? or maybe the delegate should do so to make it a little more 'normal'?
[20:11:28] <Avaris> delegate isn't a widget
[20:11:42] <Avaris> why would it get a size policy?
[20:12:36] <altendky> Avaris: sure, yet it has a size hint. i was just noting that it didn't have the other similar sorts of things and that perhaps to make itself a bit easier to use it should pay some attention to, for example, the minimum size that the widget has set
[20:13:41] <Avaris> delegate is subject to the view's limitations. whether columns/rows can grow etc. and calculates sizes based sizeHint accordingly
[20:14:46] <altendky> Avaris: sure, i'm not claiming that qt is somehow wrong here. i'm just asking if the WidgetDelegate would be more 'predictable' if it enforced the minimum and maximum size even if the widget reports a size hint outside that range.
[20:15:07] <altendky> though unless i can figure out why the size hint is being changed...
[20:15:14] <altendky> it kind of has to be ignored
[20:15:27] <altendky> err, why the minimum size is being changed
[20:15:41] <Avaris> yeah... but delegate can't enforce those restrictions to the view
[20:15:49] <Avaris> it's the other way around
[20:16:09] <altendky> Avaris: but given a size hint height of 50 and a minimum height of 70, it could relay the 70 to the view rather than the 50
[20:16:53] <Avaris> hmm? your sizeHint implementation returns 50
[20:17:50] <altendky> Avaris: i thought of this because the size hint was tracking the actual rows of text while the minimum size wasn't. so the view rows were getting shorted but the widget was still drawing itself at the larger minimum height
[20:18:09] <altendky> so i thought, aside from not knowing why the minimum height is what it is, suppose someone uses this and sets the minimum height...
[20:18:37] <altendky> should the delegate respect that in terms of trying to get that much space for the widget? it seems like that would be what a dev might expec[t
[20:18:46] <Avaris> first problem is why minimumSize is weird
[20:19:18] <altendky> Avaris: yes. doesn't mean i can't look ahead and wonder if the WidgetDelegate should have this functionality
[20:19:23] <Avaris> second, given that minimumSize weirdness..., you're painting the whole widget not your supposed "size" part where things are fine
[20:19:33] <Avaris> (the null_region thing)
[20:20:27] <Avaris> so even if your widget.sizeHint() says 50 height, your widget is 70 height and you paint all of that
[20:20:57] <altendky> Avaris: agreed, thanks.
[20:21:34] <altendky> though i think that's a separate issue, even if mixed in the same area
[20:22:02] <altendky> it shouldn't make the minimum size too tall and it doesn't help the height be what a developer might expect if they set the widget's minimum height
[20:22:28] <altendky> but option.rect seems reasonable for that?
[20:23:24] <altendky> mm, not quite
[20:24:05] <Avaris> you don't give it a parent, right?
[20:24:18] <Avaris> windows have a minimumSize > 0
[20:24:18] <altendky> not right now
[20:24:27] <altendky> mmm...
[20:24:43] <altendky> maybe set when they are shown? i'll check
[20:32:16] <altendky> looks to be the first time .show() is called
[20:34:18] <Avaris> <wild guess>try giving something other than 0 (e.g. 1)</wild guess>
[20:37:02] <Avaris> hah it's layout.minimumSize()
[20:38:04] <Avaris> defaults to that if size is 0 or invalid
[20:41:51] <Avaris> self._layout.setSizeConstraint(QLayout.SetNoConstraint)
[20:43:29] <Avaris> altendky: ^ works fine with that. and as a bonus, no need to set minimumHeight not even in __init__
[20:44:04] <altendky> Avaris: if I set geometry before show... Maybe
[20:44:32] <altendky> Typing from my phone for a few minutes so I can't try right now
[21:05:13] -!- stochastix has joined #pyqt
[21:15:31] <altendky> yep, that's good.
[21:15:31] <altendky> https://gist.github.com might be time to tidy again and see what dirty code is left
[21:15:45] <altendky> s/that's/what you suggested/
[21:36:45] <altendky> I think the highlight might be the yuckiest part left. 1) I assume that not every system just fills a rectangle. 2) it's easy to imagine the dev wanting to implement that in the widget.
[21:41:27] <altendky> But I think 1) was covered in the so link
[21:51:12] <altendky> https://stackoverflow.com i'm not understanding why they take the option, store it in optionv4, then init it. the initStyleOption docs say to do that if you weren't given the QStyleOptionViewItem...
[21:54:04] -!- mintograde has quit [Ping timeout: 244 seconds]
[22:02:58] <altendky> hmm, seems like the widget should get the whole style state at least
[22:21:46] <altendky> storgance: https://gist.github.com another tidied copy.there are a few new options relating to it drawing the 'standard item' or not with suboptions for the selected and focused highlights
[22:24:27] <storgance> Clean and tidy wooo
[22:25:55] <altendky> while there's obviously been lots to fiddle with (thanks to Avaris of course for lots of important details) it still looks to me like it's settling out quite generically. there doesn't seem to be lots of little fiddly workarounds etc.
[22:48:32] <altendky> so i think the `self._layout.setSizeConstraint(QLayout.SetNoConstraint)` call really is just a thing that the widget needs to do, as opposed to an oddity related to the use with the delegate. yes? no? doesn't mean the delegate wouldn't mention it, just that it would be documented rather than trying to find a way to move the effect in some form into the delegate.
[22:48:55] <altendky> the layout minimum size gets set to 70 when the widget is added to it
[22:51:08] <Avaris> altendky: you can do it in the delegate. `widget.layout().setSizeConstraint(...)`
[22:51:28] <altendky> Avaris: sure, but if it's not specific to the delegate...
[22:51:47] <altendky> it seems like it's generic functionality that in a regular layout scenario should do the same thing
[22:53:03] <altendky> plus, what if the widget doesn't have a layout and just paints itself :] i mean yeah, that's somewhat a degenerate use of this delegate, but i don't think it is entirely
[22:53:35] <Avaris> well, up to you :)
[22:53:49] <altendky> do you think it is an issue specific to this delegate?
[22:54:13] <Avaris> as for optionv4 in the s/o answer, that's an oddity for (py)qt4. you can ignore it
[22:54:23] <altendky> :]
[22:55:47] <Avaris> i think for this use case you want to hand craft sizes mostly and having weird minimums is confusing
[22:56:00] <Avaris> so, i'd probably enforce it in the delegate
[22:56:22] <altendky> i suppose i could give an option to skip that if the dev wanted
[23:00:09] <Avaris> eh, document it and let them change that in the filler method if they want :)
[23:00:30] <Avaris> *set no constraint, document it ...
[23:00:54] <altendky> why not the setup_ui()?
[23:01:05] <altendky> only needs to happen when it's created/configured
[23:02:01] <Avaris> you can't do it before setup_ui from delegate?
[23:02:39] <altendky> i was following on your 'eh, document it' comment. just that it could be in setup_ui where it runs once rather than in the filler
[23:03:02] <Avaris> also, i assume you know this but: `layout(widget) == layout(); widget.setLayout(widget)`
[23:03:03] <altendky> and no, i can't do it before setup_ui because the widget may not have a layout yet
[23:03:23] <altendky> but, i can do it after. where i just put it dependent on a parameter to prepare
[23:03:53] <altendky> yeah, i have a habit of doing these things separately
[23:04:01] <altendky> i forget if i have a reason or not... beyond habit
[23:20:51] <Avaris> no selection colors on the right view
[23:24:33] <Avaris> ^ painter.save(); render(...); painter.setCompositionMode(painter.CompositionMode_Multiply); drawControl(...); painter.restore()
[23:25:18] <altendky> Avaris: they belong on top? they were showing up for me but yeah, only because i made the background of the widget transparent
[23:25:23] <altendky> translucent (50% or such)
[23:25:42] <Avaris> on top?
[23:39:19] <altendky> Avaris: yeah, as in right now i'm calling drawControl before render, so the result of drawControl is 'behind' the result of render. you look to be suggesting flipping that around and having the drawControl draw after and therefore on top of the render result
[23:40:52] <Avaris> yeah, something like overlay over render
[23:41:51] <Avaris> you won't need to muck with transparency this way
[23:42:07] <altendky> it makes sense and i'll switch over. i'll note that the SO post didn't do that. and i'm a little unsure it will actually work all right.
[23:43:31] <Avaris> that's drawing a document. i believe that doesn't have background
[23:44:22] <altendky> sure. so there's potentially a desire for the widget to have two layers... :| a background behind the highlight and a foreground in front. but anyways, let me see what it does
[23:45:01] <Avaris> i suppose you can multiply it the other way around as well
[23:47:43] <altendky> Avaris: if it's supposed to be transparent... wouldn't it be using alpha?
[23:48:09] <Avaris> what's transparent?
[23:52:44] <Avaris> yeah, i think multiply will be same regardless of the operations. render first or second shouldn't matter.
[23:54:22] <altendky> so with both the selected and the focus rendering i moved it in front. (without multiply) clicking one totally blocked it out. ctrl+click (so it'll be focused but not selected) and i still see an effect, but it's translucent
[23:54:49] <altendky> so the selected is opaque but the focus is translucent
[23:56:52] <altendky> Avaris: https://gist.github.com
[23:59:47] <altendky> err, i had draw_selected=False in that code...