AutoEntry blocked while typing #110

Closed
jacobthetechy opened this Issue Mar 10, 2017 · 12 comments

Comments

Projects
None yet
3 participants
@jacobthetechy
Contributor

jacobthetechy commented Mar 10, 2017

When you start typing into the entry field of a autoentry the entry box is blocked an you cant see what your typing. Is there a possibility of offsetting there the words are shown so you can see the entry box?

*edit:
This is only an issue if the entry is at the bottom of the window

@jarvisteach jarvisteach self-assigned this Mar 11, 2017

@jarvisteach jarvisteach added the bug label Mar 11, 2017

@jarvisteach jarvisteach added this to the 0.06 milestone Mar 11, 2017

@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Mar 11, 2017

Owner

Upon a quick investigation (on OSX, with python 2.7 & 3.4), I don't quite see the issue you mention. The entryBox is always visible, but the drop-down of options gets hidden?

app = gui()
options=["apple", "ape", "apricot", "applause", "add", "address", "adept"]
app.addAutoEntry('Entry', options)
app.setFocus('Entry')
app.go()

Is this what you mean? Or, are you saying that the entryBox gets covered by the options drop-down?

Either way, I think the issues are related...

The drop-down is simply a listBox widget that is (meant to be) temporarily shown over the top of the widgets beneath the entry box.

It can't exists outside the bounds of the appJar window. So, if there's no space to show it under the entryBox (in OSX at least), then it gets hidden. I'll investigate in Windows, to see if there is different behaviour (with it being drawn over the top of the entry box?).

One solution is to always ensure you have space underneath the entry, to show the drop-down.

An extra feature, could be to have the listBox appear above the entry if necessary (& possible) - this may not involve too much re-engineering...

An alternative feature would be to make the window extend to accommodate the listBox. Again, not too hard, but perhaps better left up to the developer to decide on window size?

Other than those three options, I don't really see a solution. I don't think a widget can exist outside the bounds of the tkinter window? And I don't think spawning an extra window to show the options would work well enough (or look good enough) to be worth the effort.

I need to investigate in Windows first, to see what the behaviour is...

Owner

jarvisteach commented Mar 11, 2017

Upon a quick investigation (on OSX, with python 2.7 & 3.4), I don't quite see the issue you mention. The entryBox is always visible, but the drop-down of options gets hidden?

app = gui()
options=["apple", "ape", "apricot", "applause", "add", "address", "adept"]
app.addAutoEntry('Entry', options)
app.setFocus('Entry')
app.go()

Is this what you mean? Or, are you saying that the entryBox gets covered by the options drop-down?

Either way, I think the issues are related...

The drop-down is simply a listBox widget that is (meant to be) temporarily shown over the top of the widgets beneath the entry box.

It can't exists outside the bounds of the appJar window. So, if there's no space to show it under the entryBox (in OSX at least), then it gets hidden. I'll investigate in Windows, to see if there is different behaviour (with it being drawn over the top of the entry box?).

One solution is to always ensure you have space underneath the entry, to show the drop-down.

An extra feature, could be to have the listBox appear above the entry if necessary (& possible) - this may not involve too much re-engineering...

An alternative feature would be to make the window extend to accommodate the listBox. Again, not too hard, but perhaps better left up to the developer to decide on window size?

Other than those three options, I don't really see a solution. I don't think a widget can exist outside the bounds of the tkinter window? And I don't think spawning an extra window to show the options would work well enough (or look good enough) to be worth the effort.

I need to investigate in Windows first, to see what the behaviour is...

@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Mar 11, 2017

Owner

One other thought, would be to limit/configure the number of rows in the drop-down? appJar could try to identify how many rows to show, or the user could specify if they know they have space constraints...

Owner

jarvisteach commented Mar 11, 2017

One other thought, would be to limit/configure the number of rows in the drop-down? appJar could try to identify how many rows to show, or the user could specify if they know they have space constraints...

@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Mar 11, 2017

Owner

appJar uses winfo_height() combined with winfo_y() (in the makeListBox function) to determine where to place the listBox. Do these work on Windows? Might need to look at winfo_reqheight() ??

Owner

jarvisteach commented Mar 11, 2017

appJar uses winfo_height() combined with winfo_y() (in the makeListBox function) to determine where to place the listBox. Do these work on Windows? Might need to look at winfo_reqheight() ??

@jacobthetechy

This comment has been minimized.

Show comment
Hide comment
@jacobthetechy

jacobthetechy Mar 11, 2017

Contributor

Or, are you saying that the entryBox gets covered by the options drop-down?

Yes this is what I was seeing. I realize this was due in part to my negligence in not realizing I was making such a small window and expecting the window to resize when the options appeared.

An extra feature, could be to have the listBox appear above the entry if necessary (& possible) - this may not involve too much re-engineering...

I believe this would be a better solution for aesthetics.

My thoughts on the behavior on the AutoEntry. It should look like and EntryBox and OptionBox combination. As you type it only show matches (just as it does now), but also have the drop down for selection. You should also be able to pass a max number of rows to be shown with the ability to scroll through all the options.

Or create a new type of entry called addEntryListBox() where this behavior available.

Either way the OptionBox needs to have some way to limit the number of rows being displayed. The DatePicker would benefit from this as well. That way it would not show 31 options and take up most of the screen/window when selecting a date.

Contributor

jacobthetechy commented Mar 11, 2017

Or, are you saying that the entryBox gets covered by the options drop-down?

Yes this is what I was seeing. I realize this was due in part to my negligence in not realizing I was making such a small window and expecting the window to resize when the options appeared.

An extra feature, could be to have the listBox appear above the entry if necessary (& possible) - this may not involve too much re-engineering...

I believe this would be a better solution for aesthetics.

My thoughts on the behavior on the AutoEntry. It should look like and EntryBox and OptionBox combination. As you type it only show matches (just as it does now), but also have the drop down for selection. You should also be able to pass a max number of rows to be shown with the ability to scroll through all the options.

Or create a new type of entry called addEntryListBox() where this behavior available.

Either way the OptionBox needs to have some way to limit the number of rows being displayed. The DatePicker would benefit from this as well. That way it would not show 31 options and take up most of the screen/window when selecting a date.

jarvisteach added a commit that referenced this issue Apr 10, 2017

Configurable number of rows in AutoEntry (#110)
New function `.setAutoEntryNumRows(title, rows)` to set how many rows
to display in an AutoEntry
@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Apr 10, 2017

Owner

OK - added feature to limit the number of rows.
Still need to investigate positioning in windows.
Will split out ideas to scroll up, addEntryListBox() & modify date picker as new feature requests.

Owner

jarvisteach commented Apr 10, 2017

OK - added feature to limit the number of rows.
Still need to investigate positioning in windows.
Will split out ideas to scroll up, addEntryListBox() & modify date picker as new feature requests.

@lieuzhenghong

This comment has been minimized.

Show comment
Hide comment
@lieuzhenghong

lieuzhenghong Apr 11, 2017

In my opinion, the option box shouldn't be visible when the field is not in focus. Is this intended behaviour? @jarvisteach @jacobthetechy

Not in focus
image

In focus
image

After an entry is filled in, it's fine.
image

lieuzhenghong commented Apr 11, 2017

In my opinion, the option box shouldn't be visible when the field is not in focus. Is this intended behaviour? @jarvisteach @jacobthetechy

Not in focus
image

In focus
image

After an entry is filled in, it's fine.
image

@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Apr 11, 2017

Owner

@lieuzhenghong - this is definitely not intended behaviour!

It's also not the behaviour I see on OSX (10.11.6) python 2.7.13 & 3.6.1 or Linux(Raspbian) python 2.7.9 or 3.4.2. What platform, version of python, version of appJar are you running?

In appJar, the FocusOut event is bound to .closeList() - so the moment focus leaves the Entry, the listBox should be destroyed...

Equally, showing the list box is bound to a trace on the textVar, so it should only be visible when at least one character is present in the entry or the arrow keys are pressed...

Can you try out one of my test programs: https://github.com/jarvisteach/appJar/blob/appJar/examples/1_autoEntry.py

The 1st & 7th entries are AutoEntries...

Owner

jarvisteach commented Apr 11, 2017

@lieuzhenghong - this is definitely not intended behaviour!

It's also not the behaviour I see on OSX (10.11.6) python 2.7.13 & 3.6.1 or Linux(Raspbian) python 2.7.9 or 3.4.2. What platform, version of python, version of appJar are you running?

In appJar, the FocusOut event is bound to .closeList() - so the moment focus leaves the Entry, the listBox should be destroyed...

Equally, showing the list box is bound to a trace on the textVar, so it should only be visible when at least one character is present in the entry or the arrow keys are pressed...

Can you try out one of my test programs: https://github.com/jarvisteach/appJar/blob/appJar/examples/1_autoEntry.py

The 1st & 7th entries are AutoEntries...

@lieuzhenghong

This comment has been minimized.

Show comment
Hide comment
@lieuzhenghong

lieuzhenghong Apr 11, 2017

@jarvisteach Yours looks fine for me. I am using Python 3.5.2+, Ubuntu 16.10,
pip3 show appjar
Name: appJar
Version: 0.52
Summary: A GUI wrapper for tkinter
Home-page: http://appJar.info
Author: Richard Jarvis
Author-email: info@appjar.info
License: UNKNOWN
Location: /usr/local/lib/python3.5/dist-packages
Requires:

image

Here's my code sample.

lieuzhenghong commented Apr 11, 2017

@jarvisteach Yours looks fine for me. I am using Python 3.5.2+, Ubuntu 16.10,
pip3 show appjar
Name: appJar
Version: 0.52
Summary: A GUI wrapper for tkinter
Home-page: http://appJar.info
Author: Richard Jarvis
Author-email: info@appjar.info
License: UNKNOWN
Location: /usr/local/lib/python3.5/dist-packages
Requires:

image

Here's my code sample.

@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Apr 11, 2017

Owner

Interesting - I narrowed it down to the line of code causing the bug:
It's app.setEntryDefault('email', 'email address')

Can you confirm removing that line fixes the issue?

Owner

jarvisteach commented Apr 11, 2017

Interesting - I narrowed it down to the line of code causing the bug:
It's app.setEntryDefault('email', 'email address')

Can you confirm removing that line fixes the issue?

@lieuzhenghong

This comment has been minimized.

Show comment
Hide comment
@lieuzhenghong

lieuzhenghong Apr 11, 2017

@jarvisteach Yep, removing that line fixes the issue!

lieuzhenghong commented Apr 11, 2017

@jarvisteach Yep, removing that line fixes the issue!

@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Apr 11, 2017

Owner

OK, for now - remove the default for the AutoEntry
I can see why it breaks - just need to fix it.
Have raised a new issue...

Owner

jarvisteach commented Apr 11, 2017

OK, for now - remove the default for the AutoEntry
I can see why it breaks - just need to fix it.
Have raised a new issue...

@jarvisteach

This comment has been minimized.

Show comment
Hide comment
@jarvisteach

jarvisteach Apr 11, 2017

Owner

The issue has been resolved for the next release

Owner

jarvisteach commented Apr 11, 2017

The issue has been resolved for the next release

jarvisteach added a commit that referenced this issue Apr 23, 2017

updates to googleMaps (#136). Including getLocation() function to det…
…ermine currentLocation. Also added <Escape> to AutoEntry (#110). And added new exception() function for logging (#124)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment