[rfc][icedtea-web][itweb-settings] Improve Icedtea-Web cache disk space

[helpcrypto helpcrypto]

I'll wait for a hidding patch then.

On Wed, Sep 3, 2014 at 3:41 PM, Jacob Wisor <gitne at gmx.de> wrote:

> On 09/01/2014 at 02:59 PM, helpcrypto helpcrypto wrote:
>
>> On Sat, Aug 30, 2014 at 9:44 AM, Jacob Wisor <gitne at gmx.de> wrote:
>>
>>  No no, do not start playing around with visible and hidden UI components.
>>> It is even worse when they change their layout or start jumping around
>>> like
>>> it is now. Generally, there is never any need to hide UI components. If
>>> there seems to be, then either there is something wrong with the basic
>>> design of a window or dialog, or you should have very good reasons to do
>>> so. And, in this case there is surely *no* reason to hide any components
>>> dynamically at all. Again, stick to disabling components. This should be
>>> enough.
>>>
>>> @helpcrypto
>>> Yes, it is against basic UI design principles to have hiding UI
>>> components, unless there are really good reasons to do so.
>>>
>>
>> Can you point a style guide, or a gui-best-practices which advices on
>> that?
>>
>
> Well, there are multiple guidelines available, depending on OS, window
> managers and/or desktop managers. It is difficult to point to a specific
> one in the case of SWT and Java because it is platform independent. But, I
> suppose one could take Microsoft's UI guidelines as a basis because of it's
> undeniable bread adoption. It also shares a large set of rules with other
> UI guidelines form other vendors.
>
>
>  I have seen several GUIs wich only show the user what he needs to see, and
>> I found them KISS-compliant
>>
>
> I think you are mixing to concepts here. KISS is about technical
> solutions, that is how things should be solved in order for other engineers
> to comprehend the work of the original authors, and generally assumes that
> simple technical solutions are usually the most effective or efficient ones.
>
> UI design guidelines employ a similar concept but not exactly KISS. Good
> UI designs should not be overloaded with UI components and only display the
> right amount of components required to accomplish the current task at hand.
> Hence, users should not be overburdened with overloaded UIs. But, most
> importantly UIs must not be confusing to users, and their behavior must be
> intuitively and naturally predictable. Hiding and jumping UI controls feel
> absolutely unnatural and inorganic. This is indeed bad behavior for UI
> controls.
>
> I will give you a simple example why your way of thinking is flawed here.
> Take for example a dialog with a list view and an edit button to edit the
> list view items. Now, if no list view item would be selected then according
> to your reasoning the edit button should be hidden because the user can
> take no editing action while no list view item is selected. This is
> absolutely confusing to the user. The user is supposed to be able to see
> and know all the possible actions he can take at all times but should not
> be able to take invalid actions. This is why the edit button in this
> example has to stay always visible but not always enabled. Think about it.
> ;-)
>
>  Unfortunately, because of your attempt to play around with hiding UI
>>> components you have introduced a new bug. When "Limit cache size" is
>>> checked and the spinner is 0 then all components for setting up the cache
>>> location suddenly disappear.
>>>
>>
>> Limit checked, value=0->no cache, hence no need of location, compression
>>
>> level or anything. It's not a bug.
>> The warning under spinner informs about that.
>>
>
> This is logically correct but it is against basic UI design guidelines. It
> is inorganic.
>
>
>  And, as soon as the value becomes greater than 1, they become visible
>>> again. This is very odd, weird, and confusing. Again, do not play around
>>> with hiding UI components.
>>>
>>>  The reason why i suggested "no caché" instead of 0.
>>
>
> As mentioned before, the UI components handling the cache's location
> should simply be disabled in this case. No real reason to hide them.
>
> Jacob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20140903/1b4710d5/attachment.html>