Re: [ql-users] locking a window?
Bury me at the deepest level [ just on top of the desktop background if any ] would be very nice for QDT. Most modern desktop put their object icons directly onto the desktop and most windows sit on top of them by default. This would allow me to place the icons onto literally the desktop and have an option for a user to pick them all to the top (if he is trying to find one - useful since we don't have a way to hide all windows (or do we - another option?) or put them back down. Cheers, jim On Oct 1, 2004, at 12:10 AM, Jérôme_Grimbert wrote: Marcel Kilgus wrote: James Hunkins wrote: Marcel, were you thinking of something specific here? Just that constantly picking a windows is a bad thing to do. Perhaps I want to work with another application on top that happens to burry it? That's also why programmatically bringing another application to the foreground is impossible since Windows 2000 (instead the task bar button starts to flash). A long time ago, when background was not available at the system level, one way to do it was to have a full-screen application which always picked another to the top... due to the lack of 'Burry me to the deepest level' system call. Maybe what some need is some additional system calls: - Burry me at the deepest level (opposite of current 'bring me to top') (but to keep things clean and safe, should work only for current job, not for another, as Marcel noted, that would be a bad thing to do.) - Am I at the deepest level ? - Am I partially covered ? (not fully exposed: aka, I/O would block) - Am I at the top level ? (fully exposed) ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
I had considered that but things like dropdown menus and error messages should have the original window left open so that you can have a reference. Not to mention, with folders, I would not like a full folder closing every time I wanted to run do a change to it or pick a sub-option. For somethings your suggestion may work but I am afraid not for the desktop that I am working on. Cheers, jim On Oct 1, 2004, at 2:37 AM, John Hall wrote: James Hunkins wrote: By the way, this mechanism is only being used when a particular sub-program is called and the calling window needs to be locked. Examples programs that need windows larger than the caller's window [drop-down menus, File and List selects, etc] and programs that will be directly changing something in the calling program so we would want to lock the calling program out [IconDraw for notebooks which will change the notebook's icon, Add Objects for folders, and notebooks for folders or Icons]. A possible alternative approach would be to close/remove the calling program's window(s) before the sub-program is called and then reinstating it/them when the sub-program exits... John ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
James Hunkins wrote: I had considered that but things like dropdown menus and error messages should have the original window left open so that you can have a reference. Not to mention, with folders, I would not like a full folder closing every time I wanted to run do a change to it or pick a sub-option. For somethings your suggestion may work but I am afraid not for the desktop that I am working on. Of two things, one or the other: - if you are considering a subwindow like a dropdown menus, then it should, as a secondary, fit inside the primary. May be the primary is too small to allow that, or your secondary might enjoy some sliding bars to fit ? (or any other trick that would reduce the needed space). Secondary that falls outside of primary are not a good idea (it's impossible so far with PTR, and I believe it's a good thing.) If the secondary need more room than the primary, you have a design problem. (nevertheless, being able to move a secondary might be a good idea, so remember to allow such icon and action in your secondaries). - if the sub-window is an independant application, why do you want to lock down the primary at all ? If the primary is visible, then, as a user, I'm expecting to be able to use it. (Even if the sub-application is running). Do not enter the fascist dialog-mode with a user. Rather than denying it access to a visible locked application, hide the application. If the user cannot see it, he cannot use it! Cheers, jim On Oct 1, 2004, at 2:37 AM, John Hall wrote: James Hunkins wrote: By the way, this mechanism is only being used when a particular sub-program is called and the calling window needs to be locked. Examples programs that need windows larger than the caller's window [drop-down menus, File and List selects, etc] and programs that will be directly changing something in the calling program so we would want to lock the calling program out [IconDraw for notebooks which will change the notebook's icon, Add Objects for folders, and notebooks for folders or Icons]. A possible alternative approach would be to close/remove the calling program's window(s) before the sub-program is called and then reinstating it/them when the sub-program exits... John ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
On 1 Oct 2004 at 12:32, Jérôme Grimbert wrote: J - if the sub-window is an independant application, why do you want to lock down the primary at all ? If the primary is visible, then, as a user, I'm expecting to be able to use it. (Even if the sub-application is running). Do not enter the fascist dialog-mode with a user. Rather than denying it access to a visible locked application, hide the application. If the user cannot see it, he cannot use it! Just for a futher clarification - do I understand you correctly, Jim, that you want the following: exec a program(program B) from another one (program A), and have that other one(B) always stay on top of the first one (A).? Like, for example, use the QPAC2 files menu to launch an application, and make sure that the window thereof is never covered by QPAC2's files menu later on? Wolfgang ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
Marcel Kilgus writes: James Hunkins wrote: Marcel, were you thinking of something specific here? Just that constantly picking a windows is a bad thing to do. Perhaps I want to work with another application on top that happens to burry it? Not a problem. Try it! That's also why programmatically bringing another application to the foreground is impossible since Windows 2000 (instead the task bar button starts to flash). In this case it is justified, imho. Windoze seems to be able to attach the windows of two jobs so that picking one always picks the other (eg when clicking send and receive mail in Lookout (no snide comments please guys!) a progress window pops up and over that the connections dialogue (ie two separate programs). If you bury those two windows and then click on the button for the progress window in the task bar, they both pop up, with the connections dialogue on top.) Thats the effect I was trying to achieve (and I presume Jim too). Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
Re: [ql-users] locking a window?
Jérôme Grimbert writes: Maybe what some need is some additional system calls: - Burry me at the deepest level (opposite of current 'bring me to top') (but to keep things clean and safe, should work only for current job, not for another, as Marcel noted, that would be a bad thing to do.) - Am I at the deepest level ? - Am I partially covered ? (not fully exposed: aka, I/O would block) - Am I at the top level ? (fully exposed) Our system is rather primitive in this respect. If thered been a zillion SMSQ/E users Im sure this would have been fixed long ago. It is possible to emulate some (or all?) of the features we have been discussing usng existing means, but of course it would be much better to have all this done for us by simple system calls. However, were not likely to get that, as we seem to be a parsimonous lot, and not prepared to pay a penny for the priviledge. - Am I at the deepest level? - could be done by a small toolkit. Scanning the Pile is well documented. - Am I partially covered (or not)? - Can be ascertained now eg using iop.rdpt with termination vector = 48 - Bury me at the deepest level - would be very difficult to do in a general way, I think, and of doubtful value. It would, however, be great to be able to add icons or buttons to the desktop, as Jim suggests. Would it be difficult to give the Background a channel, but still keep it unpickable? One feature Id be very interested in, and the functionality already exists (in Qpac2), is making a window diasppear from the screen without closing its channels or loosing its information. Thats what the button_sleep job does. Per ___ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
