Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #75842 > unrolled thread

Keep one GUI always on TOP while python code is running

Back to article view | Back to comp.lang.python

Contents

  Keep one GUI always on TOP while python code is running Jaydeep Patil <patil.jay2009@gmail.com> - 2014-08-07 04:24 -0700
    Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-07 22:57 +1000
      Re: Keep one GUI always on TOP while python code is running Jaydeep Patil <patil.jay2009@gmail.com> - 2014-08-07 22:57 -0700
        Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-08 16:02 +1000
          Re: Keep one GUI always on TOP while python code is running Paul Rudin <paul.nospam@rudin.co.uk> - 2014-08-08 09:57 +0100
            Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-08 19:32 +1000
              Re: Keep one GUI always on TOP while python code is running Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-08 23:58 +1000
                Re: Keep one GUI always on TOP while python code is running Marko Rauhamaa <marko@pacujo.net> - 2014-08-08 17:06 +0300
                Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-09 00:20 +1000
                  Re: Keep one GUI always on TOP while python code is running Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-08-09 04:04 +1000
                    Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-09 08:31 +1000
                  Re: Keep one GUI always on TOP while python code is running Grant Edwards <invalid@invalid.invalid> - 2014-08-11 22:14 +0000
                    Re: Keep one GUI always on TOP while python code is running Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-08-11 19:47 -0400
                Re: Keep one GUI always on TOP while python code is running alister <alister.nospam.ware@ntlworld.com> - 2014-08-08 14:50 +0000
                  Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-09 01:01 +1000
    Re: Keep one GUI always on TOP while python code is running Rustom Mody <rustompmody@gmail.com> - 2014-08-08 06:44 -0700
      Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-08 23:51 +1000
        Re: Keep one GUI always on TOP while python code is running Rustom Mody <rustompmody@gmail.com> - 2014-08-08 07:23 -0700
          Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-09 00:34 +1000
            Re: Keep one GUI always on TOP while python code is running Rustom Mody <rustompmody@gmail.com> - 2014-08-08 07:45 -0700
              Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-09 00:52 +1000
                Re: Keep one GUI always on TOP while python code is running Rustom Mody <rustompmody@gmail.com> - 2014-08-08 07:58 -0700
                  Re: Keep one GUI always on TOP while python code is running Chris Angelico <rosuav@gmail.com> - 2014-08-09 01:05 +1000
    Re: Keep one GUI always on TOP while python code is running Grant Edwards <invalid@invalid.invalid> - 2014-08-11 22:08 +0000

Page 1 of 2  [1] 2  Next page →

#75842 — Keep one GUI always on TOP while python code is running

Hi all,

I have one query. I have did some programming which copies and paste data using system clipboard. I need to keep one GUI always on top till my python code is running.

Can we do like this?



Regards
Jaydeep 

[toc] | [next] | [standalone]

#75849

On Thu, Aug 7, 2014 at 9:24 PM, Jaydeep Patil <patil.jay2009@gmail.com> wrote:
> I have one query. I have did some programming which copies and paste data using system clipboard. I need to keep one GUI always on top till my python code is running.
>

"till" or "while"?

If you mean "while", then yes. But it depends on your GUI toolkit. Are
you using Tkinter, wxpython, PyGTK, etc, etc, etc? Check the docs for
that toolkit and see how to make a window stay on top.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75866

Chris,
I mean to say, One GUI should be always on top from start to end of code running.
So that user cant do any other operation.
I am using wxpython

Regards
Jay

[toc] | [prev] | [next] | [standalone]

#75867

On Fri, Aug 8, 2014 at 3:57 PM, Jaydeep Patil <patil.jay2009@gmail.com> wrote:
> I mean to say, One GUI should be always on top from start to end of code running.
> So that user cant do any other operation.
> I am using wxpython

Ah, that would be called "System Modal", and should be reserved for
absolutely critical system-wide alerts. It's also a feature that's
simply not available to most user-space programs, and not available in
most GUI toolkits.

Short answer: Don't.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75872

Chris Angelico <rosuav@gmail.com> writes:

> On Fri, Aug 8, 2014 at 3:57 PM, Jaydeep Patil <patil.jay2009@gmail.com> wrote:
>> I mean to say, One GUI should be always on top from start to end of code running.
>> So that user cant do any other operation.
>> I am using wxpython
>
> Ah, that would be called "System Modal", and should be reserved for
> absolutely critical system-wide alerts. It's also a feature that's
> simply not available to most user-space programs, and not available in
> most GUI toolkits.
>
> Short answer: Don't.

There are commercial software packages that do this sort of
thing. Examsoft is one - the idea being that people can take exams
without access to other software at the same time (so that, for example,
they could look at previously prepared notes).

[toc] | [prev] | [next] | [standalone]

#75874

On Fri, Aug 8, 2014 at 6:57 PM, Paul Rudin <paul.nospam@rudin.co.uk> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Fri, Aug 8, 2014 at 3:57 PM, Jaydeep Patil <patil.jay2009@gmail.com> wrote:
>>> I mean to say, One GUI should be always on top from start to end of code running.
>>> So that user cant do any other operation.
>>> I am using wxpython
>>
>> Ah, that would be called "System Modal", and should be reserved for
>> absolutely critical system-wide alerts. It's also a feature that's
>> simply not available to most user-space programs, and not available in
>> most GUI toolkits.
>>
>> Short answer: Don't.
>
> There are commercial software packages that do this sort of
> thing. Examsoft is one - the idea being that people can take exams
> without access to other software at the same time (so that, for example,
> they could look at previously prepared notes).

Yeah; like I said, "Don't" is the short answer. There will be
exceptions, some extremely rare situations when system modality is
correct; but fundamentally, it's impossible to use GUI software to
control what a person does with a computer (for instance, on all my
Linux systems, I can hit Ctrl-Alt-F1 to switch away from the GUI
altogether). So I'm dubious about its value for anything that isn't an
absolutely critical alert. With the OS/2 Presentation Manager, I had
SystemModal available as a window flag, and I used it for two
purposes: an out-of-memory alert (or similarly critical resource
shortage), and a pseudo-login screen (it just asked for a name, no
password or anything, and it didn't change what you had access to - it
was for the purposes of logging and messaging identification, nothing
more); and the latter didn't really need to be system modal, it was
just for convenience.

If there's no way to make a wxpython window system modal, I would say
it's no great loss. The chances of the feature being misused are
extremely high; the cases where it's actually needed are extremely
rare. Hence my short answer of "Don't"; honestly, there are more times
when you need to optimize Python code for performance than there are
times to create system modal windows.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75884

Chris Angelico wrote:

> On Fri, Aug 8, 2014 at 6:57 PM, Paul Rudin <paul.nospam@rudin.co.uk>
> wrote:
>> Chris Angelico <rosuav@gmail.com> writes:
>>
>>> On Fri, Aug 8, 2014 at 3:57 PM, Jaydeep Patil <patil.jay2009@gmail.com>
>>> wrote:
>>>> I mean to say, One GUI should be always on top from start to end of
>>>> code running. So that user cant do any other operation.
>>>> I am using wxpython
>>>
>>> Ah, that would be called "System Modal", and should be reserved for
>>> absolutely critical system-wide alerts. It's also a feature that's
>>> simply not available to most user-space programs, and not available in
>>> most GUI toolkits.
>>>
>>> Short answer: Don't.
>>
>> There are commercial software packages that do this sort of
>> thing. Examsoft is one - the idea being that people can take exams
>> without access to other software at the same time (so that, for example,
>> they could look at previously prepared notes).
> 
> Yeah; like I said, "Don't" is the short answer. There will be
> exceptions, some extremely rare situations when system modality is
> correct; but fundamentally, it's impossible to use GUI software to
> control what a person does with a computer

There are exceptions, but it's impossible? Impossible except for the
exceptions, I presume :-P

> (for instance, on all my 
> Linux systems, I can hit Ctrl-Alt-F1 to switch away from the GUI
> altogether). 

Does that work when xscreensaver or equivalent has locked the system? If so,
that's a security vulnerability.


> So I'm dubious about its value for anything that isn't an 
> absolutely critical alert. 

Well, there's at least two use-cases I can think of:

* screen locking, as in screen savers;

* login screens;

* exam software;

Eh, that is, at least three use-cases:

* screen locking;

* login screens;

* exam software;

* emulating full screen arcade games;

Um, among the use-cases are, screen locking, login screens, exam software,
full-screen games, critical system alerts, and, of course, the most popular
reason of all:

* my application is SOOOOO SPECIAL that it deserves to take over the
  entire GUI Just Because I Can.

I don't know any platform-independent GUI toolkits which offer this out of
the box, but I expect that there's probably a way to do it in a platform
specific way on each platform you wish to support. Either that, or the OP
can google for <wxpython "system modal"> (including the quotes) and see
what comes up. I'd do so myself, except some damn fool Javascript code
running on some rubbish web site just crashed my browser. Again.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#75885

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> Does that work when xscreensaver or equivalent has locked the system?
> If so, that's a security vulnerability.

Depends on the semantics of the screensaver. Its scope is the current
X11 session.

In my home, different family members have different VTs. Locking one VT
shouldn't prevent you from switching over to a different one.


Marko

[toc] | [prev] | [next] | [standalone]

#75887

On Fri, Aug 8, 2014 at 11:58 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Chris Angelico wrote:
>
>> Yeah; like I said, "Don't" is the short answer. There will be
>> exceptions, some extremely rare situations when system modality is
>> correct; but fundamentally, it's impossible to use GUI software to
>> control what a person does with a computer
>
> There are exceptions, but it's impossible? Impossible except for the
> exceptions, I presume :-P

There are exceptions to the rule "you shouldn't use system modal
windows". It is, however, fundamentally impossible for GUI software to
completely control what the person does - system modality is defined
only to the extent of the GUI.

>> (for instance, on all my
>> Linux systems, I can hit Ctrl-Alt-F1 to switch away from the GUI
>> altogether).
>
> Does that work when xscreensaver or equivalent has locked the system? If so,
> that's a security vulnerability.

Absolutely it works! However, what you get to is a terminal with a
login prompt. If you don't know a valid userid and password, you can't
get in. (And if you *do* know them, you can probably get in through
the GUI, too, although it's possible for a screen saver to lock such
that no other account can log in.)

>> So I'm dubious about its value for anything that isn't an
>> absolutely critical alert.
>
> Well, there's at least two use-cases I can think of:
>
> * screen locking, as in screen savers;
>
> * login screens;

With these two, it's deliberately locking only the GUI, so system
modality could be correct. But really, it's more about covering the
whole screen; system modality is more about disabling the whole
screen. So they're still not a perfect match.

> * exam software;

This is what I'm dubious about. Since you can always log in via some
other method, or brute-force something (eg replace one of the system
accessibility programs with your own tool), it's impossible for the
software to stop you from running something else. And if the computer
you're doing this on is so locked down that you can't pull up your
notes in some other app, it may as well simply be so locked down that
you can't get your notes onto that computer in the first place.

> * emulating full screen arcade games;

Why should that disable access to everything else? Most full screen
games let you alt-tab away from them (preferably auto-pausing the
game). If a game goes system modal on me, I would not be happy.

> * my application is SOOOOO SPECIAL that it deserves to take over the
>   entire GUI Just Because I Can.

And that one is definitely not a reason, as I'm sure you agree :)

> I don't know any platform-independent GUI toolkits which offer this out of
> the box, but I expect that there's probably a way to do it in a platform
> specific way on each platform you wish to support.

There may be; there also may not (that is to say, there may be
platform-specific ways on some, but not all, platforms - I'm not sure
Windows has the functionality). But that's par for the course... if
every platform had the exact same features, we wouldn't need multiple
platforms.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75899

Chris Angelico wrote:

> On Fri, Aug 8, 2014 at 11:58 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Chris Angelico wrote:
>>
>>> Yeah; like I said, "Don't" is the short answer. There will be
>>> exceptions, some extremely rare situations when system modality is
>>> correct; but fundamentally, it's impossible to use GUI software to
>>> control what a person does with a computer
>>
>> There are exceptions, but it's impossible? Impossible except for the
>> exceptions, I presume :-P
> 
> There are exceptions to the rule "you shouldn't use system modal
> windows". It is, however, fundamentally impossible for GUI software to
> completely control what the person does - system modality is defined
> only to the extent of the GUI.

*Fundamentally* impossible? You've never used classic Mac OS, I take it. Or
a non-jail-broken iPhone.

There is nothing *fundamental* that says that a GUI interface is necessarily
a second-class interface, or that a non-GUI interface is always available.


>>> (for instance, on all my
>>> Linux systems, I can hit Ctrl-Alt-F1 to switch away from the GUI
>>> altogether).

You're assuming that there are any virtual terminals running on the system,
which is not a given. Windows doesn't have them at all. Even in Linux, they
can be turned off(?) or at least access to them disabled. For that matter,
you're assuming the machine has a keyboard attached. Have you never seen a
machine running in kiosk mode with only a touchscreen or trackball?

http://wiki.tldp.org/Kiosk-HOWTO


>> Does that work when xscreensaver or equivalent has locked the system? If
>> so, that's a security vulnerability.
> 
> Absolutely it works! However, what you get to is a terminal with a
> login prompt.

I don't think so. I think you get a terminal which may or may not be already
logged in. Hence the security vulnerability: if you leave a virtual
terminal logged in, then locking the X terminal alone via xscreensaver is
useless.

I haven't tried it with xscreensaver itself, but I've just tried it with
whatever screensaver KDE under Centos uses, and sure enough, it locks the X
session but allows access to any virtual terminals that happen to already
be logged in with no authentication needed.


[...]
>> * exam software;
> 
> This is what I'm dubious about. Since you can always log in via some
> other method, 

Always? You're saying it is impossible to disable telnet and ssh? Or unplug
the network cable?

But really, now we're getting silly. No, exam software isn't going to
prevent you from ssh'ing into the computer from another computer, assuming
ssh is allowed. Nor is it going to prevent you from using another computer,
getting answers from handwritten notes or books, or asking somebody to help
you. That's hardly the point.


> or brute-force something (eg replace one of the system 
> accessibility programs with your own tool), 

And how am I supposed to do that, from the exam software itself, without
access to a shell?


> it's impossible for the 
> software to stop you from running something else. And if the computer
> you're doing this on is so locked down that you can't pull up your
> notes in some other app, it may as well simply be so locked down that
> you can't get your notes onto that computer in the first place.

Um, yes? Although not necessarily. We're getting further and further from
the OP's question, which should be interpreted in the most reasonable
manner, not the least reasonable:

- he probably only cares about blocking access to the rest of the 
  GUI environment, not virtual terminals (assuming he is even using
  a system with virtual terminals);

- or he's trying to build a kiosk application.

It is unreasonable to interpret his comment "user cant [sic] do any other
operation" so broadly that we have to care about (e.g.):

- ssh'ing into the computer from another machine;

- rebooting into single user mode;

- walking away from the computer to do something else.

All those things can be solved (e.g. by turning off the ssh daemon, or
blocking access at the firewall, using a custom BIOS, and chaining the user
to the computer), but likely not by the GUI toolkit itself.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#75911

On Sat, Aug 9, 2014 at 4:04 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Chris Angelico wrote:
>
>> On Fri, Aug 8, 2014 at 11:58 PM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> Chris Angelico wrote:
>>>
>>>> Yeah; like I said, "Don't" is the short answer. There will be
>>>> exceptions, some extremely rare situations when system modality is
>>>> correct; but fundamentally, it's impossible to use GUI software to
>>>> control what a person does with a computer
>>>
>>> There are exceptions, but it's impossible? Impossible except for the
>>> exceptions, I presume :-P
>>
>> There are exceptions to the rule "you shouldn't use system modal
>> windows". It is, however, fundamentally impossible for GUI software to
>> completely control what the person does - system modality is defined
>> only to the extent of the GUI.
>
> *Fundamentally* impossible? You've never used classic Mac OS, I take it. Or
> a non-jail-broken iPhone.
>
> There is nothing *fundamental* that says that a GUI interface is necessarily
> a second-class interface, or that a non-GUI interface is always available.

What I mean is that GUI software can't control the entire computer.
It's impossible for a system-modal flag to prevent access to non-GUI
parts of the computer. Now, if there happen to be none of them (that
you're aware of - certain OSes are rife with unexpected backdoors),
then for all practical purposes, it's controlling the whole computer -
but technically it still isn't.

> You're assuming that there are any virtual terminals running on the system,
> which is not a given. Windows doesn't have them at all. Even in Linux, they
> can be turned off(?) or at least access to them disabled. For that matter,
> you're assuming the machine has a keyboard attached. Have you never seen a
> machine running in kiosk mode with only a touchscreen or trackball?
>
> http://wiki.tldp.org/Kiosk-HOWTO

This is what I was saying about the system being so locked down
already that there's no point going system modal. If you can't invoke
other programs, what's it matter if you could switch to other running
programs? So system modality is still pointless on a kiosk.

>>> Does that work when xscreensaver or equivalent has locked the system? If
>>> so, that's a security vulnerability.
>>
>> Absolutely it works! However, what you get to is a terminal with a
>> login prompt.
>
> I don't think so. I think you get a terminal which may or may not be already
> logged in. Hence the security vulnerability: if you leave a virtual
> terminal logged in, then locking the X terminal alone via xscreensaver is
> useless.
>
> I haven't tried it with xscreensaver itself, but I've just tried it with
> whatever screensaver KDE under Centos uses, and sure enough, it locks the X
> session but allows access to any virtual terminals that happen to already
> be logged in with no authentication needed.

Oh, sorry. I thought you were talking about the "oops you got around
my security" problem. If you leave something logged in, that's a
security vulnerability; whether that's on a VT or in a web browser
tab, someone (you or someone else) can then use it. As far as I'm
concerned, the vulnerability has nothing to do with a locked GUI. If
you're trying to ensure that someone can't get around your program,
you have to make sure there's no available logins.

> [...]
>>> * exam software;
>>
>> This is what I'm dubious about. Since you can always log in via some
>> other method,
>
> Always? You're saying it is impossible to disable telnet and ssh? Or unplug
> the network cable?

I'm assuming here that the student has some control of the computer
the software's being run on. If the student has absolutely no control
over the computer, then it's the kiosk situation; there's no point
locking the GUI because you'll already have locked everything else.
What you're basically saying is "Hey look, I have a perfect lock on my
front door - backed up by a moat full of angry crocodiles". The crocs
make the lock superfluous.

>> or brute-force something (eg replace one of the system
>> accessibility programs with your own tool),
>
> And how am I supposed to do that, from the exam software itself, without
> access to a shell?

Again, this would be something you'd do beforehand, making use of some
measure of control over the computer. If you can't do anything like
that, it's kiosk mode.

I'm thinking here of the time I had a Windows 7 VM that I'd forgotten
the password to. The solution? Boot a rescue disk (I could probably
have done this with a Linux live CD and an ntfs mount), copy cmd.exe
over the top of some accessibility program (backing it up first), and
reboot. The same can be done with Linux; if you can boot your own
media, you can change anything and give yourself access (put yourself
in sudoers, give yourself some groups, create a setuid root shell,
etc, etc, etc). So the *only* way to prevent access to a physical
machine is to prevent *all* access. And at that point, any lesser
control is utterly superfluous.

> We're getting further and further from
> the OP's question, which should be interpreted in the most reasonable
> manner, not the least reasonable:
>
> - he probably only cares about blocking access to the rest of the
>   GUI environment, not virtual terminals (assuming he is even using
>   a system with virtual terminals);

In that case, a (possibly maximized) always-on-top window is probably
all he needs. Which is why that was my very first response to him.

> - or he's trying to build a kiosk application.

In that case, he needs to learn a lot about how to build a kiosk, and
it's way WAY beyond the scope of python-list.

> It is unreasonable to interpret his comment "user cant [sic] do any other
> operation" so broadly that we have to care about (e.g.):
>
> - ssh'ing into the computer from another machine;
>
> - rebooting into single user mode;
>
> - walking away from the computer to do something else.
>
> All those things can be solved (e.g. by turning off the ssh daemon, or
> blocking access at the firewall, using a custom BIOS, and chaining the user
> to the computer), but likely not by the GUI toolkit itself.

Definitely. I don't think there's a wxpython flag
wx.CHAIN_USER_TO_CHAIR. That said, though: it is conceivable to have
students use their own computers for exams, while under approximate
observation by a human. That would prevent them from using external
devices or paper notes, but would make all the rest of this thread
exactly correct. And that's what I'm saying is fundamentally
impossible; if the students have any prior access to the computers,
they can get around the problem - and if they have no prior access (or
they get HD wiped before the exam), then there's nothing to access
anyway, and thus no problem. (Presumably, anyone who would go to the
effort of wiping the drives to keep notes away will also isolate them
from the network.)

Personally, though, I think the whole concept of exams is pretty
pointless. I heard somewhere that the final qualifying test for
certain Cisco certifications is to be put in a room with a router that
someone's broken in some way, and told "You have X minutes. Fix it.".
No need to lock out a GUI, this is absolutely accurate to real life.
Of course, it's a bit hard to put someone in a room with allgebra and
say "I've broken something. Fix it."... :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#76081

On 2014-08-08, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Aug 8, 2014 at 11:58 PM, Steven D'Aprano

> Why should that disable access to everything else? Most full screen
> games let you alt-tab away from them (preferably auto-pausing the
> game). If a game goes system modal on me, I would not be happy.
>
>> * my application is SOOOOO SPECIAL that it deserves to take over the
>>   entire GUI Just Because I Can.
>
> And that one is definitely not a reason, as I'm sure you agree :)

But, AFAICT, that's the only reason behind the behavior for a lot of
Windows apps.  Authors of X apps don't seem to suffer from such
delusions of grandeur (or maybe it's just too hard under under X).

My opinion is that people with valid reasons to use a system-modal
window don't need to ask how.  IOW asking how to do it is pimae-facie
evidence that you should not be doing it.

-- 
Grant Edwards               grant.b.edwards        Yow! PIZZA!!
                                  at               
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#76089

On Mon, 11 Aug 2014 22:14:12 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> declaimed the following:

>
>But, AFAICT, that's the only reason behind the behavior for a lot of
>Windows apps.  Authors of X apps don't seem to suffer from such
>delusions of grandeur (or maybe it's just too hard under under X).
>
	Or maybe influenced by the facet that X-Window is a full client/server
model where the display engine is the server, and multiple applications
(which could even be on different computers) are the clients.

	In contrast, M$ Windows tends to make each application responsible for
its windows via a DLL, but doesn't really have an overall display server.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#75892

On Fri, 08 Aug 2014 23:58:56 +1000, Steven D'Aprano wrote:
> 
>> (for instance, on all my Linux systems, I can hit Ctrl-Alt-F1 to switch
>> away from the GUI altogether).
> 
> Does that work when xscreensaver or equivalent has locked the system? If
> so,
> that's a security vulnerability.

I have not tried b=ut is should not be a security risk as you still have 
to log into the virtual terminal.

this may even be desirable if multiple people may administer the PC.
 


-- 
I never met a piece of chocolate I didn't like.

[toc] | [prev] | [next] | [standalone]

#75895

On Sat, Aug 9, 2014 at 12:50 AM, alister
<alister.nospam.ware@ntlworld.com> wrote:
> On Fri, 08 Aug 2014 23:58:56 +1000, Steven D'Aprano wrote:
>>
>>> (for instance, on all my Linux systems, I can hit Ctrl-Alt-F1 to switch
>>> away from the GUI altogether).
>>
>> Does that work when xscreensaver or equivalent has locked the system? If
>> so,
>> that's a security vulnerability.
>
> I have not tried b=ut is should not be a security risk as you still have
> to log into the virtual terminal.
>
> this may even be desirable if multiple people may administer the PC.

Right. Unix has as its underlying philosophy that users and processes
are the most important things, not interfaces. I can log in to a
computer at a virtual terminal by pressing Ctrl-Alt-F1, or with a
graphical login manager like lightdm, or via ssh, or something else,
and everything works. And if I leave something running under my user
name that allows me to connect remotely, or maybe have something
running as root that can hook in to some sort of user event (off a USB
device, or a secondary mouse, or whatever) that can then display
something on the screen, then no amount of login prevention will
change that.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75882

On Thursday, August 7, 2014 4:54:09 PM UTC+5:30, Jaydeep Patil wrote:
> Hi all,

> I have one query. I have did some programming which copies and paste data using system clipboard. I need to keep one GUI always on top till my python code is running.

In linux you can do (at shell level)
$ wmctrl -r "window" -b add,above

Note: In place of window you will need a string that is in your window title
You can get these with
$ wmctrl -l

You can then stuff this into python with os.system

Windows: No idea

[toc] | [prev] | [next] | [standalone]

#75883

On Fri, Aug 8, 2014 at 11:44 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Thursday, August 7, 2014 4:54:09 PM UTC+5:30, Jaydeep Patil wrote:
>> Hi all,
>
>> I have one query. I have did some programming which copies and paste data using system clipboard. I need to keep one GUI always on top till my python code is running.
>
> In linux you can do (at shell level)
> $ wmctrl -r "window" -b add,above

AIUI that just sets the "always on top" flag, which isn't what he's
asking for. Also, his toolkit should offer that directly.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75888

On Friday, August 8, 2014 7:21:35 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Aug 8, 2014 at 11:44 PM, Rustom Mody wrote:
> > On Thursday, August 7, 2014 4:54:09 PM UTC+5:30, Jaydeep Patil wrote:
> >> Hi all,
> >
> >> I have one query. I have did some programming which copies and paste data using system clipboard. I need to keep one GUI always on top till my python code is running.
> >
> > In linux you can do (at shell level)
> > $ wmctrl -r "window" -b add,above
> 
> 
> 
> AIUI that just sets the "always on top" flag, which isn't what he's
> 
> asking for. Also, his toolkit should offer that directly.

A windows equivalent for linux's wmctrl seems to be nir
http://www.nirsoft.net/utils/nircmd2.html#using

Search for 'settopmost'

[toc] | [prev] | [next] | [standalone]

#75889

On Sat, Aug 9, 2014 at 12:23 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> A windows equivalent for linux's wmctrl seems to be nir
> http://www.nirsoft.net/utils/nircmd2.html#using
>
> Search for 'settopmost'

No need; both of those are just setting the "always on top" flag,
which wxpython can do directly. It may be unobvious, as there seem to
be a lot of questions asked about it (lots of StackOverflow and forums
posts), but ultimately, there's a wx.STAY_ON_TOP flag that will do the
same thing.

However, the OP wasn't asking about visually keeping a window on top,
which is pretty easy. Trying to actually prevent access to any other
window is significantly harder to do, plus it's never going to be more
broad than one X session, plus it's almost always a bad UI idea.

ChrisA

[toc] | [prev] | [next] | [standalone]

#75891

On Friday, August 8, 2014 8:04:05 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Aug 9, 2014 at 12:23 AM, Rustom Mody  wrote:
> > A windows equivalent for linux's wmctrl seems to be nir
> > http://www.nirsoft.net/utils/nircmd2.html#using
> >
> > Search for 'settopmost'
> 
> 
> No need; both of those are just setting the "always on top" flag,
> which wxpython can do directly. It may be unobvious, as there seem to
> be a lot of questions asked about it (lots of StackOverflow and forums
> posts), but ultimately, there's a wx.STAY_ON_TOP flag that will do the
> same thing.
> 
> 
> 
> However, the OP wasn't asking about visually keeping a window on top,
> which is pretty easy. Trying to actually prevent access to any other
> window is significantly harder to do, plus it's never going to be more
> broad than one X session, plus it's almost always a bad UI idea.
> 

This is the OP:

> I have one query. I have did some programming which copies and
> paste data using system clipboard. I need to keep one GUI always 
> on top till my python code is running.

[I am of course assuming that 'did' means 'done' and 'GUI' means 'window' or 'widget']

I dont see anything about preventing access.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web