Activity for Tuxo Holic
-
Tuxo Holic posted a comment on discussion Help
Hello, with Debian Buster & Bullseye my bookmark stop working when the ip lease changes the next day. My router does offer dnsmasq for hostname advertising using dns or netbios using nmbd. testparm on my debian desktop tells me my name lookup is configured like this: name resolve order = bcast host lmhosts wins Is the ip value stored in the bookmark always used and the unc //hostname value ignored?
-
Update: Fix is to add "client min protocol = NT1" and "client max protocol = NT1" in the client smb.conf.
-
Update: Fix is to add "client max protocol = NT1" and "client max protocol = NT1" in the client smb.conf.
-
In Debian Buster "client max protocol = NT1" in smb.conf global section was needed to see all smb servers (older smb servers included). After setting this Dolphin and smb4k worked fine enough again. In Debian Bullseye this is no longer the case: Dolphin works fine without "client max protocol = NT1" and stops working when protocol is forced to NT1. smb4k does not find shares with or without NT1 inplace. Shipped version in Bullseye is 3.0.1 - it not longer allows to switch between nmblookup or net...
-
In Debian Buster "client max protocol = NT1" in smb.conf global section was needed to see all smb servers (older smb servers included). After setting this Dolphin and smb4k worked fine enough again. In Debian Bullseye this is no longer the case: Dolphin works fine without "client max protocol = NT1" and stops working when protocol is forced to NT1. smb4k does not find shares with or without NT1 inplace. Shipped version in Bullseye is 3.0.1 - it not longer allows to switch between nmblookup or net...
-
In Debian Buster "client max protocol = NT1" in smb.conf global section was needed to see all smb servers (older smb servers included). After setting this Dolphin and smb4k worked fine enough again. In Debian Bullseye this is no longer the case: Dolphin works fine without "client max protocol = NT1" and stops working when protocol is forced to NT1. smb4k does not find shares with or without NT1 inplace. Shipped version in Bullseye is 3.0.1 - it not longer allows to switch between nmblookup or net...
-
In Debian Buster "client max protocol = NT1" in smb.conf global section was needed to see all smb servers (older smb servers included). After setting this Dolphin and smb4k worked fine enough again. In Debian Bullseye this is no longer the case: Dolphin works fine without "client max protocol = NT1" and stops working when protocol is forced to NT1. smb4k does not find share with or without NT1 inplace. Shipped version in Bullseye is 3.0.1 - it not longer allows to switch between nmblookup or net...
-
well, I don't have much time with the merge window closing soon so, there goes nothing ... I filed for a version bump in debian/testing and hope they also consider your patch and give you credits for it. Thank you Thomas for helping me out once again!
-
Update: tested against fluxbox.git: unpatched git was showing the same symptoms in vlc, kwrite, konsole and the proposed patch fixed it good enough. Are you committing this to git? I'd like to try my luck with a late Debian Testing patch suggestion. The current debian testing version is 1.3.5 - that's kind of old anyway - we should try to get this patch in for bullseye with v. 1.3.7 if you're okay with it.
-
thank you, works fine now.
-
Unable to clone fluxbox.git repo
-
I could apply it to 1.3.7 and it almost works! When you reopen vlc after it was closed maximized, it still won't let you un-maximize, but it does clear the geometry tag. So the next time you open vlc, it will follow the fluxbox-app ruleset again. May I recommend for you to spot the expected behaviour with Gimp (a gtk app)? I assume you have it installed? Gimp is behaving exactly like expected: reopen maximized, allow to un-maximize to the state it was before you clicked maximize. From then on re-open...
-
I will try to build your patch against version 1.3.7 then, so I can confirm it has the desired effect.
-
So you can reproduce it now using vlc?
-
vlc does it indeed different because it is not a kde app: you have geometry=@ByteArray=CODE definitions in ~/.config/vlc/vlc-qt-interface.conf. The relevant one is on line 4, it controls main window size. Remove it and fluxbox-apps can set size correctly again. Okay, if vlc is the only app you have using QT5 menu dekoration, let me write steps to reproduce the problem and how to recover once it happened: Add this and only this to ~/.fluxbox/apps so we use the same setup: [app] (name=vlc) (class=vlc)...
-
vlc does it indeed different because it is not a kde app: you have geometry=@ByteArray=CODE definitions in ~/.config/vlc/vlc-qt-interface.conf. The relevant one is on line 4, it controls main window size. Remove it and fluxbox-apps can set size correctly again. Okay, if vlc is the only app you have using QT5 menu dekoration, let me write steps to reproduce the problem and how to recover once it happened: Add this and only this to ~/.fluxbox/apps so we use the same setup: [app] (name=vlc) (class=vlc)...
-
Run tests against an empty apps file and the problem remains: Window-Maximized tag is not cleared by un-maximize, but it is cleared by minimize or fullscreen.
-
xprop -spy _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ, That's what it says, the window was already vertically maximized by fluxbox-apps. What fluxbox prevents is clearing the Window-Maximized Tag in qt5 apps, please test against kde konsole,kwrite, vlc with qt5 gui. They all don't remove the tag when you click un-maximize, but they remove it immediately when you minimize or fullscreen those apps. In Openbox,plasma and xfwm they remove it the instant you hit un-maximize.
-
Downforce the app with a [Maximized] {no} entry : This still works fine in Debian 10 Buster, it has never worked in upcoming Debian 11 Bullseye, no idea why that is.
-
No, it's a size issue, not a placement issuse: most apps seem to register a maximized state immediately in their respective config file, if you close them maximized, they restore itself maximized when you open them next. That's considered a feature these days ... even all the browsers I tested do it. The difference to qt5 behaviour under fluxbox is the following: The Window-Maximized tag should get erased immediately (even before closing) once you click the un-maximize button. This does happen with...
-
Hello, did some more testing in the meantime and observed how other window managers like xfwm or openbox are handling qt5 apps: they both immediately clear the Window-Maximized tag as soon as you click the maximize button one more time. Window size also reverts to how it was before. That's the expected behaviour IMHO, but none of them offers windows size management as sophisticated as fluxbox does :-(
-
To answer you question whether qt5 settings should have the final word or not on geometry or positioning: I always thought it was fluxbox-apps so an app that tries to position it somewhere different or open it in a different size that would be ignored by fluxbox? You can even spot this sometime if you for example open firefox-esr, it might for a second open on the left side, but then immediatly move to the right side with a statement like [Dimensions] {50% 100%} [Position] (UPPERLEFT) {50% 0%}
-
Sorry, that printf statement has no effect in Buster or Bullseye kde konsole. VLC player has a qt5 user interface as well and this is basically the only app I often use in fullscreen. VLC is affected by maxi problem as well and people like to use it in fullscreen, other apps don't matter that much. It would be nice to have a qt5 setting maybe in ~/.config/kdeglobals ,that would just tell all qt5 apps to stop re-open closed windows in maximized state :-( This maximize tag should only be set like ...
-
Oh boy, sorry Thomas to bother you with this one more time, but did you happen to test Debian Bullseye? I just did and kwin is acting up in new ways with the app ruleset: Now the max statement inside qt5 ~/.config/rc files is written like this: HDMI-1 Window-Maximized 1080x1920=true and your nifty trick of [Maximized] {no} has no more effect! :-( So basically the only help is go fullscreen (f11 in many cases) and back with your qt5 application - this still works as it does erase the maximization...
-
Hello Thomas, I finally had the time to test this more thoroughly and [Maximized] {no} seems to do the trick, Thank you. One thing that worked as well is force the window into full screen mode and back (usually F11 but it depends on the app).
-
close kde app maximized does always reopen it fully maximized
-
Sorry that's not it. Some background task must be occasionally crashing without me noticing. If I login again the issue is gone for while until it reappears. I can't really say whether it is qt5ct or some other background task dolphin is using. All I can say is this: when it appears calling kwrite from the terminal is still running fine with qt5ct.
-
That's already set in Debian using /etc/X11/Xsession.d/99qt5ct. I see it using the env command.
-
Wrong theme when kwrite is opened with dolphin context menu
-
solved! that was all me inadvertantly setting the double click interval to 100ms without noticing the negative effect. Setting it back to 400ms and double clicks work fine.
-
Double Click not working
-
Debian/Linux qt5 builds no longer show the tray icon
-
just build 1.2.2 stable and this appears to be not fixed: no lookup possible using...
-
click to play for html5 videos
-
display composer tag as upnp:author
1