Greetings. The panel doesn't seem to handle some plugins very well when it's vertical. In particular: xfce4-datetime gets cut off oddly. I know there is a bug 3888 about the tasklist plugin. I'm not sure what the solution here is. ;( - Just keep cutting them off and people can resize them. - Always make the panel grow to the size to show them, and folks will need to remove them to make a smaller panel. This may cause confusion on why the panel can't be shrunk. - Remove plugins that don't show correctly when a vertical panel is set. People might be confused that they don't show up however. Thoughts? This is from Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=509758
Not a problem of the panel. We did this on purpose for point 2 you've mentioned (panel should always scale to the defined size), removing plugins is even worse (from a technical point of view we can't even do that reliable). So file bugs against the plugins that have problems in vertical mode.
I'm an initial reporter of bug in Fedora. I'm use it from XFCE4.4 and was happy. Now, you broken this. Off course user settings of panel size shouldn't be silent ignored if plugin greater, but what you did is also not solution! So, as resolution possibilities I seeing few variants: 1) Give users separately set width and height of panel, not only 1 size. Really, in my example I want see small buttons, not as elephants, and I want also place there full date. 2) Inform user what their settings will be ignored "because plugin XXX required more space" and return old behavior.
For point 1, duno if I understand you correctly here, but if you want separate width and height settings for each plugin: hell no. Like I said in my first comment, we cannot fully rely on the plugin's sizes and warnings like this will only result to confusion. The reason why we simply force plugins in a size (actually; only the width on vertical panels and the height in horizonal ones) has 2 reasons. First ANY widget implementation should always respect the size send through allocation. It can request any size it needs, but if the panel says your allocation is 20x20 pixels it should make sure everything fits in that area. Secondly let's say the panel size is 20, and 1 plugin needs a size of 25 pixels, what do we do with the other plugins? Keep them 20px which will result in fuzzy icons, weird button sizes etc, or (after fully allocating the panel), resize again, because we noticed 1 plugin needs a bigger size. This will result in a flickering panel and a possible infinity loops (because a plugin could have a 1px larger size then allocated due to wrong calculations), the panel will grow and grow and... until you see nothing but panel. So I hope you understand the panel should be a bitch in this case and simply force plugins to respect its size. Up to the plugin to obey this and because some plugins don't do this or are not designed to run in a vertical panel they could look ugly. That is sad, but not the panel's fault.
(In reply to comment #3) > For point 1, duno if I understand you correctly here, but if you want separate > width and height settings for each plugin: hell no. > > Like I said in my first comment, we cannot fully rely on the plugin's sizes and > warnings like this will only result to confusion. > > The reason why we simply force plugins in a size (actually; only the width on > vertical panels and the height in horizonal ones) has 2 reasons. > First ANY widget implementation should always respect the size send through > allocation. It can request any size it needs, but if the panel says your > allocation is 20x20 pixels it should make sure everything fits in that area. > Secondly let's say the panel size is 20, and 1 plugin needs a size of 25 > pixels, what do we do with the other plugins? My point there old (may be modified) behavior: All should try fit in 20px, but if they can't, panel must be increased to plugin minimal allowed dimension. And especially want note, thus plugins who can be fit to user-desired size must do that (NOT also be increased to new panel width, or, at maximum it is also should be tunable). Also will be cool provide alignment (left/center/right for vertical panel and top/middle/bottom for horizontal) in this case for elements they size appeared less than result size of panel, but center/middle (as it was) I think is good start. Additionally, as you can see this scheme exclude ugly errors and unusable plugins, as I have now (on screenshot). So, if I add plugin, they increase panel width and I don't desire it, I can remove it or tune, until I do not make decision what is good for me. In current scheme I do not have any such capability at all and only see broken plugin/panel.
Increasing the panel size is simply not an option, if you don't understand that from my previous comments, then you probably refuse to see the whole picture. Fill bugs against orage and whatever plugin that is not working properly. They should rotate the text or decrease the size, whatever needed to fit in the allocated area.
(In reply to comment #5) > Increasing the panel size is simply not an option, if you don't understand that > from my previous comments, then you probably refuse to see the whole picture. Yes, may be I don't compleatly understand implementation problems there... Sorry. But it was in previous releases. Was there bugreports, problems or etc, why you change it?? > Fill bugs against orage and whatever plugin that is not working properly. They > should rotate the text or decrease the size, whatever needed to fit in the > allocated area. The main reason why I don't do that until now - I think it is not solution! I absolutely don't want see full date-time in 20px... Really, it would be font size around 2-3pt and unreadable! But in current situation I also absolutely can't use such plugin in my vertical panel.
(In reply to comment #6) > (In reply to comment #5) > > Increasing the panel size is simply not an option, if you don't understand that > > from my previous comments, then you probably refuse to see the whole picture. > > Yes, may be I don't completely understand implementation problems there... > Sorry. But it was in previous releases. Was there bugreports, problems or etc, > why you change it?? Not sure it was a bug report or a discussion on the ml, but some plugin developers complaint that their plugin started to look weird because another plugin did not respect the allocated plugin/panel size. So right now 1 plugin looks weird, in the other case n_plugin - 1 look strange. > > Fill bugs against orage and whatever plugin that is not working properly. They > > should rotate the text or decrease the size, whatever needed to fit in the > > allocated area. > > The main reason why I don't do that until now - I think it is not solution! I > absolutely don't want see full date-time in 20px... Really, it would be font > size around 2-3pt and unreadable! But in current situation I also absolutely > can't use such plugin in my vertical panel. Maybe the plugin is not suitable for a vertical panel (like the verve plugin), that is something you should accept i think or you change the date format of the plugin to put the text in 3 or 4 rows.
(In reply to comment #7) > Not sure it was a bug report or a discussion on the ml, but some plugin > developers complaint that their plugin started to look weird because another > plugin did not respect the allocated plugin/panel size. So right now 1 plugin > looks weird, in the other case n_plugin - 1 look strange. So no bugs before, is now (as minimum this). > Maybe the plugin is not suitable for a vertical panel Maybe, maybe... But I suggest provide this decision for user... As you think? > (like the verve plugin), You will be surprised, but I much time using verve plugin (as shown in screenshot) there. It found it very usefull placed near after main menu. And width around 10 characters was enough for most commands... And again, it became less useful now :( > that is something you should accept i think or you change the date format of > the plugin to put the text in 3 or 4 rows. DateTime plagin do not allow it now. And in any case, it will look strange date like: 2009 09 24 15 : 13 : 47 ??? Ok, as summary you have 2 implementation old and new. It is very hard provide choose to user in settings what desired???
(In reply to comment #8) > (In reply to comment #7) > > Not sure it was a bug report or a discussion on the ml, but some plugin > > developers complaint that their plugin started to look weird because another > > plugin did not respect the allocated plugin/panel size. So right now 1 plugin > > looks weird, in the other case n_plugin - 1 look strange. > So no bugs before, is now (as minimum this). Like I said, it was either a bug or a discussion with other plugin developers, probably the latter. > You will be surprised, but I much time using verve plugin (as shown in > screenshot) there. It found it very usefull placed near after main menu. And > width around 10 characters was enough for most commands... And again, it became > less useful now :( > > > that is something you should accept i think or you change the date format of > > the plugin to put the text in 3 or 4 rows. > DateTime plagin do not allow it now. And in any case, it will look strange date Mm i thought it was capable to using markup too, maybe \n works... > Ok, as summary you have 2 implementation old and new. It is very hard provide > choose to user in settings what desired??? Esp. not desired, the option has no meaning at all if all plugins work as expected. The old implementation was a mistake in the panel design some plugins abused. You probably got used to that flaw. I'm not going to change it, I'd rather spend my time to fix the plugins that have a problem atm.
(In reply to comment #9) > Mm i thought it was capable to using markup too, maybe \n works... No it is not. I try "Custom" variant with '%Y\n%m-%d' it does not work. In any case, example on date before is very strange. What you think? How you can imagine verve plugin multi-lined??? > > Ok, as summary you have 2 implementation old and new. It is very hard provide > > choose to user in settings what desired??? > > Esp. not desired, the option has no meaning at all if all plugins work as > expected. Desired. It is highly desired by me, and I think many (ok, some) other peoples. It is not problem name option like 'Behavior when plugin greater' or something similar. The old implementation was a mistake in the panel design some plugins > abused. You probably got used to that flaw. > I'm not going to change it, I'd rather spend my time to fix the plugins that > have a problem atm.
Why you do not want find compromise and made you product better for users? Especially for thus, who use it long time...
Contact the respective plugin developers if their plugin is not suitable in a vertical panel. I'm spending a lot of time in making the default plugins work flawless in a vertical panel (including clock and tasklist), that's all i can do (you can already see a bunch of that in the devel branch of the panel and you'll see the complete result in 4.8).
(In reply to comment #12) > Contact the respective plugin developers if their plugin is not suitable in a > vertical panel. Why you think developer must make decision suitable plugin for one or anoyher plugin or not? Why it can't do user, as it was in 4.4 version?? Where freedom?
I already explained this this problems for other plugins who try to respect the panel size. I'm done discussing about this, all I can promise is a panel in 4.8 that works a lot better in vertical mode.
(In reply to comment #14) > all I can promise is a panel in 4.8 > that works a lot better in vertical mode. Glad to hear it. I will wait with impatience.