One keeps thinking it is programmer-error when in fact it's something outside their control. ![]() I think we've managed pretty well with so many unsuspected significant bugs in the mix. And now I've uncovered a fourth significant bug (Qt), mentioned here: Plus, we've uncovered maybe three other significant bugs, so divide that post-length by three. Record discussion length? Probably not even close, hee-hee. If anything, I'd consider removing the recent bug addressed, i.e., everything contained within ![]() I myself prefer more atomic changes, but I really don't want to put too much more time in this changeset. I never suspected so many related bugs in KDE and Qt to arise. Yes, the items addressed in this patch have grown. My feeling is that there should be a better way of having the File Editor deal with it more locally, such as in some focusInEvent virtual function override. I took that out, and that may be why on your system there is a highlight issue on the first try. Anyway, the file editor is treated with special consideration. I do feel though that the focus_changed routine is overly complicated with it search through the previous focused object "linked list" that could result in an infinite loop by happenstance so is arbitrarily limited to 100 counts or something. Also drop the specialĪttached is a patch where I backed out the above change. Widgets and if not found don't change the highlight. Instead, just look for the currently focused object in all the octave dock * (main_window::focus_changed): Simplify this routine byĮliminating the indefinite loop search through all previous focus objects. This probably has to do with the change I made to : We can add padding to those buttons in the CSS and spread those apart. Before a new changeset candidate, though, what do you mean by compactness? Are you referring to the title bar buttons? I've mentioned before I feel those are too close and difficult to select. To the cascading style sheet and it appears to fix the issue. But I can say that for Oxygen setTitleBarWidget(0) setParent(0) is not producing full decorations and therefore it should be fixed. ![]() set_title() uses the custom title bar.įor example, I couldn't have said in the KDE bug report that for Oxygen setParent(0) setTitleBarWidget(customtitle) setParent(0) is not producing full decorations therefore it should be fixed. The construct of setParent(0) setTitleBarWidget(customtitle) setParent(0) is not documented as doing anything, and in fact the rules that are defined in the documentation would suggest the above should not have full decorations after the setParent(), if anything. The Qt documentation is indicating that one doesn't get full decorations if the custom title bar is set. Not using the custom title bar is the core issue.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |