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

List:       kde-usability
Subject:    Re: kcontrol
From:       Benjamin Meyer <ben+kdeusability () meyerhome ! net>
Date:       2004-07-26 7:59:59
Message-ID: 200407260408.00653.ben+kdeusability () meyerhome ! net
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 26 July 2004 12:05 am, Jamethiel Knorth wrote:
> >From: Benjamin Meyer <ben+kdeusibility@meyerhome.net>
> >Date: Sun, 25 Jul 2004 21:54:00 -0400
> >
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >Rather than being just another complainer person who says "KControl sucks
> >and
> >needs to be better" with nothing constructive to add, I have put together
> >some things first.
>
> Great.
>
> >Based somewhat on the already constructed changes by this mailinglist
> >contained in kdebase/kcontrol/TODO I have written up first a doc
> > specifying the basic grouping along with explanations of what/why.  This
> > type of doc never seemed to have existed before which is part of the
> > problem for the constant kcontrol changes in the past 7 years (as far
> > back as I know)
> >
> >http://www.csh.rit.edu/~benjamin/kcontrol4/kcontrol4.html
> >
> >At the same time I played using QtDesigner and a little code and made a
> >mockup
> >application:
> >http://www.csh.rit.edu/~benjamin/kcontrol4/screenshots/mockup.png
> >
> >Then I actually sat down and fleshed it out quite a bit more to the point
> >where it does actually load the kcontrol modules on your system.
> >
> >http://www.csh.rit.edu/~benjamin/kcontrol4/screenshots/
> >http://www.csh.rit.edu/~benjamin/kcontrol4/kcontrol4.tar.bz2
> >
> >You can compile it yourself and check it out.  It works just enough to
> > play with the system, but probably wouldn't take much more to finish it
> > off.
>
> I'd love to do so, but can't get to Linux for a while, as I'm on vacation
> for another pair of weeks or so. As such, my comments will be based
> entirely on your page and may be completely off-base. If they are off-base,
> I sorry for bothering you with them.
>
>
> I actually did a somewhat similar design for the overall layout
> (http://www.csis.gvsu.edu/~abreschm/designs/the-control-panel/images/contro
>l_center.1.png and
> http://www.csis.gvsu.edu/~abreschm/designs/the-control-panel/images/control
>_center.2.png) not too long back, although I only made mock-ups as I cannot
> program very well. What I was trying to work around, only partially
> successfully, are two things which I still see as problems in your design.
>
> First, the control panel is extensible, no matter how bothersome that may
> be. There must be allowances for third-party modules to be added. I did not
> see it addressed in your design document where such additions would go if
> they did not fit into the current areas. For example, what occurs if  there
> are too many icons in a single row to fit into the width of the window?
> Although that likely won't be an error yet, it should be prepared for.

Well in my app each of the three main groups are contained in kiconview's, but 
if you have more items then will fit on the screen the "row" will simply be 
twice as tall with one item on the second row.  Scrollbars are added as 
needed to fit the app withing the size specified.  In the source if you 
change in mainwindow.cpp "KServiceGroup::baseGroup( "kcontrol4" );" to 
"KServiceGroup::baseGroup( "settings");" you will get all seven groups each 
with 15 items etc as it is presented in today's kcontrols and you can play 
with the overflow.

> Second, you seem to be using a multi-window approach. I am strongly against
> that for many reasons. Many users are confused by a new window appearing
> once they want to return to the original one. Closing the new window seems
> risky to some people, and it can cause many issues. If that cannot be
> worked around, I don't think there will be as large an improvement in
> KControl as some of us hope. Even if it does get much cleaner, it will have
> introduces new problems into the mix at the expense of the old ones. That
> isn't to say that it needs to be single-window, but I would strongly
> recommend trying for a single-window approach.

There is no technical reason why not.  I ended up not going with an all in one 
window app for two reasons:

1) Because the initial window has about 12 items on it (vs 50 or so in other 
designs) you will have at most 12 windows open assuming you opened every 
single one.

2) But more importantly I didn't know where to put the "go back to viewing 
everyone" button.  The only thing I could think of was putting it in the 
"View" menu, but that seemed combersome.  A fourth menu could be added kinda 
like you have, with a "Show All"... , but that leaves a lot of space...  feel 
free to suggest something better.

> As far as other comments on the design, I think that 64x64 is larger than
> the icons actually need to be. When I was doing a mock-up of my design,
> 48x48 seemed to be plenty large enough. 64x64 is very large, and only fits
> into a reasonably sixed window if the spacing is fairly small. I would
> rather see wider spacing, so that a user has more rest area for their eye.
> A dense window can be hard to look through, even with relatively few
> options in it.

64x64 was just my random pick.  Some kcm modules like launch only have 16x16 
at this time fyi.  This of course would be configurable in the View menu like 
today's with probably a default of 48

> >I guess the work I have done present two things:
> >
> >1) A (sort of) formal doc that can be used explaining where modules go. 
> > As far as I know know one has bothered to write up something like this. 
> > Feel free to point me out as wrong. (no, mailing list archives don't
> > count)
> >
> >2) A different way of looking at kcontrol.  Someone said it looks like
> >something from winXP, but if so that was not intensional and entirely
> >accidental.
>
> Actually, it looks a lot like the Mac OS-X control panel, which is not a
> problem. However, the Mac OS-X control panel has some of the same problems
> you have. In fact, if the screen is at a low enough resolution (I think
> 800x600 does it) it is technically impossible to reach some options on the
> control panel due to the combination of it having a fixed size and Mac OS-X
> not allowing windows to be moved above the top border of the screen.
> (That's as of 10.1, they may have fixed this since then). 800x600 may be
> rare, but the issue still exists with that particular design.

Well there is allways the menu with View/module/foo :D and smaller icons and 
change views from a icon view to a list view.  My demo app fits in 800x600 
and with smaller icons fits much smaller size.

- -Benjamin Meyer 

- -- 
aka icefox
Public Key: http://www.csh.rit.edu/~benjamin/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBBLve1rZ3LTw38vIRAvcCAJ4jiZx6J7UFqrgIJajIQnzseh3tJQCfXtkz
GUxg0pCu8aMHQOTRCGEH+kw=
=1o0e
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]