search

TiZ-HugLife / xfce4-dockbarx-plugin

A plugin that embeds DockbarX into Xfce4-panel
MIT License
70 stars 14 forks source link

Max size #8

Closed M7S closed 10 years ago

M7S commented 10 years ago

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.

Is there some sort of maximum items option or something like that which I can expose to the panel plugin, and make it user configurable?

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?

TiZ-HugLife commented 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.

wp9015362 commented 10 years ago

Related:

https://github.com/TiZ-EX1/xfce4-dockbarx-plugin/issues/5#issuecomment-46248193 https://bugs.launchpad.net/dockbar/+bug/1331820 https://answers.launchpad.net/dockbar/+question/250432

TiZ-HugLife commented 10 years ago

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.

wp9015362 commented 10 years ago

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

M7S commented 10 years ago

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.

wp9015362 commented 10 years ago

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

M7S commented 10 years ago

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.

TiZ-HugLife commented 10 years ago

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.

TiZ-HugLife commented 10 years ago

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.