From mint-bounce@lists.fishpool.fi Fri Apr 14 16:17:05 2006 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] wind_set(WF_TOPMOST) From: Odd Skancke To: MiNT List In-Reply-To: <1145018821.443f99c511bdb@imp5-g19.free.fr> References: <443E1915.5090804@utbm.fr> <443E9A2B.6680.17817B8@localhost> <1144969895.25823.119.camel@linuxbox> <1144998269.443f497de58c5@webmail1.utbm.fr> <1144999862.25823.150.camel@linuxbox> <1145007472.443f6d70304a3@imp3-g19.free.fr> <1145010821.25823.172.camel@linuxbox> <1145018821.443f99c511bdb@imp5-g19.free.fr> Content-Type: text/plain Date: Fri, 14 Apr 2006 16:09:36 +0200 Message-Id: <1145023776.25823.213.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-7) Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=2.8 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: ** fre, 14,.04.2006 kl. 14.47 +0200, skrev arnaud.bercegeay@free.fr: > Hello, > > > I agree. Not very good to have that kind of thing. Therefore TOPMOST > > should be used by system-apps only. > > I don't understand very well *why* this should be reserved to system-apps. If i > don't like an application look'n feel, i just don't use it. I don't want the > AES to forbid this application for me. Let's take the example of an application > that uses its own widget rendering in place of the AES rendering (EZEdit for > example). If i want a text editor to have windows with real AES widget, i just > chose another editor. This is where we differ the most. While I think that GEM app should NEVER EVER render their own widgets/AES objects under any circumstance, you think this is perfectly OK. This undermines the work I've done on Theme handling lately, because there are no restrictions as to what the applications are allowed to do. Discussing further when our opinions differ to this degree is almost useless because we want different goals. I want every GEM app to look the same depending on what Theme the user wants, while you seem to be OK with total anarchy where no rules apply. I hope to god I'm wrong about this, tho ;-) Am I the only one who wants consitency across GEM applications? > > I understand that you may prefer to limit the usage of TOPMOST windows to > system-apps only on your setup, but then you just have to NOT install standard > app that uses > TOPMOST windows... Is there any security reason (?) to limit the usage of > TOPMOST windows to system-apps ? Or is it just a preference (and then, no > really reason to impose that choice to everyone). There are no security issues related to topmost windows, ofcourse. But the limitations suggested on topmost windows are not good either. The argument that topmost windows never gets kbd focus will severly limit the use of such windows even for system applications. I put a lot of work into keyboard navigation, and any window which have anything selectable via mouse should be reachable via kbd too. Then we might as well go with the exnteded alerts I suggested. The real use for topmost windows may be for example the possibility to put the menubar/taskbar/tasklists etc. anywhere without having to reduce the workarea of the desktop (one may want to hide both the menu/taskbar, for exaple). And those will need kbd input too. The focus rules are different from normal windows ofcourse, but focus should not be excluded. > > Don't get me wrong, i just want to understand the motivation of that choice. I > don't say it's a bad choice. Now if we can agree on the fact that topmost windows also should be accessible via keyboard, we are back to what I mentioned before; If apps use topmost windows whenever authors see fit, we may end up with two layers of windows. I just dont get why topmost is necessary when there are other better ways to solve this? > > > Here I do not agree. I think the examples I've seen so far belong to > > the 'alert' group of windows, or situations where the user would choose > > it to be TOPMOST. > > ... and to be without BUTTON, and to have a total control of the rendering (not > only a string + icon), and to change the rendering of the "alert" from time to > time (evolution in real time of the message by alert_draw() ?), and to close the > "alert" when it is no more usefull (alert_close() ?)... well this is exactly the > definition of a window set on TOPMOST without focus, i mean the initial proposal > of Olivier. Again, rendering should always be done by the AES. Any form of application specific window contents (that is, what the application shows in the work area) should be done in normal windows! > > > Besides, I dont agree that TOPMOST windows never > > should have focus. > > So we are not talking of the same thing, and it's natural that we cannot find a > common solution ;) Well, I think understand what you want :-) While I very much agree that these would be very nice, I disagree on using topmost to gain them. You want topmost windows which never get focus, but have a normal work-area for applications to display any kind of .. yeah, alert ;-) .. while I want these to be handled by AES alerts, giving us consistency across the different applications when it comes to looks/themes. I would agree that these alerts can contain a normal AES object tree where progdefs are not allowed. > > You consider the TOPMOST window as a "standard" window wich is just displayed in > top of other (introduction of a 2nd layer of windows)... and in that case, i > agree with most of what you post here, and i disagree with what i post here. Yes. This is what I think a topmost window should be, but without application awareness; these should be controlled by the user via window-context popup, like on KDE. > > In Olivier's idea (and what i consider useful for applications), the "topmost" > layer of windows cannot give the focus to the application, and it fit very well > to the usage i tried to describe. And no, this is not alert. This is a kind of > "user window that contain a high priority message". For example, teatime may > open a small TOPMOST window somewhere on the screen that show the countdown in > real time... displayed over the QED full sized window where you are typing a > text. Aniplayer may display the title of the next OGG file to be played with a > small image of the the CD-cover in the TOPMOST window. A destop utility may > display a "disk near full" message in a TOPMOST window, with the progression of > the disk free memory in real time... and the TOPMOST window will be closed as > soon as the amount of free memory on the disk is ok. No timeout to close this > "alert" window. These still look like alerts to me. As a matter of fact, "a user window that contain a high priority message" sound very much like the very definition of an alert :-) It looks to me that the only thing stopping us from agreeing here is that you want the application to be able to render the contents of these on their own, while I want such messages to be consistent across the applications. Best Regards, Odd Skancke