Closed M7S closed 10 years ago
I think you made the right call opening a new issue. :)
The optimal solution isn't really feasible in xfce panel. The plugin API (at least through Vala) only allows the plugins to know about the particular space belonging to them. That's why you have to configure the background manually.
Right now, I'm not using set_max_size at all, and with the widget set to expand, it works as expected. So in order to replicate the old behavior that allows it to grow as much as it wants to, I'm guessing I could set_max_size to something absurdly high. This is probably a good configuration option to expose anyways.
DockX is doing it too? Interesting... in that case, whatever fix is implemented there can also be implemented here. Or it could simply be an upstream issue entirely.
Hello,
DockbarX now seems to be on GitHub and M7S made a new release (0.91.1) with a fix for this issue, see:
https://github.com/M7S/dockbarx https://github.com/M7S/dockbarx/releases
;)
Regards
No. Dockbarx 0.91.1 does not change anything for xfce plug. It only affects DockX.
On June 19, 2014 1:52:42 PM EEST, wp9015362 notifications@github.com wrote:
Hello,
DockbarX now seems to be on GitHub and M7S made a new release (0.91.1) with a fix for this issue, see:
https://github.com/M7S/dockbarx https://github.com/M7S/dockbarx/releases
;)
Regards
Reply to this email directly or view it on GitHub: https://github.com/TiZ-EX1/xfce4-dockbarx-plugin/issues/8#issuecomment-46546825
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hello,
M7S wrote:
No. Dockbarx 0.91.1 does not change anything for xfce plug. It only affects DockX.
thanks for the info.
But can it be fixed for the xfce4-dockbarx-plugin as well?
It would be much appreciated.
Regards
TiZ-EX1, I propose you set max_size to something absurdly high when expand is off and keeping max_size at None when expand is on, if you don't want to dabble with exposing the max_size option to the users right away. That way we could get a quick fix version out that as quickly as possible that fixes all(?) known bugs.
I guess this is what DockX does? Sounds fine to me. :P But I might as well expose the option while I'm at it. I'll get started right now.
Okay, all good! There is now a max_size property for the plugin exposed through the configuration dialog. If you set it to 0, the plug will set_max_size to 4096. So you can restrict the size of the plugin if you want. But by default, it's set to 0 in order to replicate original behavior.
Only problem is, now when you set_max_size to None, it restricts itself even more harshly than before even with expand on. So I just made it use the defined max_size in all circumstances. It's dirty, but it works; it doesn't push other panel plugins out or anything. Hell, in retrospect, I don't need to have the plug object giving a crap about the expand property at all anymore because of this, but I'm lazy so I left it in because it doesn't hurt anything.
I'm opening a new issue, even though I'm not sure if that's what you do on github or if I should answer this question in the now closed issue where you asked it.
There's a command dockbar.set_max_size(max_size) that can be used to set the maximum size in pixels that DockbarX is allowed to take up (including the arrows). If the max_size value is None, DockbarX will use the size of it's container as the max size.
The optimal sollution would be if there is any way to find out the combined size of all non-extended panel applets and subtract that size from the screen size to set max_size, that's what DockX does. I guess that's not an option in this case, you probably cant tell the size of other panel-applets from within a panel applet in Xfce?
So I guess the best option is to set max_size to None (default) when expanded mode is used and setting it to a user controlled value when not in expanded mode?