[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Taskbar area (was: Re: zTask Bug or maybe even kernel bug, or is it my fault?)



On Sat, Jan 15, 2011 at 8:31 PM, Jo Even Skarstein <joska@online.no> wrote:
> On Sat, 2011-01-15 at 12:29 +1100, Paul Wratt wrote:
>
>> > There was a long discussion about the AES setting the accessable desktop
>> > size that excluded the area used by the bar.
>> >
>> > Peter
>> >
>> hmm, what is it you are trying to do. It sound like you are wanting
>> something like the noleft setting used in APP_OPTIONS declarations,
>> but for the bottom of the screen.
>
> Something similar I guess. Basically he wants a way to stop windows from
> overlapping the taskbar.
>
>> Why not just set the apps you dont want hidden to inhibit_hide=true
>> for each app. with APP_OPTIONS declarations.
>
> That's something completely different.
>
> Taskbar can be set to "Always on top" so it will never be hidden.
> However, I rarely use it as it will hide the mover-widget and the
> horizontal slider of fulled windows.
>
> Jo Even
>
OK, I think I understand. I seem to remember having issues with the
taskbar when using HighWire, even though it was set to nohide

I do have a vague memory that the code in XaAES can support "always on
top". I believe the windows are stored in the order they are opened
one after the other, with the current "topped" window being the one on
top of that stack (or array). Any existing window that is then topped
is just moved up that "window stack"

In theory a mechanism to manage "topped" windows could reduce the
point in the stack where the normal "topped" windows are ordered, and
allow "always on top" windows to be inserted above that point

I wounder how well this would fit in with the config. I guess
something like an APP_OPTIONS always_topped option would be suitable,
with order being that in which "allways_topped" was registered, be it
via config, or XaAES menu/popup.

How practical would this be to impliment?

Paul