Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#19 closed enhancement (fixed)

Dropdown menu behaviour

Reported by: Samir Hawamdeh Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2014R3
Component: Calltips.mcc Version: 4.0-2014R2
Severity: minor Keywords:
Cc: Roman Kargin OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

On the main interface of Odyssey if you type somethings into the quick search area (or even into the search field) at some point a drop menu will be opened with the classic "suggested words" (hints) or urls in history in case instead you select the main search field

All is fine of course, however if you decide to close that drop menu, for example clicking on other area of the program —> and then for example you iconify OWB —> when you reopen OWB that drop menu will be reopened automatically and it cannot be closed at 100% until you quit OWB

This behaviour is a bit annoying because the drop menu will steal the focus so after you have used it once, then if that will be "unintentionally" reopened you cannot click on any other areas..

See post:
http://www.amigans.net/modules/xforum/viewtopic.php?post_id=87669#forumpost87669

Kas1e suggested that the only method to close them for real is to hit "Enter" in that search fields, or press into that search gadget.

He also add:
"Its the same with URL search window for example: try to write something in when history will spawns, then dbl-click on main owb window: history window will looks like closed, but its not, its just under main window as you make it inactive."

I wonder if you can add an option in MUI4 to make this behaviour as optional, so we can decide how that drop menu should be closed (only after a user's keypress, in this case the "Enter" key) or even if users will just leave the area selecting (clicking) into another area of the program

Attachments (3)

glitch.png (1.3 MB) - added by Samir Hawamdeh 6 years ago.
Crashlog_OWB_2014-03-15_21-44-42.txt (25.0 KB) - added by Samir Hawamdeh 6 years ago.
Crashlog_OWB_2014-03-16_08-14-23.txt (24.6 KB) - added by Samir Hawamdeh 6 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 6 years ago by Thore Böckelmann

Component: undefinedCalltips.mcc
Milestone: MUI 4.0-2014R3
Priority: undecidednormal
Status: newaccepted

comment:2 Changed 6 years ago by Thore Böckelmann

In 3316:

  • mcc/Calltips.c: fixed the GUI lockup in case the application was uniconified with a Calltips object being opened. This refs #19.

comment:3 Changed 6 years ago by Thore Böckelmann

Cc: Roman Kargin added
Owner: set to Thore Böckelmann
Status: acceptedassigned

The lockup is fixed now. The calltips window will be fully restored after the uniconification.

Roman, how does Calltips.mcc behave on MorphOS when the source object's window becomes deactivated? Is it closed then or does it stay visible until the user eventually selects an item from the list or presses Return in the string object?

comment:4 Changed 6 years ago by Roman Kargin

Thore,

Yes, there was indeed lockup in the calltips class (on morphos, when you have calltips window, and then you iconify main app, and uniconify it back, it then respawn main app with opened calltip window (i.e. the same as it was when you do iconify). On our current one when we press iconify, it lockup main window, and after a while DSI.

Through you already fix it as i see.

Roman, how does Calltips.mcc behave on MorphOS when the source object's window becomes deactivated? Is it closed then or does it stay visible until the user eventually selects an item from the list or presses Return in the string object?

If you click outside of the calltips window somewhere on main window, its auto-closes.

As for whole Samo's report, i not so understand what he trying to say. Because for me, when i just type anything in the quicksearch window, and it show me dropdown menu, and then i iconify it , and iconify it back , then it of course restored. And then, if i want to close it, i need to press on any other buttons/area/etc in the odyssey and continue to use it.

comment:5 in reply to:  4 ; Changed 6 years ago by Thore Böckelmann

Replying to kas1e:

Roman, how does Calltips.mcc behave on MorphOS when the source object's window becomes deactivated? Is it closed then or does it stay visible until the user eventually selects an item from the list or presses Return in the string object?

If you click outside of the calltips window somewhere on main window, its auto-closes.

Does it reopen itself again when you type something more in the string object? Or does it stay closed? It is easy to make the window close automatically, but since it is the application's task to open the window there is no easy way to reopen it consistently.

comment:6 Changed 6 years ago by Thore Böckelmann

In 3320:

  • mcc/Calltips.c: close the calltips window automatically in case it becomes inactive. This refs #19.

comment:7 in reply to:  5 Changed 6 years ago by Roman Kargin

Does it reopen itself again when you type something more in the string object? Or does it stay closed? It is easy to make the window close automatically, but since it is the application's task to open the window there is no easy way to reopen it consistently.

On mos it reacts like this:

  1. we go to some string where calltips will deal with
  2. type something to bring dropdown menu
  3. press on owb window outside of that dropdown menu (so it disappear/auto-closes)
  4. if we type something again in that string where we type before, its react the same as if it was closed, and opens as fresh one. I.e. if we only make string active, nothing popups. If we type anything after letter we type which didn't contain what could spawn drop-down menu: nothing spawns.

For example:

I.e. if we have in string "admin" word , and type there "a": then drop-down menu spawns. We then click outside of window to some other place in owb main window, and it closes. Then, when we make string active, we still have our "a", and cursor stays right after. But nothing spawns. If we type now "d", then drop-down menu spawns. If , instead of "d" we type antyhing else (i.e. which will not make "admin" word) , then nothing spawns.

comment:8 Changed 6 years ago by Thore Böckelmann

According to some private mails of Roman this issue is fixed.

comment:9 Changed 6 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

comment:10 Changed 6 years ago by Samir Hawamdeh

@Thore & Kas1e

Sorry guys but i think we should reopen this one because the current behaviour doesn't resolve the problem at 100% and can create other potential issues

Actually if you didn't press "Enter" once you have opened (spawned) a drop-down menu after typing, then if you iconify OWB that menu will be spawned again

At the end you might consider it as a normal behaviour, however it would be better to NOT spawn any more the drop-down menu, atleast in case you have reopened a program after an iconification.

An example of a potential issue:

I did a simple stability test spawning all the dropdown menu of OWB (without pressing Enter on any of them) then i iconify OWB

When i deiconify the program i found all the drop-down menu opened, so i just moving the OWB window around the screen, at this condition most of the time the drop-down menu will followed the new position and size of the program's window, however at some point a problem heppen —> see grab attached

When this graphical glitch happen, i closed OWB and i got a couple of different crashes —> see the 2 crashlogs attached

So to conclude can say we have 2 different but related issues:

  • Spawned drop-down menus should be really closed automatically after you click elsewhere and NOT ONLY after you jave press "Enter"
  • We have some stability issues when such spawned drop-down menu are opened and we try to move/resize the program window around the screen

Changed 6 years ago by Samir Hawamdeh

Attachment: glitch.png added

Changed 6 years ago by Samir Hawamdeh

Changed 6 years ago by Samir Hawamdeh

comment:11 Changed 6 years ago by Roman Kargin

@samo

Sorry its all again wrong.

Actually if you didn't press "Enter" once you have opened (spawned) a drop-down menu after typing, then if you iconify OWB that menu will be spawned again

I told you many times (really many, and on amigans, and everywhere) : that how it done originally by Fab ! It spawned because it didn't closed ! If you spawn it, and press on the main owb window or any other place, then spawned window not closed , it just jumps under the main window, and it still here (i say it many times), and when you do iconify back, it of course showup itself because it didn't closes.

Top line: fab do it like this. When you press enter , window indeed closes. When you didn't ,but make other window be active, then that one just jump under the main one and you didn't see it. And that not glitch. Its 2 different windowses.

Yes, that annoing, but that how it done by Fab. Ask him to make it different.

I.e. the way how history and quick search windwoses done (and that they dind't auto-closes), done like this in code of odyssey (and i say it few times before to you). What it mean is:

  1. There nothing to fix in mui.
  2. If you have problems with how urlhistory window and quicksearch window handles write to Fab.

The only "autoclose" happens in new autoform filling, but that new in 1.23, and not in 1.16. Ask Fab and write him why he do url-history and quick-search window don't be autoclosed when user press outside of it.

And crashes which you have, related to the odyssey again and not to mui. You can see in crashlog its all about "removeclibboardhook". So that bz to me, write plz it on bugs.os4depot.net with 100% step-by-step guide of how to reproduce that crashes on exit.

And i have a suggestion as you seems like to do all kind of tests: Just buy a second hand mac for few buks, install mos with latest odyssey, and so you will have ability to see where is bugs in mui, and where is problems with odyssey itself, and if it is problems with odyssey itself or with port on os4. Because as it now, you mess everything in one piece, and mui bugs, and how odyssey done by fab, and porting bugs.

Last edited 6 years ago by Roman Kargin (previous) (diff)

comment:12 Changed 6 years ago by Thore Böckelmann

Roman is right. As long as the crash eventually happens inside Odyssey code there is nothing I can do in MUI.

If it is really possible to let the popup window appear below the browser window in a reproducable fashion then please open a new ticket for that issue with a step by step instruction.

comment:13 Changed 6 years ago by Samir Hawamdeh

@kas1e

I told you many times (really many, and on amigans, and everywhere) : that
how it done originally by Fab ! It spawned because it didn't closed ! If you > spawn it, and press on the main owb window or any other place, then spawned
window not closed , it just jumps under the main window, and it still here (i > say it many times), and when you do iconify back, it of course showup itself > because it didn't closes.

Mate you don't need to get angry, similarly to how we did previously for the shortcuts I thought we could override this behavior (atleast optionally) directly through our MUI4, but if not that's ok ..
You say ask Fab directly, yes this is part of the problem because i already mailed him but then he never replied.

Top line: fab do it like this. When you press enter , window indeed closes. When > you didn't ,but make other window be active, then that one just jump under the
main one and you didn't see it. And that not glitch. Its 2 different windowses.

Roman I know, the glitch i was referring wasn't that, but that: https://muidev.de/attachment/ticket/19/glitch.png

And crashes which you have, related to the odyssey again and not to mui. You > can see in crashlog its all about "removeclibboardhook". So that bz to me,
write plz it on bugs.os4depot.net with 100% step-by-step guide of how to
reproduce that crashes on exit.

Ok done: http://bugs.os4depot.net/?function=viewissue&issueid=876

Because as it now, you mess everything in one piece, and mui bugs, and how
odyssey done by fab, and porting bugs.

Of course and it's pretty logic as is and you should remember our old discussions via mail, without any unique repository, without any centric area for making bugreports (or asking for new features) how can i know if a problem is related to our port or if it still also into the original version ?

We discuss it already, as we paid for i think it could be better to have the entire OWB source on Sourceforge (or any other at your choice), because right now it's a bit messy to follow and you can't ask any betatester around to buy a second hand Macintosh just to compare OWB under OS4 and OWB and MorphOS you know ..

In way or another we should convince Fab to accept ifdefs working togheter in a unique repository opened to all, it would be really better and 200% logic for all of us, aniway ..

@Thore

If it is really possible to let the popup window appear below the browser
window in a reproducable fashion then please open a new ticket for that issue > with a step by step instruction.

Yes reproduce it shouldn't be so hard, the various steps are already described here or here:
http://bugs.os4depot.net/?function=viewissue&issueid=876

For now let's forgot the dropdown menus behaviour, but still that 2 problems:

  • 1 - Popup window at some point will appear below the browser window (happen when dropdown menus are opened and you try to play with the OWB window)
  • 2 - When this happen, OWB will crash at exit

comment:14 Changed 6 years ago by Samir Hawamdeh

@Thore

To make our life easier I will open a new ticket as soon as possible but in general the problem are more or less already explained :-)

comment:15 Changed 6 years ago by Roman Kargin

@Thore

If it is really possible to let the popup window appear below the browser window in a reproducable fashion then please open a new ticket for that issue with a step by step instruction.

Its what happens with ulr-history and quick search popup windowses. I.e. when you click on the main odyssey window (or anywhere else), while they open, they just jump under the main owb window and stay invisibly and user may think they closed (because he didn't see them) while they are not, they just invisibly and stays under main window, as any other windowses do. So when user do iconify/deiconify, he see them, and curious "why they there, if they was kind of closed", but they wasn't, they just was invisibly. That kind of annoing, yes, but, that done like this in odyssey itself, by Fab, so its BZ for him.

Or, we need to modify odyssey code in those parts, to make those windowses be autoclosed once anyone press outside of them (like done now with calltips), but now its need changes in odyssey itself for sure. But i for myself prefer if Fab will make it and i will just report working code (to avoid making those custom-different builds, about which users will have different reports and co).

@Samo

I dont angree, i just don't get why we need to keep repeat the same :) I.e. you say:

Roman I know, the glitch i was referring wasn't that, but that:

No. Its not glitch. Where is glitch ? Its you just move main window , and found another window (url-history) under it, which was deactivated by you when you click on main (odyssey) window. I.e. its not drop-down menus. Its windowses. New different windowses.

1 - Popup window at some point will appear below the browser window (happen when dropdown menus are opened and you try to play with the OWB window)

And ir i just do not understand what you tring to say, or i dunno what.

Imho i already explain it few times: window below of the OWB are intendent when you press outside of it you just make main owb window active, and of course another window just deactivated and jumps below of owb. That how it done in odyssey by fab.

I.e. you run odyssey. You go to urls string. You type something. You have dropdown history window (it is not drop-down menu, it is new window and it reacts as window). Then, when you have it swawned (i.e. url-history window on the main odyssey window) it mean you have 2 windowses. Now, you press on main odyssey window, and url-history window just dactivates, and jump under/below main odyssey window, and you don't see it and think it is closed. But is not. Its not autocloses. You just don't see it.

Yes, from user side its quite sucky. But from techincal side everything understandable : you have 2 windowses, and you make one active , of course another (deactivated) automatically jump below the active one.

And that is how it works on morphos too. I even few years ago ask Fab why it like this, he explain me the same things. I got it and forget about, to avoid annoing him with it.

What it mean : your 1) its (as i say many many times, and keep repeat it and trying to explain as much as possible) - intendent. Because you have not "Drop-down menu" of url history (or quick search), but its different windowses. And those windowses didn't closes automatically when you press out of them. They deactivates, and jump below owb and stay here (of course, where they should be ?). If you will move main odyssey window, you of course will see that another "url-history" or "quicksearch" window there. Because its another window.

And 2) not related to mui at all , will check it on bugs.os4depot.net

Last edited 6 years ago by Roman Kargin (previous) (diff)

comment:16 in reply to:  14 Changed 6 years ago by Roman Kargin

@Thore
To make our life easier I will open a new ticket as soon as possible but in general the problem are more or less already explained :-)

That ticket for mui will mean nothing. Because what you ask, its all should be done in Odyssey itself, not in mui. And if write ticked about, then "Suggestion" to the odyssey.

comment:17 Changed 6 years ago by Thore Böckelmann

In 3394:

  • mcc/Calltips.c: make sure that the popup window is moved in front of the parent window upon uniconification. This refs #19.

comment:18 in reply to:  13 Changed 6 years ago by Thore Böckelmann

Replying to samo79:

For now let's forgot the dropdown menus behaviour, but still that 2 problems:

  • 1 - Popup window at some point will appear below the browser window (happen when dropdown menus are opened and you try to play with the OWB window)

I will try to make sure that the popup window cannot be moved behind the browser window. I just committed the first step for this, the second will be done soon.

  • 2 - When this happen, OWB will crash at exit

Take a look at the crashlog yourself. Although MUI must be mentioned in the stack trace as the controlling element it is not MUI which is responsible for the crash, but the clipboard handling. As such MUI is out of the scope here, as I stated earlier already.

comment:19 Changed 6 years ago by Thore Böckelmann

In 3395:

  • Window.c, mcc/Calltips.c: implemented a private attribute to control the window's "stay on top" behaviour. This should really make sure that the popup windows of Calltips.mcc can ever be placed behind any other window. This refs #19.

comment:20 Changed 6 years ago by Samir Hawamdeh

@Thore

I just committed the first step for this, the second will be done soon

Thanks!

Take a look at the crashlog yourself. Although MUI must be mentioned in
the stack trace as the controlling element it is not MUI which is
responsible for the crash

You right on this, (that were two different issues) as kas1e suggest i posted the other one directly into the Odyssey bugtracker

http://bugs.os4depot.net/?function=viewissue&issueid=876

comment:21 Changed 5 years ago by Thore Böckelmann

Milestone: MUI 4.0-2014R34.0-2014R3

Milestone renamed

Note: See TracTickets for help on using tickets.