UI polishing: config dialogs

Sam S. smls75 at gmail.com
Fri Jan 1 16:47:37 UTC 2010


On Fri, Jan 1, 2010 at 12:18 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> [...]
>>          - "*Schedule all project files for parsing*" checkbox
>>             - should be moved to "Background Parser" page
>
> Why?

Short answer: because that's where one would look for it.

Long answer:
Because it is part of defining the behaviour of the background parser,
and the "Background Parser" configuration page is the central place
for defining this behaviour.

If I understand it correctly, there are three behaviours you can
currently specify for the source file parser:
 a) no parsing
 b) automatic parsing of all open files, and files included by them
 c) automatic parsing of all open files & files belonging to open
projects, and files included by them

The "Enable Background Parser"checkbox lets you choose between a) and b/c).
The "Schedule all project files for parsing" checkbox lets you choose
between b) and c).

I think it would be easier for users to understand all of this if both
settings were together in the "Background Pareser" page.

Besides, you also wouldn't choose to have a "Schedule opened files for
parsing" option in a "Files" configuration page or somewhere in the
"Configure Editor" dialog, instead of the "Enable Background
Parser"checkbox in the "Background Parser" page. "Files" and
"Projects" are very low-level concepts in KDevelop - there might be
many settings that pertain to them, but are still more approriate to
put with other settings belonging to the more "higher-level"
functionality that provides them.

>>             - should be given a more descriptive caption, e.g.
>>             "Automatically start parsing all files belonging to open projects"
>
> Thats too long. The text needs to be relatively short (its already 2
> lines) so the layout doesn't make the lineedit too small.

Not a problem if it is moved to the "Background Pareser" page... ;-)

>>          - *add an informational QLabel* telling the user that this is not
>>          where Project-specific settings are configured, and point to
>> where you can
>>          do that.
>
> Where do you think that should be (I'm undecided wether to put that
> above or below the existing stuff)?

Personally I had imagined it below the existing stuff, but now that
you mention it, I guess it's really a matter of taste...

I guess it should go below if it is phrased more like a "by the
way"/"see also" note, e.g.:
"Note: this is not where settings concerning specific projects are
specified. For this, select the respective project in the Projects
View and select 'Open Configuration' in the 'Project' menu."

but placed at the top if it is phrased more like a general "what does
this page do" text, e.g.:
"This page contains settings concerning how KDevelop handles projects
in general. For configuring specific projects, use the 'Open
Configuration' action in the Projects View's right-click menu or the
'Project' menu instead."

> [...]
>
>>    - "*Background Parser*" page:
>>          - *add an informational QLabel* briefly explaining to the user what
>>          the background parser is and what it is needed for
>
> Suggestions for the text?

What about:

"The background parser automatically scans all open source files (and
optionally, all files belonging to open projects) as well as files
included by them, in order to collect the information necessary for
providing code completion, code navigation and other advanced
features.

The collected data is cached to the ~/.kdevduchain directory."

>> [...]
>>          - "*Add Kate modelines*" checkbox could use explanatory tooltip
>
> Added as "Adds a kate modeline to the file when formatting it".

Maybe expand this to:

"Adds a Kate modeline to the file when formatting it.

A modeline is a statement inserted at the end of a file which may
specify configuration options for the Kate editor (which is used in
KDevelop) specific to this file. In this case, it will tell the editor
to match it's indentation behaviour when editing this file to the
source formatting style that has been applied."

> Everything else is fixed now.

Cool...




More information about the KDevelop-devel mailing list