From mint-bounce@lists.fishpool.fi Thu Apr 13 22:01:10 2006 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <1144957798.443eab66887d4@webmail2.utbm.fr> Date: Thu, 13 Apr 2006 21:49:58 +0200 From: "olivier.landemarre@utbm.fr" To: MiNT List Subject: Re: [MiNT] wind_set(WF_TOPMOST) References: <443E0AEB.8050708@utbm.fr> <1144918628.25823.32.camel@linuxbox> <443E1915.5090804@utbm.fr> <1144922563.25823.45.camel@linuxbox> <443E6F3E.3020509@utbm.fr> <1144949935.25823.78.camel@linuxbox> In-Reply-To: <1144949935.25823.78.camel@linuxbox> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.8 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: Olivier.Landemarre@utbm.fr 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=1.8 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00, RCVD_IN_SORBS X-Spam-Level: * Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id k3DK1A4M013512 ... > > > > > > I dont quite agree here. I think that this feature should be reserved > > >for system-applications only, such as a taskbar/manager, etc. > > > > > How do you define system-application? For example taskbar is a simple > > gem application for me. > > N.AES introduced a function appl_control(). I see that XaAES have a > mode APC_SYSTEM, which lets a gem application be a AES system extension, > altho I dont know the details. I not implement it yet, but I don't know the usefull of it, if a program simply wan't to do an WF_TOPMOST it just do before an appl_control(), and I don't know how we could restrict it. > > > > > >Normal > > >applications should use normal windows, the AES provides for > > >alerts/popups already via form_popup/menu_popup/form_alert etc. A better > > >route would be to extend these calls to be non-app-blockable. > > > > > > > > I not see relation with this feature. This is a feature existing in most > > modern system, most of time to display some messages for a short time > > (ex amorok on X11). I agree alerts, popup should be able to be non > > locking, but it's an other problem (should be solve with AES message as > > some alternative file selector do (not as Magic do! I can't remember > > name of this file selector)). > > The feature I'm aware other GUI's have are so-called 'program-modal' > windows. This would be the same as extended alert windows to us for > example. Altho these sometimes do not have keyboard focus, the focus > doesnt go to the underlying windows of the program opening such a window > either, I think. If the underlying window is of another application, you > do get keyboard input. > > > > > > > > > > > >>wind_set(WF_TOP) or wind_set(WF_BOTTOM) have no effects at this time, > > >>but perhaps I could change this, but window can't receive WM_TOPPED and > > >>WM_BOTTOMED at this time, do you think it's need? I think it should be > > >>possible change order beetween all TOPMOST windows, I have not think > > >>about this possibility before I write this. What do you think about > > >>this? need or not? > > >> > > >> > > > > > > What you are proposing here is a second fully-working window-stack. > > >This is indeed necessary for this implementation, but applications must > > >not have the same access to this stack as to the normal-window-stack. > > >That would lift the whole purpose of 'floating' windows, I think, as you > > >could end up with a second 'layer' of windows only. So, no, I do not > > >think these windows should be WF_TOP/BOTTOM controllable by > > >applications. I think we need to sit down and clearly define what we > > >need these windows for, and define their use properly before rushing > > >into implementation that will bring us headache later on. > > > > > > > > Yes. But I think actual implementation I done, let an aes, to manage in > > the way it wan't, here this is only a flag to put a window in a specific > > way, after you can choose or not to control TOP and BOTTOM. I can do > > this probably, but perhaps it's not need! > > > > > > > The 'floating' window is, as you say, very useful for taskbars, etc., > > >but imagine what happens if all apps can have 'floating' windows... > > >system-apps like taskbars, etc, loose again. > > > > > > > > > > I think near never application use it only for a very specific use, this > > is possible on other system, and I have not see some abuse of this. In > > the way I have implement it, application have nothing more to do than > > the software already do. I have a way to force this mode for all windows > > an application open and test it on Ztask, I not notice any trouble with > > this. > > Let me get this 100% correct; You do mean that these windows are never > getting covered by 'normal' windows, they always 'float' ontop of the > 'normal' ones? In which case, if more apps that absolutely necessary use > these types of windows, we end up with having two layers of windows, and > the whole idea gets lost. Plus you have to maintain two window stacks. > Are there any restrictions as to how many such windows one app can open? Actually I have only one stack and not plan to add one, there is no more restriction in number than the totaly windows open. > > > > > > Anyone else have opinions on this matter? > > > > > > > > > > > Yes, need opinion. > > I think we need to carefully consider what such a feature will solve. > Which application, or what situations, would need a window that isnt an > alert, a popup or a normal window? Now, alerts and popups are completely > controlled by the AES, and carefully extending these existing 'window > classes', we can make sure we get a clear and good GUI. I do agree that > 'floating' windows are necessary in some cases, such as for a > taskmanager, taskbar and other AES system extensions. I also think that > when a 'normal' application have something important to tell the user, > it should use alerts. Users can then decide if they want the alerts to > 'float' over all windows, or just over the alert-callers windows. > But alert and popup are not funny for display, you can't manage window as you wan't, can't put gem object on it, can't simply display a message for a short time (because you wait alway's for clos something) etc... ex anyplayer play a list of music, it change of title, it could for 3 second the title of the song, some software write time in hard in menu, probably it could be better to be above menu bar, bubble could be display, a lot of softawre open a window in top, to inform of the load of the software (not in our world!) etc... Most of time for a short time. regards Olivier > > > > Best Regards, > Odd Skancke > > > > > > --