New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Alert placed in the position of first opened window #119
Comments
If i understand you correctly, you want the alert dialog to always pop up over the window who launched it, while this would be easy to implement it means breaking backward compatibility and apparently a design feature (all dialogs are acting this way), not a big threat, compatibility wise, though, i think. opinions ? |
As you said, it's quite annoying and I see no advantage of the way it is working now. |
There is also the situation of two identically sized windows - one hides the other and as noted by @backorder , there is no placement options for the first window either - perhaps you don't want it in the center of the screen. When you open up the APP/Windows structure for work or redesign for this bug there's some other requests on the issues list that need consideration to make sure those requests are not closed off by a hasty bug fix. There is a case for the current situation - alerts/dialogs belong to the running Shoes C level application and not to the current script or a block in a script. It's one of those design decisions made long ago to keep Shoes simple and cross platform. That's were you start running into backwards compatibility issues. Remember, Shoes 4 is supposed to be compatible with Shoes 3. Two perspectives from one person. |
yes not so simple situation, #define ACTUAL_APP(appvar) \
shoes_app *appvar = NULL; \
if (RARRAY_LEN(shoes_world->apps) > 0) \
Data_Get_Struct(self, shoes_app, appvar) Then we can replace GLOBAL_APP by ACTUAL_APP on a method by method basis basis in gtk.c or cocoa.m (needs testing on osx, but i don't see why it wouldn't work) looks it won't be troublesome for other issues on windows/app, and again dead simple to go back if needed now for compatibility, the change is very light from a code perspective : it won't change anything in the deeps of Shoes, from a user point of view it's just a popup appearing differently, and it might do so in a less annoying way :-)) a not so objective prospective point of view from my last 2 cents |
Hard to argue against working code, @passenger94. Issue the pull request and I'll deal with the OSX side of things when I get a chance. |
test app Shoes.app title: "Main" do
button "new" do
window title: "Deputy", width: 300, height: 200 do
button("ask") {r = ask "do you ?"; alert "'#{r}'\nGlad to know !"}
button("confirm") { r = confirm "sure ?"; alert "corroborated ? #{r}" }
end
end
end |
OSX exhibits the old behavior, as expected. On Windows the new code behaves just as it does on Linux the alert/confirm pops up over the window with the button that launched it. @ProvGANG - you can test it with the new beta http://walkabout.mvmanila.com/public/shoes/shoes-3.2.23-gtk2-32.exe if you like. |
Thank you, that's great! 👍 |
@ccoupe, ok i see now the cocoa side of the recipe ! not so sweet indeed ! |
I've reverted the simple fix because it did cause backwards compatibility issues. #136. I think a better solution might be adding a new style "thing" that can the gtk or cocoa code can reference when creating windows. OSX has a NSWindow.setParentWindow method that might work (or not). Another option to consider is to implement the dialog class in Shoes - it's there but not really used and subclass ask/alert/confirm from shoes-dialog. That would mean duplicating some Ruby/C/Obj-C code to populate the subclass to do the right thing and of course that's not as simple as it sounds. OSX dialog code is on my fix list (future deprecation issues) so I'll look into that side soon. |
Bad news. As best as I can tell, on OSX a modal dialog (which is what alert.ask/confirm/ is) will be placed in the center of the Screen. Their rules. After thinking about it, Apple is correct - Dialogs go up front, in your face. Shoes.ask() should not be used for lazy edit lines if you care about layout and appearance. A patch to gtk.c (windows and linux) to put the dialogs in th center of the screen would be reasonable, IMO of course. |
ok i think i have it replace ACTUAL_APP macro by this one and it should work both ways (subclass or regular) #define ACTUAL_APP(appvar) \
shoes_app *appvar = NULL; \
VALUE actual_app = rb_funcall2(self, rb_intern("app"), 0, NULL); \
Data_Get_Struct(actual_app, shoes_app, appvar); self refers indeed to the subclass in the url/visit scheme, so Data_Get_Struct(self, shoes_app, appvar); wasn't correct !! tested with bug119.rb and #136 example side note @ccoupe : in gtk, alert and co are always placed at the center of the "calling" window |
Yes! You did fix it. Thank you! I changed the macro name (for now) but its working on my Linux and Windows, both #136 and #119. Neither of us is going to change gtk or cocoa dialog behavior. We just do what we can. Not sure what to do about gtk.c:973 (but it works so maybe nothing needs to be done). |
hi :-) |
Fixed in 3.2.24 |
When I open a new window or load it from my app, alert widget is shown in the middle of parent window. This changes when the parent window is closed but there are situations when I want both of them running. Here's the code sample
The text was updated successfully, but these errors were encountered: