Skip to content

(release 30)bug fix get splitter working properly on editor right side#436

Closed
SlySven wants to merge 5 commits intoMudlet:release_30from
SlySven:(release_30)BugFix_getSplitterWorkingProperlyOnEditorRightSide
Closed

(release 30)bug fix get splitter working properly on editor right side#436
SlySven wants to merge 5 commits intoMudlet:release_30from
SlySven:(release_30)BugFix_getSplitterWorkingProperlyOnEditorRightSide

Conversation

@SlySven
Copy link
Copy Markdown
Member

@SlySven SlySven commented Mar 23, 2017

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 dlgTriggerEditor constructor 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 the QSplittercan 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.)

@SlySven SlySven self-assigned this Mar 23, 2017
@SlySven SlySven requested a review from vadi2 March 23, 2017 19:51
@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Mar 23, 2017

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.

@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Mar 24, 2017

⚠️ Weird Travis CI failure - all four builds using it (i.e. both those for Linux and MacOS) failed to find the boost libraries at compile time - though they were successfully updated to 1.55 from the default (broken) mix of 1.46 & 1.48 on the Linux side and the latest 1.63 on the MacOS side during the setup-phase. 😖

@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Mar 24, 2017

Um, whoops, it seems I only included the first change to the src/CMakeLists.txt to update the headers and did not stage the actual business of the deletion of the deleted files previous listed therein. Let me find go and find a fresh wall I can bang my head against! 🤕

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Mar 24, 2017

Save some space for The Merge.

Which is our next task at hand... time to freeze accepting PRs to development and release_30... for better or worse given how branch freezes went over wonderfully for us? Let's discuss on Gitter.

SlySven added 5 commits March 25, 2017 01:23
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>
@SlySven SlySven force-pushed the (release_30)BugFix_getSplitterWorkingProperlyOnEditorRightSide branch from d1f0008 to bfd341b Compare March 25, 2017 01:28
Copy link
Copy Markdown
Member

@vadi2 vadi2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

</property>
<property name="text">
<string>Substitution:</string>
<string>Command:</string>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QVBoxLayout * pVB1 = new QVBoxLayout(mainArea);

// Replacement code to use single splitter for all right widgets:
mpSystemMessageArea = new dlgSystemMessageArea(splitter_rightTopBottom);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty awesome! I'd like to request a few aesthetic changes. I don't know where to put the comments for the UI itself, it's less obvious than code, so forgive that this isn't the right place.

Could the 2.1 tooltip size be restored for when there are no elements:

selection_008

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In all other cases too, the minimum size got larger and looks out of place now:

selection_023

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the bottom line sounds good.

Regarding parsing: no need! QString::toHtmlEscaped().

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 👂

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keneanung what's your take on adding this?

<item row="0" column="0">
<widget class="QLabel" name="label_hours">
<property name="text">
<string>Hours:</string>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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">
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bit of a squish happening, need those minimums:

selection_024

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bit of extra space after variable name:

selection_025

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could keys sizing be limited in the same way aliases is limited, as there's no need to expand it?

peek 2017-03-26 11-13

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit weird - but see for yourself - there's a white rectangle that shows up if the errors view is of a certain width:

peek 2017-03-26 11-16

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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... 😕

@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Mar 26, 2017

By the way what tool are you using to capture animated. partial. screen shots ❓

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Mar 26, 2017

https://github.com/phw/peek

It seems like an easier way to get a point across, seems to be working so far...

@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Mar 29, 2017

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...

@SlySven SlySven added On Hold PR on hold pending further discussion or other incident. and removed 1 - Ready labels Mar 29, 2017
@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Mar 29, 2017

Yep.

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Apr 25, 2017

When you get a moment, could you port the PR to development? Need to delete the release_30 branch as it is still causing mild amounts of confusion.

SlySven added a commit to SlySven/Mudlet that referenced this pull request Jul 11, 2017
…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>
SlySven added a commit that referenced this pull request Jul 23, 2017
…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>
vadi2 pushed a commit that referenced this pull request Aug 6, 2017
…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>
This was referenced Oct 14, 2017
@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Dec 6, 2017

@SlySven can we close this PR? Code will still be in your branch.

@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Dec 6, 2017

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 TConsoles...

@SlySven SlySven closed this Dec 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

On Hold PR on hold pending further discussion or other incident.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants