(release 30)bug fix get splitter working properly on editor right side#436
Conversation
|
Nah - I had a look at it, and there's a few issues with it, the risk of breaking a major part of Mudlet for no apparent problem just now isn't worthwhile. Let's iron it out after 3.0 and will get it in then. I do love all this cleanup work though! Will submit a proper review later on when I get time. |
|
|
|
Um, whoops, it seems I only included the first change to the |
|
Save some space for The Merge. Which is our next task at hand... time to freeze accepting PRs to |
This implements the part of commit-857a90bc1af88acd63d86f785ff0c51a164540cd to the development branch that removed the dlgOptionsAreaXxxxxx class and the associated options_area_xxxxxx.ui files. None of these are used now and they cruft up the area in the dlgTriggerEditor constructor that I am aiming to rework to achieve the main purpose of this PR. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Renames some widgets to better identify them:
* (QWidget *)dlgActionMainArea::widget
==> (QWidget *)dlgActionMainArea::widget_top
* (QWidget *)dlgActionMainArea::widget_4
==> (QWidget *)dlgActionMainArea::widget_middle
* (QWidget *)dlgActionMainArea::widget_2
==> (QGroupBox *)dlgActionMainArea::widget_bottom
* (QLabel *)dlgTimersMainArea::label_5
==> (QLabel *)dlgTimersMainArea::label_name
* (QWidget *)dlgTriggersMainArea::widget_6
==> (QWidget *)dlgTriggersMainArea::widget_top
* (QWidget *)dlgTriggersMainArea::widget
==> (QWidget *)dlgTriggersMainArea::widget_middle
* (QWidget *)dlgTriggersMainArea::widget_3
==> (QWidget *)dlgTriggersMainArea::widget_bottom
* (QLabel *)dlgTriggersMainArea::label_5
==> (QLabel *)dlgTriggersMainArea::widget_command
* (QLabel *)dlgTriggersMainArea::label_4
==> (QLabel *)dlgTriggersMainArea::label_name
Some "container" widgets have been removed from the .ui files used by
the editor (dlgTriggerEditor class):
* frame_rightBottom
* frame_rightTop
* mainArea
* popupArea
the code had to be revised to work on others, specifically:
==> mpSourceEditorArea
Revised all xxxx_main_area.ui files so that they all have "Name:" to
identify that aspect of the item that is being edited, and for all the
"direct string to send to MUD Server" entries to be "Command:" (obviously
the Action one has two under some conditions and none on others!
Revised all xxxx_main_area.ui files so that the ones that benefit from
extra space expand in the right places, for Triggers this is the middle
part which holds the list of trigger items and for Actions (Buttons /
Menus / Toolbars) this is the bottom widget which holds the "Optional CSS"
{which is now labelled "Style sheet:"}. Keys, Aliases and Variables do not
benefit and Scripts only takes a little to expand the middle widget
containing a list of events that are handled.
The timers_main_area.ui was reformatted slightly to make better use of
vertical space (putting labels for each time element OVER the number
as opposed to a long single label to the right of all the digit displays.
The millisecond display was revised to show three digits (using format
"zzz") as they represent a decimal portion of a second rather than only
a single "0" when not otherwise set to anything.
Similarly the source editor area (which now gains an explicit "Lua code:")
label at the top can expand freely and has a minimum size set of around
200. Code has been added to change the text to "Value:" when Variables are
being edited. This requires setting the text contained in the new:
* (QLabel) dlgSourceEditorArea::label_editor
The errors console - as it is a custom widget we construct in code also now
has a minimum size of 200 set but that has to be set in the
dlgTriggerEditor constructor.
Finally the system error messages widget has a minimum size set of 90 but
can now expand to 200 high.
All of these changes means that the splitter widget on the right hand side
of the editor is much more flexible and usable for a bigger range of
screen heights.
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
I felt sure I had remembered to remove the deleted dlgOptionsAreaXxxx class files and the associated options_area_xxxx.ui files in the first commit; but it seems I did not. 😊 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
There was a whole load of QActions that though defined and inserted into a pair of QMenus in the dlgTriggerEditor constructor however they were not inserted into the layout and thus were unused. They were remnants from prior code and could be safely deleteed. *Commits before this one have been rebased as they were applied to the codebase before it was released* Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
In the main commit in the PR I left the "Errors" widget shown on startup whereas in the past it was hidden until requested. This commit is needed to return to the initial hide state. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
d1f0008 to
bfd341b
Compare
vadi2
left a comment
There was a problem hiding this comment.
Love the work you've done on the splitter, it looks great and the minimums it allows are quite reasonable!
Just a few UI bugs popped up around the place...
| <widget class="QLabel" name="label"> | ||
| <property name="text"> | ||
| <string>Command:</string> | ||
| <string>Time:</string> |
There was a problem hiding this comment.
I'm on the edge about this, because this hasn't been an issue before and it would cause a lot of work for the documentation - we'd need to update the text everywhere accordingly and update our screenshots. That's just our own text documentation: screencasts would be out of date and would need to be re-recorded, and any documentation people have done themselves would be broken.
Basically, we could cause a whole lot of pain for no real benefit. There's a huge hidden cost to doing this. While we can't freeze the text forever either, I think it would be good to do in one fell swoop or something when we have a real need.
Do you see this change as being really necessary?
There was a problem hiding this comment.
The example you quoting seems to suggest changing Time: to Command: I suspect that is actually a side effect of item reordering within the .ui file. However, if you now compare all of the different item type dialogue they (should) all possess the same text for the same element which behaves the same on different item types - the prior inconsistency is just that, inconsistent, IMHO.
There was a problem hiding this comment.
Agreed, inconsistent. I am asking though if the cost to fix this inconsistency worthwhile?
| <widget class="QLabel" name="label_command"> | ||
| <property name="text"> | ||
| <string>send plain text:</string> | ||
| <string>Command:</string> |
There was a problem hiding this comment.
| </property> | ||
| <property name="text"> | ||
| <string>Substitution:</string> | ||
| <string>Command:</string> |
There was a problem hiding this comment.
| QVBoxLayout * pVB1 = new QVBoxLayout(mainArea); | ||
|
|
||
| // Replacement code to use single splitter for all right widgets: | ||
| mpSystemMessageArea = new dlgSystemMessageArea(splitter_rightTopBottom); |
There was a problem hiding this comment.
There was a problem hiding this comment.
It is tricky to get right, I am aware that there are some messages at the top of the dlgTriggerEditor.cpp file that do or should get painted in the "systemMessageArea" that dlgTriggerEditor::mpSystemMessageArea is the handle for and which dlgTriggerEditor::showInfo( QString ), dlgTriggerEditor::showWarning( QString ) and dlgTriggerEditor::showError( QString ) use. Those messages are currently of low quality and generally include a list of numbered steps which would benefit from revision to include laying out as a numbered list (using HTML tags?) but which will use more vertical space {which is OK as they appear only when there is nothing else to show on the right hand side!}
As I see it the bottom line is ideally I need to:
- find a way to align the systemMessageArea to the top of the dialogue
- to have a pleasingly proportioned minimum size (more like the 2.1 sample immediately above here).
- to allow it to grow reasonably should the system message text get larger.
- to convert embedded line feeds into <p></p> so that they get reproduced in multi-line error message from the Lua sub-system {
requireing a lua library that is not found produces the biggest error messages I believe} 😮
Note I already found that it was necessary to parse error messages for < and > as otherwise the HTML parser hides things like <eof> that the lua system sometimes throws up in its error messages...!
There was a problem hiding this comment.
Yes, the bottom line sounds good.
Regarding parsing: no need! QString::toHtmlEscaped().
There was a problem hiding this comment.
Well spotted - I wasn't aware of that one and it was introduced in Qt 5.0 so I only need a replacement for my Frankensteinian(?) Qt 4.x backport {As Gene Wilder in 'Young Frankenstein': "My God! It is alive!..."}
| <item> | ||
| <widget class="QLabel" name="label_editor"> | ||
| <property name="text"> | ||
| <string>Lua code:</string> |
There was a problem hiding this comment.
I don't think we need this label, it's redundant. The default text already says "Enter your Lua code here" and when you have entered Lua code in there - well, you see that there's Lua code there. In general finding where to put your Lua code hasn't been a problem, so we don't need to incur the real estate costs by adding this explicit label.
There was a problem hiding this comment.
Actually that place holder text actually caused me to raise a bug on Qt - anyway in some error messages it is necessary to describe where the error is, and in the specific case of Lua Condition triggers it is necessary to differentiate between a Lua error in a numbered "item" and one in the "Lua code:" area.
For the record the place holder only works for Qt 5.3 and later (I had to make the code to do it version dependent and I would, in hind sight, be happy to do away with it)... 🤷♂️
Actually this might be an issue on the Buttons/Menu/Toolbar display, where there are two (large) and now adjustable (and if you get your wish to make things collapsible) widgets. You suggested that we change the label for "CSS" so it now says "Style-sheet:", to then have another multi-line text entry box which would be unlabelled to my eye looks a bit disjoint from a common visual theme - though then the "Errors:" widget is also unlabelled. {OTOH that pops-up and hides on user request and is visually unrelated to the rest of the dialogue by having a black background compared to everything else being pale by default.}
It would also look "off" on the "Variables" editor where everything else has a name.
These are some of my thoughts on the aesthetics but I am willing to hear further input on this. 👂
| <item row="0" column="0"> | ||
| <widget class="QLabel" name="label_hours"> | ||
| <property name="text"> | ||
| <string>Hours:</string> |
There was a problem hiding this comment.
I love the design you did in this area! It's more intuitive to have the text be closer to the data it's representing.
| <property name="text"> | ||
| <string>Hours:</string> | ||
| </property> | ||
| <property name="minimumSize"> |
There was a problem hiding this comment.
Will check that in the timers_main_area.ui design. That one is fixed I think but this suggests it needs checking. (By comparison, I like the fact that I am not longer limited to only showing a fixed number of trigger items as I can drag the separator to show more or less as needed - it is just a case of ensuring realistic minimums. 😀 )
| addTimersMenuAction->setEnabled( true ); | ||
| connect( addTimersMenuAction, SIGNAL(triggered()), this, SLOT( slot_addTimer())); | ||
|
|
||
| QAction * addVarsMenuAction = new QAction( QIcon( QStringLiteral( ":/icons/chronometer.png" ) ), tr("Variables"), this); |
There was a problem hiding this comment.
Yeah, a side effect of using a QGridLayout and possibly cutting out separate nested layouts for the top and bottom halves of (the coloured bits of) vars_main_are.ui - I think the hidden-variable widgets are using 2 columns in the second (bottom) with the other two using one each, in the bottom row and the "Name:" label is using one on the top row with the QLineEdit display for the value of that taking up 3 columns...
I think I will have to resort (revert?) to two separate QHorizontalLayouts, one for each row, inside a QVerticalLayout for those rows.
| mpTimersMainArea = new dlgTimersMainArea(splitter_rightTopBottom); | ||
| mpAliasMainArea = new dlgAliasMainArea(splitter_rightTopBottom); | ||
| mpActionsMainArea = new dlgActionMainArea(splitter_rightTopBottom); | ||
| mpKeysMainArea = new dlgKeysMainArea(splitter_rightTopBottom); |
There was a problem hiding this comment.
Yes, I think that can be done. The one thing about using fixed sizes is for those pesky users of ultra high definition displays or if the Qt Library system uses a different size font for things - I've never fully traced how these things get decided and it does depend on the Desktop environment and the system wide settings I believe.
There was a problem hiding this comment.
It should not be a fixed size, but rather a Qt sizing property - remember those prefer/minimum/expanding. That will make it work with HiDPI displays, and other OS's. Remember not every OS uses the same sizes for widgets!
There was a problem hiding this comment.
I think that is the issue - to get a fixed size I think you need to say fixed but that gets messed up with different font sizes / display DPI - I'll have a closer look and see...
There was a problem hiding this comment.
No, I'm saying, it should not be a fixed size. Use Qt sizing hints instead.
| @@ -650,15 +517,12 @@ void dlgTriggerEditor::slot_viewStatsAction() | |||
|
|
|||
| void dlgTriggerEditor::slot_viewErrorsAction() | |||
There was a problem hiding this comment.
Agreed, I saw it as well but could not understand it. I think I will need to run it through GammaRay and see if I can identify what it is, probably a widget that should be hidden somewhere... 😕
|
By the way what tool are you using to capture animated. partial. screen shots ❓ |
|
It seems like an easier way to get a point across, seems to be working so far... |
|
Not sure of the status of this PR now - given that release_30 branch is technically frozen - I suspect I will need to cherry pick / rebase onto the development branch... |
|
Yep. |
|
When you get a moment, could you port the PR to |
…editor Uses a means documented in https://stackoverflow.com/a/21376774/4805858 to replace the "standard" data model for the QComboBox with one from the QListWidget which allows individual items to be flagged as disabled - which the standard QComboBox does not. This is designed to, in conjunction with a refactoring of code in dlgTriggerEditor::slot_var_selected(...) to prevent invalid choices to be made by the user (so types that they cannot enter through the Editor widget but which are included in the type QComboBox s for display purposes: functions for both and tables for one are disabled). I would like to hide the editor widget when functions and tables are selected in the tree widget - but that has proven to mess up the spacing and layout for the remaining visible widgets and will have to be left until I can bring: PR 436 "(release 30)bug fix get splitter working properly on editor right side" into a usable state: Mudlet#436 Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…1218) * Enhance: make editor search have optional case-sensitivity and clear Following on from #1096 I realised that the search capability was still not case sensitive and given that Lua is a case preserving language this struck me as a nuisance. It is now possible to configure this feature when searching. As we now have "boarder-outlines" around all the instances found in an element in a lua script component, we ought to have a means to removed them afterwards without having to click on another item and then return to the current one being considered. This commit also adds the built in clear button in the QLineEdit of the QComboBox that the search term is entered into which also clears the treeWidget_searchResults and also remove those border outlines. Clicking on a result in the search tree widget should put the focus (and the cursor) on the first (or selected term depending on case) within item. Moved several methods in dlgTriggerEditor from being declared as SLOTs when they are not so used: * (void) recursiveSearchTriggers(TTrigger*, const QString&) * (void) recursiveSearchAlias(TAlias*, const QString&) * (void) recursiveSearchScripts(TScript*, const QString&) * (void) recursiveSearchActions(TAction*, const QString&) * (void) recursiveSearchTimers(TTimer*, const QString&) * (void) recursiveSearchKeys(TKey*, const QString&) In that class I also renamed: * (void) recurseVariablesDown(TVar*, QList<TVar*>&, bool) ==> recursiveSearchVariables(TVar*, QList<TVar*>&, bool) because it had the same name as another function with a different signature but it is used in the same manner as the previously mentioned no longer SLOT methods. Also renamed in the same class was: * (void) slot_search_triggers(const QString) ==> slot_searchMudletItems(const QString&) because it is now used to search all item types not just "Triggers" as it may once have done! I added a couple of enums to the same class, both for use with the search functionality which this commit extends, the first is used to categorise the data elements that are stored in the first item in each row of the search results tree widget and the second (used as one type of the first) to identify which part of a particular "item" the search result relates to and thus how to process the stored data to goto the correct part of the editor display when/if that result is selected by the user. Elements were also renamed to try and be a bit more consistent across the different Mudlet "item" types: In "aliases" form/dialog: * (QLineEdit *) pattern_textedit ==> lineEdit_alias_pattern * (QComboBox *) comboBox ==> comboBox_alias_regex * (QLineEdit *) substitution ==> lineEdit_alias_command In "actions" (buttons/menus/toolbars) form/dialog: * (QCheckBox *) checkBox_pushdownbutton ==> checkBox_action_button_isPushDown * (QLineEdit *) lineEdit_command_down ==> lineEdit_action_button_command_down * (QLineEdit *) lineEdit_command_up ==> lineEdit_action_button_command_up * (QSpinBox *) buttonColumns ==> spinBox_action_bar_columns * (QPlainTextEdit *) css ==> plainTextEdit_action_css * (QComboBox *) comboBox_location ==> comboBox_action_bar_location * (QComboBox *) comboBox_orientation ==> comboBox_action_bar_orientation * (QComboBox *) buttonRotation ==> comboBox_action_button_rotation * (QLabel *) label_command_down ==> label_action_button_command_down * (QLabel *) label_command_up ==> label_action_button_command_up In "keys" form/dialog: * (QPushButton *) pushButton_grabKey ==> pushButton_key_grabKey * (QLineEdit *) lineEdit_command ==> lineEdit_key_command * (QLineEdit *) lineEdit_name ==> lineEdit_key_name * (QLineEdit *) lineEdit_key ==> lineEdit_key_binding In "scripts" form/dialog: * (QLineEdit *) lineEdit ==> lineEdit_script_event_handler_entry * (QListWidget *) listWidget_registered_event_handlers ==> listWidget_script_registered_event_handlers * (QToolButton *) toolButton_add ==> toolButton_script_add_event_handler * (QToolButton *) toolButton_remove ==> toolButton_script_remove_even_handler In "timer" form/dialog: * (QLineEdit *) lineEdit_command ==> lineEdit_timer_command * (QTimeEdit *) timeEdit_hours ==> timeEdit_timer_hours * (QTimeEdit *) timeEdit_minutes ==> timeEdit_timer_minutes * (QTimeEdit *) timeEdit_seconds ==> timeEdit_timer_seconds * (QTimeEdit *) timeEdit_msecs ==> timeEdit_timer_msecs In "trigger pattern" form/dialog: * (QComboBox) patternType ==> comboBox_patternType * (QPushButton) fgB ==> pushButton_fgColor * (QPushButton) bgB ==> pushButton_bgColor * (QLabel) number ==> label_patternNumber In "variables" form/dialog: * (QCheckBox *) hideVariable ==> checkBox_variable_hidden * (QComboBox *) key_type ==> comboBox_variable_key_type * (QComboBox *) var_type ==> comboBox_variable_value_type Note that in the above SOME other elements that are not used in a programmatic way (e.g. some label identifiers or layout or container type widgets) have also been renamed in a similar way. Also: * The layout of the Timer editor has been "improved" and also now reports the milli-seconds in "zzz" format rather than "z" so that it is more obvious that the number is thousandths of a second and can range from "000" to "999". * The patterns in the trigger part of the editor are now numbered in a more human-friendly 1 to 50 instead of the previous 0 to 49. * When a different trigger is selected the pattern widget is scrolled so that the highest used pattern number is in view. * The search process now also searches: the "name" field for all items and where relevant the "command" fields of "actions", "aliases", "keys", "timers" and "triggers" {including the "command (up)}" for "buttons" and the "Css"/"Stylesheet" field for "buttons"/"menus"/"buttons" and the "Events handled" for "Scripts" and the "pattern" field for "aliases". * Searching on fields that are multi-line (the Lua scripts for all but "variables"; the "Css/Stylesheet" for "buttons"/"menus"/"buttons") or multi-element ("trigger" patterns) indicate the line/column of the start of the search term or pattern number respectively in the "What" column of the search results. A tweak has been included that disables some items on the key and value QComboBoxs in the "Variable" part of the editor, this uses a means documented in https://stackoverflow.com/a/21376774/4805858 to replace the "standard" data model for the QComboBox with one from the QListWidget which allows individual items to be flagged as disabled - which the standard QComboBox does not. This is designed to, in conjunction with a refactoring of code in dlgTriggerEditor::slot_var_selected(...) to prevent invalid choices to be made by the user (so types that they cannot enter through the Editor widget but which are included in the type QComboBox s for display purposes: functions for both and tables for one are disabled). I would like to hide the editor widget when functions and tables are selected in the tree widget - but that has proven to mess up the spacing and layout for the remaining visible widgets and will have to be left until I can bring: PR 436 "(release 30)bug fix get splitter working properly on editor right side" into a usable state: #436 I have reordered all QGridLayout constructs in the "touched" dialog/forms in strict ascending column & row (columns first) order - as Qt Form designer does not currently enforce this but it increases Git noise in them. Also have edited tooltip for hidden variable to match new form of hidden variables control. Part way through the evolution of this (squashed down to a single) commit it was decided to revised the search to be an options menu with space for additional options. The mechanism now behaves very like the Qt Creator's own search options which are presented as a clickable menu at the start of the search term QLineEdit part of the editable QComboBox. At present only Case Sensitivity is supported but it will be possible to add additional search options - the most likely being whole word and regular expression type searches. As the QtCreator inspiration does different icons are shown depending on the options enabled on the menu that is displayed is clicked (and encoded into the new enum/QFlags "SearchOptions" which is stored in dlgTriggerEditor::mSearchOptions). As new options are coded extra icons that support all the combinations will be needed (although if a combination is not provided with an icon) the grey binoculars icon that is used when no option is set is replaced with a red one to indicate something is enabled and modifying the search behaviour. Also currently the options chosen are NOT stored against the search terms that get stored into the search term QComboBox - it might be wanted to store the search options chosen as part of each search term (use a item::data for that) so they can be restore if an existing term is reused... Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…1218) * Enhance: make editor search have optional case-sensitivity and clear Following on from #1096 I realised that the search capability was still not case sensitive and given that Lua is a case preserving language this struck me as a nuisance. It is now possible to configure this feature when searching. As we now have "boarder-outlines" around all the instances found in an element in a lua script component, we ought to have a means to removed them afterwards without having to click on another item and then return to the current one being considered. This commit also adds the built in clear button in the QLineEdit of the QComboBox that the search term is entered into which also clears the treeWidget_searchResults and also remove those border outlines. Clicking on a result in the search tree widget should put the focus (and the cursor) on the first (or selected term depending on case) within item. Moved several methods in dlgTriggerEditor from being declared as SLOTs when they are not so used: * (void) recursiveSearchTriggers(TTrigger*, const QString&) * (void) recursiveSearchAlias(TAlias*, const QString&) * (void) recursiveSearchScripts(TScript*, const QString&) * (void) recursiveSearchActions(TAction*, const QString&) * (void) recursiveSearchTimers(TTimer*, const QString&) * (void) recursiveSearchKeys(TKey*, const QString&) In that class I also renamed: * (void) recurseVariablesDown(TVar*, QList<TVar*>&, bool) ==> recursiveSearchVariables(TVar*, QList<TVar*>&, bool) because it had the same name as another function with a different signature but it is used in the same manner as the previously mentioned no longer SLOT methods. Also renamed in the same class was: * (void) slot_search_triggers(const QString) ==> slot_searchMudletItems(const QString&) because it is now used to search all item types not just "Triggers" as it may once have done! I added a couple of enums to the same class, both for use with the search functionality which this commit extends, the first is used to categorise the data elements that are stored in the first item in each row of the search results tree widget and the second (used as one type of the first) to identify which part of a particular "item" the search result relates to and thus how to process the stored data to goto the correct part of the editor display when/if that result is selected by the user. Elements were also renamed to try and be a bit more consistent across the different Mudlet "item" types: In "aliases" form/dialog: * (QLineEdit *) pattern_textedit ==> lineEdit_alias_pattern * (QComboBox *) comboBox ==> comboBox_alias_regex * (QLineEdit *) substitution ==> lineEdit_alias_command In "actions" (buttons/menus/toolbars) form/dialog: * (QCheckBox *) checkBox_pushdownbutton ==> checkBox_action_button_isPushDown * (QLineEdit *) lineEdit_command_down ==> lineEdit_action_button_command_down * (QLineEdit *) lineEdit_command_up ==> lineEdit_action_button_command_up * (QSpinBox *) buttonColumns ==> spinBox_action_bar_columns * (QPlainTextEdit *) css ==> plainTextEdit_action_css * (QComboBox *) comboBox_location ==> comboBox_action_bar_location * (QComboBox *) comboBox_orientation ==> comboBox_action_bar_orientation * (QComboBox *) buttonRotation ==> comboBox_action_button_rotation * (QLabel *) label_command_down ==> label_action_button_command_down * (QLabel *) label_command_up ==> label_action_button_command_up In "keys" form/dialog: * (QPushButton *) pushButton_grabKey ==> pushButton_key_grabKey * (QLineEdit *) lineEdit_command ==> lineEdit_key_command * (QLineEdit *) lineEdit_name ==> lineEdit_key_name * (QLineEdit *) lineEdit_key ==> lineEdit_key_binding In "scripts" form/dialog: * (QLineEdit *) lineEdit ==> lineEdit_script_event_handler_entry * (QListWidget *) listWidget_registered_event_handlers ==> listWidget_script_registered_event_handlers * (QToolButton *) toolButton_add ==> toolButton_script_add_event_handler * (QToolButton *) toolButton_remove ==> toolButton_script_remove_even_handler In "timer" form/dialog: * (QLineEdit *) lineEdit_command ==> lineEdit_timer_command * (QTimeEdit *) timeEdit_hours ==> timeEdit_timer_hours * (QTimeEdit *) timeEdit_minutes ==> timeEdit_timer_minutes * (QTimeEdit *) timeEdit_seconds ==> timeEdit_timer_seconds * (QTimeEdit *) timeEdit_msecs ==> timeEdit_timer_msecs In "trigger pattern" form/dialog: * (QComboBox) patternType ==> comboBox_patternType * (QPushButton) fgB ==> pushButton_fgColor * (QPushButton) bgB ==> pushButton_bgColor * (QLabel) number ==> label_patternNumber In "variables" form/dialog: * (QCheckBox *) hideVariable ==> checkBox_variable_hidden * (QComboBox *) key_type ==> comboBox_variable_key_type * (QComboBox *) var_type ==> comboBox_variable_value_type Note that in the above SOME other elements that are not used in a programmatic way (e.g. some label identifiers or layout or container type widgets) have also been renamed in a similar way. Also: * The layout of the Timer editor has been "improved" and also now reports the milli-seconds in "zzz" format rather than "z" so that it is more obvious that the number is thousandths of a second and can range from "000" to "999". * The patterns in the trigger part of the editor are now numbered in a more human-friendly 1 to 50 instead of the previous 0 to 49. * When a different trigger is selected the pattern widget is scrolled so that the highest used pattern number is in view. * The search process now also searches: the "name" field for all items and where relevant the "command" fields of "actions", "aliases", "keys", "timers" and "triggers" {including the "command (up)}" for "buttons" and the "Css"/"Stylesheet" field for "buttons"/"menus"/"buttons" and the "Events handled" for "Scripts" and the "pattern" field for "aliases". * Searching on fields that are multi-line (the Lua scripts for all but "variables"; the "Css/Stylesheet" for "buttons"/"menus"/"buttons") or multi-element ("trigger" patterns) indicate the line/column of the start of the search term or pattern number respectively in the "What" column of the search results. A tweak has been included that disables some items on the key and value QComboBoxs in the "Variable" part of the editor, this uses a means documented in https://stackoverflow.com/a/21376774/4805858 to replace the "standard" data model for the QComboBox with one from the QListWidget which allows individual items to be flagged as disabled - which the standard QComboBox does not. This is designed to, in conjunction with a refactoring of code in dlgTriggerEditor::slot_var_selected(...) to prevent invalid choices to be made by the user (so types that they cannot enter through the Editor widget but which are included in the type QComboBox s for display purposes: functions for both and tables for one are disabled). I would like to hide the editor widget when functions and tables are selected in the tree widget - but that has proven to mess up the spacing and layout for the remaining visible widgets and will have to be left until I can bring: PR 436 "(release 30)bug fix get splitter working properly on editor right side" into a usable state: #436 I have reordered all QGridLayout constructs in the "touched" dialog/forms in strict ascending column & row (columns first) order - as Qt Form designer does not currently enforce this but it increases Git noise in them. Also have edited tooltip for hidden variable to match new form of hidden variables control. Part way through the evolution of this (squashed down to a single) commit it was decided to revised the search to be an options menu with space for additional options. The mechanism now behaves very like the Qt Creator's own search options which are presented as a clickable menu at the start of the search term QLineEdit part of the editable QComboBox. At present only Case Sensitivity is supported but it will be possible to add additional search options - the most likely being whole word and regular expression type searches. As the QtCreator inspiration does different icons are shown depending on the options enabled on the menu that is displayed is clicked (and encoded into the new enum/QFlags "SearchOptions" which is stored in dlgTriggerEditor::mSearchOptions). As new options are coded extra icons that support all the combinations will be needed (although if a combination is not provided with an icon) the grey binoculars icon that is used when no option is set is replaced with a red one to indicate something is enabled and modifying the search behaviour. Also currently the options chosen are NOT stored against the search terms that get stored into the search term QComboBox - it might be wanted to store the search options chosen as part of each search term (use a item::data for that) so they can be restore if an existing term is reused... Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
@SlySven can we close this PR? Code will still be in your branch. |
|
I guess so - I only left it as a nagging reminder to me to get it done - which I did have a go at recently but did not complete as there was one or two niggling details that I did not get fully sorted but which I was going back to after the GUI Translations PR and possibly the issue of non-ASCII selection/display in |






This PR reworks the Editor so that the parts on the right hand size can be better resized dynamically in the splitter widget that now encompasses the entire right side of the screen. I think it is more user friendly and allows better use of various amounts of screen real estate - for instance with a large screen you can now expand the proportion of the list of triggers shown to show more than 6 at a time, and for Toolbars/Menu/Buttons you can adjust the vertical space allocated to CSS (now relabelled "Style-sheet:") and to the lua script editor (now labelled "Lua code:").
As a side effect It also cleans up the
dlgTriggerEditorconstructor considerably as it rips out the instantiation code for all the widgets of the right side of the editor together with the manual code that contradicts or at least contents with the settings in the .ui files - now theQSplittercan do all that it is supposed to.Also ALL of the Alias/Action/Key/Script/Timer/Trigger/Variable displays have a uniform "Name:" and Alias/Action/Key/Timer/Triggers (thought Actions sometimes needs two) - they all have the same "Command:" entry for the text to send directly to the MUD server on activation.
Whilst it is not essential to get this into the release I think it is of benefit - it could improve that large screen/high resolution user's issue with parts of the trigger widget disappearing due to a lack of space for it (I found that some of the widgets were not sized very well.)