← Back to team overview

kicad-developers team mailing list archive

  1. kicad-developers team
  2. Mailing list archive
  3. Message #04080

Re: Minimum Recommended Screen Resolution

  Thread Previous • Date Previous • • Thread Next 
Verner has made a goor summary of resolution needs...

But I think that he missed that today most portables have wide screens, 
which in fact are not wide but smaller verticaly. So I would say:

1) I agree with 800x600, being that the important thing that the OK 
button does not disapear. If the main section scrolls with the wheel, it 
would be perfect.

2) 1024 horizontaly is ok, but verticaly 768 is not available in most 
portables.

So I may add it all up, as a suggestion:
a) Dialog Width should be never more then 800, so that it will never 
become a problem.
b) it would be a good solution to have the main buttons allways present 
at the bottom, adjust the screen to maximum screen size, scroll the main 
part of the windows
c) Avoid putting too much in the same dialog... This may not be allways 
possible/convienient, alas...

Sorry to come back to this toppic, but IMVHO it is important..
Alain

Werner Almesberger escreveu:
> Dick Hollenbeck wrote:
> 
>> Let me call the "Minimum Recommended Screen Resolution" our MRSR.
>> 
>
> I think there are two or three resolutions that matter for users:
>
> 1) the minimum resolution at which the program is still usable, no
> matter how painful. E.g., below this resolution, GUI elements may
> disappear, dialogs may exceed the screen size, and so on.
>
> 2) the resolution at and above which the program can be used for
> regular work, even if it may be incovenient or may require more
> experience (e.g., to learn hotkeys)
>
> 3) the resolution at and above which the program is really
> convenient to use
>
> I wonder if space permanently allocated to desktops also has to be
> taken into account or if all of the major ones have a full screen
> mode that gives the application the full physical resolution.
>
> I think 1) should be as small as possible. It's not the resolution
> people should work at, but they may find themselves in an exceptional
> situation where their work environment is very constrained. It's nice
> it your tools don't fail you even then.
>
> I think it would be good if this resolution could be 640x480, which
> seems to be the lowest common denominator for hardware that's likely
> to run KiCad at all. I think requiring more than 800x600 as the bare
> minimum would make KiCad a less flexible tool.
>
> On Unix, you can work around some screen limitations also with a
> virtual desktop, but I don't know if this is also true for other
> environments.
>
> 2) and 3) are fuzzier and probably don't have a large impact on
> development. I think 800x600 for 2) would be generous and 1024x768
> should be acceptable for most people. For 3), the 1280x1024 you
> proposed sound like a good limit to me. 
>
> - Werner
>
>

--------------050105070208030803080902 Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Verner has made a goor summary of resolution needs...<br>
<br>
But I think that he missed that today most portables have wide screens,
which in fact are not wide but smaller verticaly. So I would say:<br>
<br>
1) I agree with 800x600, being that the important thing that the OK
button does not disapear. If the main section scrolls with the wheel,
it would be perfect.<br>
<br>
2) 1024 horizontaly is ok, but verticaly 768 is not available in most
portables.<br>
<br>
So I may add it all up, as a suggestion: <br>
a) Dialog Width should be never more then 800, so that it will never
become a problem.<br>
b) it would be a good solution to have the main buttons allways present
at the bottom, adjust the screen to maximum screen size, scroll the
main part of the windows<br>
c) Avoid putting too much in the same dialog... This may not be allways
possible/convienient, alas...<br>
<br>
Sorry to come back to this toppic, but IMVHO it is important..<br>
Alain<br>
<br>
Werner Almesberger escreveu:
<blockquote cite="mid:20100128143119.GA27996@..."
type="cite">
<pre wrap="">Dick Hollenbeck wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Let me call the "Minimum Recommended Screen Resolution" our MRSR.
</pre>
</blockquote>
<pre wrap=""><!---->
I think there are two or three resolutions that matter for users:

1) the minimum resolution at which the program is still usable, no
matter how painful. E.g., below this resolution, GUI elements may
disappear, dialogs may exceed the screen size, and so on.

2) the resolution at and above which the program can be used for
regular work, even if it may be incovenient or may require more
experience (e.g., to learn hotkeys)

3) the resolution at and above which the program is really
convenient to use

I wonder if space permanently allocated to desktops also has to be
taken into account or if all of the major ones have a full screen
mode that gives the application the full physical resolution.

I think 1) should be as small as possible. It's not the resolution
people should work at, but they may find themselves in an exceptional
situation where their work environment is very constrained. It's nice
it your tools don't fail you even then.

I think it would be good if this resolution could be 640x480, which
seems to be the lowest common denominator for hardware that's likely
to run KiCad at all. I think requiring more than 800x600 as the bare
minimum would make KiCad a less flexible tool.

On Unix, you can work around some screen limitations also with a
virtual desktop, but I don't know if this is also true for other
environments.

2) and 3) are fuzzier and probably don't have a large impact on
development. I think 800x600 for 2) would be generous and 1024x768
should be acceptable for most people. For 3), the 1280x1024 you
proposed sound like a good limit to me. 

- Werner

</pre>
</blockquote>
</body>
</html>
 --------------050105070208030803080902--

References

  Thread Previous • Date Previous • • Thread Next