[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kcontrol patch #1
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2001-03-27 5:18:55
[Download RAW message or body]

Hi Carlo,

I have some concerns with some of these suggestions as well. Hope you do not mind me \
commenting on them since I did not follow the discussion on kde-devel...

On Monday 26 March 2001 16:51, Carlo Robazza wrote:
> Hi there,
> 
> I have five patches to kcontrol that I will be posting to this email
> list. I have had to split the work I did into separate patches for each
> feature. The original discussion of these features took place in
> kde-look but I was asked to post the patches to this list for further
> discussion.
> 
> 
> Patch #1
> ------
> 
> I have removed the Help tab. Help is still available through each
> module's help button. This brings up a dialog box with the help
> information.

I fail to see how popping-up a dialog box would be a better choice in
this case...  In fact it makes it is IMHO slightly worse.  Perhaps an illustration
will my make my view a  bit clearer:

User A needs help filling out or settings some value in a certain control
panel module ; so (s)he clicks on the Help button and they get a popup
dialog.  User A then proceeds to  read the info and closes or minimizes
the popup dialog.  Now if (s)he wants to refer to this help again, (s)he
would have to bring up the dialog box and repeat the whole process.  This
would result in at the least three mouse clicks to switch back and forth
to read this info as needed.

Compare this with the current format where one only needs to click on the help
TAB ONCE to display the help or description info available all the time.  The only
inconsistency I see here is that the "Help" button and the "Help" Tab do not do
the same thing!  IMHO this is what needs to be fixed not the removal of the help
tab.

My suggestion, well actually my personal preference is perhaps the right term,
would be to leave the help TAB as is or hide the tab and when the user presses
the help button show that tab if it is hidden or bring it to the front if not.  This
would make the information easily accessible to the user while (s)he is manipulating
the desired entry.  Then all that is required of them to access the help text would \
be to click ONLY ONCE on the help button and the occasional glance or glare :) at \
this text for assistance as needed.  This IMHO is much more intuitive approach than \
the previous one, isn't it ?

> Patch #2
> ------
> 
> I have removed the Search tab and replaced it with a Search button. The
> search button then brings up a dialog box. Unfortunately, the process of
> splitting out the patches has slightly broken this feature in that the
> search list isn't populated. It worked before and I can't figure out why
> it doesn't now. Perhaps someone could take a look at it and figure out
> why.

Similar issue here as well.  The first question that popped-up in my mind is why an
extra dialog box ? In the least, if you want to get rid of the tab to simplify things
why not simply marry the search and the index tabs into a single one ?  Add a search
button along with a klineedit (as sketched below) either at the top or bottom of the
index tab would allow the user to search for the available entries and when the user
selects one, it would be displayed and the the module listing tree would simply have
to be synced.  Wouldn't this approach be the easiest path ?  You can completely
replace the content list that gets adjusted in the search tab with the completion \
mode of the lineedit itself which now has a popup completion mode.

> Patch #5
> ------
> 
> Display a list of the modules under a category when a category is
> selected. This uses a modified AboutWidget that lists the Category and
> sub-modules when a category is selected. If a category is selected after
> changes were made to a module, the standard message box pops up to let
> the user accept or forget their changes. There is one minor bug with
> this that I haven't been able to figure out which has to do with
> resizing the AboutWidget when a category is selected. If a category is
> selected after a module, then the resizing is correct. If a category is
> selected on startup or after another category, there is a resizing
> problem. However, resizing kcontrol as a whole by dragging an edge
> causes a proper resize.

Hmm... I actually think this is a good idea, however what happens when a module
that belongs in that category gets loaded ?  Does it display its own info ? One of \
the most important things missing from the control panel is an explanation of a \
particular module directly in the display area.  This was replaced with the help TAB, \
but IMHO that is not intuitive for the end-user.

Regards,
Dawit A.


[prev in list] [next in list] [prev in thread] [next in thread]