Possible panel tweaks (Was: Re: Random thoughts about release)

[Jasper Huijsmans]

Hey,

On Tue, 8 Jul 2003 14:22:50 -0700 (PDT)
Ric <fhj52ads at yahoo.com> wrote:

> Hi:
> 
> I'd like to preface this(in retrospect) with I luv what has
> been done so far with XFce. Y'all are great.
> 

I love you, but you all suck ...

> 
> Revert is the only way to "revert".
> Actually, clicking the "Close" button in the top right
> corner(usually) should have the same effect as 'Revert and
> Close without changes' but it does not when a *new* item is
> being added - it leaves the (empty) item on the panel.  If
> you (eventually) remove the "Revert" functionality, at
> least make it so that 'close' utton just stops the action
> and removes any *new* panel item.
>  Also, IMO, the "Close"
> button should have the same effect as "Revert" and then
> "Close" when making changes to an existing item. That
> action is normally interupted in other programs with a
> "Lose Changes?" redundant popup which I personally hate -
> please do not add another popup when/if you fix the Close
> button on the window to be "Revert" and "Close" and, also,
> "Remove" if it is a *Add new item*.
> 

You shouldn't look at it like that. If an item is being added, it is
added immediately. Then the panel conveniently opens a properties dialog
so you can change its options. If the options are alright, you close the
dialog, if you decide you don't want it, you remove it. It is all there
in the dialog.

The window close button on the dialog should do no magic, it closes the
dialog without doing anything. Because we are using instant-apply
dialogs, your changes are already applied and pressing the window close
button will not change that.

> 
> > > > Of course I will have to only hide it, otherwise I
> will
> > > > cause API change
> > > > for plugins. For 4.2 I can then really rip out the
> > > > functionality.
> 
> Also, I will remind you of the pal to KISS: 
> " Do not fix what is not broken. "
> (It ain't broke, so leave it alone).
> 

Please don't try to be a smart-ass if you don't have anything to back it
up. Why are you assuming that if I want to change something it is
without reason?

In my opinion as the panel maintainer and designer of that API, it _is_
broken. It is a not too useful feature which makes implementations of
panel item dialogs far more complex. It is a simplification. Surely, you
who say you live by KISS rules can appreciate that.

[...]
> 
> That tooltip is a good thing when it is used properly. 
> FYI: "Including the kitchen sink" is not utilizing it
> properly; it's cute for those that 'get it' but is not
> useful for anyone new to *nix on the desktop or,
> especially, those new to computer usage.  Using " emacs is
> a text editor and much, much more " would be helpful(there
> are other (prbly better) tips that could be used...).
> 

I have repeatedly asked for people to please take a look at the default
configuration and send me improvements, because I can't seem to find
the time to do it. We are only with few, help out if you can. 

> Tooltips are not very useful for _experienced_ people only.
>  Please rem that Linux and other *nix on the desktop are
> far from being well known/used.  The thing that it will do
> to help developers is, when used properly, keep the mailbox
> from getting messages from users that click on something
> and get a surprise that they do not know how to use (or
> kill) or, even worse, the "What is emacs?" type questions. 
> That, in of itself, is a good reason to have "Tips". Of
> course, tips is a 'nice' thing to do, too, for the end
> user("Oh yea, _now_ I remember what that is...").
> 

lol, are you trying to explain to me what tooltips are?

> 
> Jasper, 
> if you need something to do:
> Whenever the pager is displayed in a horizontal panel, the
> very last page  is longer than all the rest. (note that it
> does not matter if there is anything on that workspace)  My
> monitor does not grow horizontally on the last workspace...
> 

Thank you, I never noticed that. It probably has something to do with me
no taking into account internal borders when calculating the size.

> 
> An addendum to that is that if the panel grows beyond the
> width of the screen there are no hooks to move it around
> except at the ends. You can only reach one of those but, of
> course, cannot move the panel beyond the screen border
> using it. This is a difficult problem& solution which can
> only be solved with new code that would presumably only be
> the next release: you can: (1)State: " Sorry, panel is
> full! " /(2)Ask: "Grow panel beyond borders? " /(3)fix the
> hooks so the panel can be moved by clicking on the (center)
> borders /(4) ???
> 
> Also, I will add that the panel requires manual centering
> after an addition (or "Remove") is "Done". It should auto
> center or at least provide a check box option to
> auto-center the panel, IMO. Furthermore, if the panel is
> larger than the screen size, "Center" does not _center_ the
> panel on the screen at top, bottom, lft or rt.(that's a
> good thing since there no hooks to move it if the ends are
> obscured)
> 
> Also, the options for the panel in the settings manager
> _always_ revert to   "Center: Bottom".  They should, IMO,
> keep whatever the previous user defined setting might have
> been.  The remember state is not implemented or if it is,
> it is broken(here).
> 
> Furthermore, when panel "Orientation" is set horizontal and
> "Center" is "Left" or "Right", the panel gets put
> dead-center in the middle of the screen; when panel
> "Orientation" is set Vertical and "Center" is "Top" or
> "Bottom", the panel gets put dead-center in the middle of
> the screen too.  Not good, IMO. 
> 

Agreed, current movement and position related behaviour is not very
good. Definitely on my after 4.0 list.

> AND, when the panel is in 'Hide' mode and is UN-hidden,
> with "Normal" layer setting, it does not go to the top
> layer until the user clicks on the panel.  Ask yourself, if
> a user moves the mouse pointer to UNhide the panel, why,
> for goodness sakes, would the user _not_ want the panel on
> the top layer without having to also click on the panel??
> Rem that clicking on the panel _after_ UNhiding it is not
> necessarily intuitive; it is a learned  response.  Yes,
> there are mousing glitches to consider but that is a timing
> issue not a layer issue.  

You seem to think every behaviour of the panel is a conscious decision.
Well, I have news for you, it is not. Naturally I can agree with you,
but come on, cut me some slack here. Window management issues are
usually not that straightforward.

> And while in that thought, an addendum is: where is the
> Settings Mgr/Panel setting  'Timing settings' for the panel
> hide/unhide or for the popup tips or for the launcher/menu
> items???
> 

Again, the tone of this question is not very nice, is it?. Ask yourself
if you want to help out or just piss me off. As for the answer, options
are not solutions to a problem. Do you think it is not working
correctly? Or do you really believe it is a useful feature to be able to
choose the hide timeout? I will disagree with that.

> And if that is not enough, I can come up with more. 
> For example, the "Add new item" has "Systemtray".  It
> should be "System Tray", right? 
> "Volume Control" does not need an icon(the "volume control"
> slider is enough) _or_ the item should be called "Mixer".  
> " Mail check " is really "Mail Checker", is it not?

You should have mentioned that earlier. These are all translated
strings, so cannot be changed before release.

> " Help " on the _panel_ rt-clk should open XFce4 doc at the
> "Panel" section, whereas "Help" lft-clk on the workspace
> opens the XFce4 Help doc at the contents, correct? 

I don't think so. I think they should be alternative ways to reach the
documentation. I don't have a strong opinion on it though.

> The " Browser " tooltip for "mozilla" is misleading.
> Mozilla is not just a browser, it's a monster too. :)  You
> can fix that on most systems by using 
> /bin/sh -c $BROWSER
> instead of "mozilla" in the command line.  Yes, there are
> systems that do not have the env variable $BROWSER set (or
> set properly) but I will bet a dime to a dollar that it is
> fewer than those that do not use mozilla.

Please help out creating a good default config.

>  At the very
> least, wherever a specific browser is used, use the
> standard icon associated with the browser.  
> Note that the "Help" widget needs to do the same thing - at
> least try to find $BROWSER on the system before assuming
> mozilla is installed. (Unless y'all actually want XFce4 to
> depend upon("Require") mozilla being installed...)
> 

xfhelp4, the script used for opening help pages does use the BROWSER
variable.

> (More: two desktop switchers in the same panel? ;  2 pagers
> in the same panel?

I could make them unique ... Not very important though.

> clock will not go into the system tray

Nor should it. It is not a notification icon.

> (would be nice 'cause it could then display in the
> taskbar too if 'Show system Tray in taskbar' is selected) ;

If you want a clock in the taskbar, ask for that ... 

Personally I think it would be cool if the taskbar would become a status
bar able to contain all kinds of monitors and other dynamic stuff like
a clock.


>  at some point the list of items in "Add new item" could be
> so long that it is off the screen - maybe a subcategory or
> two s/b considered now(plugins, toys, extras...) or a way
> to scroll the list if it is at the bottom of the screen...

It's a gtk menu, it will scroll.


I'm sorry I got annoyed, it's probably just me.

Thanks for the input,

	Jasper