Re: [Gretl-users] Other GUI changes: "stay on top" dialogs
I think that making it mandatory would be uncomfortable under some
circumstances. What if I want to check something while I'm in a specify
model window? On large screens it wouldn't be an issue (though you'd likely
have to manually move that window out of the way), but on netbook-sized (or
oooooold university computers like the ones we use with ~800x600 resolutions
on CRTs) you could be forced to close the model specifications window to see
what's beneath, loosing the work you've begun. Besides, those dialogs
already show up in the taskbar, it isn't that hard to dig them back up.
Maybe an optional "keep on top of other windows" toggle button on such
dialog could help some, but I don't think it would be such a big
improvement. Perhaps this could be better addressed by removing the "gretl:
" string from the window title for those systems where the taskbar button
width hides the last part of the windows title, and improve some of those
windows titles (instead of "gretl: specify model" for ols, liml, high
precision ols, etc. use "specify - ols", "specify - liml").
On Thu, Dec 3, 2009 at 8:21 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
I've made some changes today in response to a request that Talha a
few days ago, and I'd like to get people's opinions on whether
this change should stay.
That is, should gretl dialogs (other than simple "instant
response" dialogs such as errors and warnings) be marked as
"staying on top" of other windows? [Note: it can't be guaranteed
that this will be respected by all window managers, but there's a
mechanism in GTK to request this.]
Talha's argument was that this firmly prompts users to respond,
rather than "losing" the dialog under other windows. I think that
has some validity, but I can also see a case for saying that a
program that pushes its dialogs in the user's face is being too
bossy. What do people think?
One reason I ask is that I've thought up till now that we couldn't
do this for dialogs that have a Help button, since (if anyone ever
reads Help!) the dialog would obscure its own help text. I've
thought of a way to get around this problem, but before I try
coding I'd like to hear if we want to go with "stay on top"
dialogs at all. (That is, other than error dialogs, which do need
to force a response.)
Allin.
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
Attachments:
- attachment.html (text/html — 3.1 KB)