[hatari-devel] New FileSelector

Laurent Sallafranque laurent.sallafranque at free.fr
Fri Sep 10 21:59:01 CEST 2010


 > More generally, changing the UI can be nice to propose some new ways 
to work, but I
 > think it would be best in that case to provide some code than can be 
turned on/off using
 > a "define".


Yes, I agree here, but I had to change code here and there in many 
places, and it would have been hard to put #defines everywhere.

I'll have a look at the key repeat and I'll finish to add the mouse 
scrolling.
OK for keeping the old button.

For the UI, I have plenties of ideas, but the actual UI is usable like 
this (it wouls be more cosmetic changes).
But I found the fileSelector was too poor to be useable like this.

Regards

Laurent




Le 10/09/2010 20:07, npomarede at corp.free.fr a écrit :
> On Fri, 10 Sep 2010, Laurent Sallafranque wrote:
>
>> Hello,
>>
>> I was too upset with hatari fileSelector.
>> So, I've reworked it a little.
>> I've added
>> - 1 pixel precision scrollBar,
>> - Gem look and feel
>> - 17 lines displayed instead of 16 before
>> - upper left button for ".." folder
>>
>> Still to do :
>> - allow to scroll the scrollbar with the mouse (for now, it just 
>> displays the current view of browsed files)
>>
>>
>> Question :
>>
>> - Do you like it ?
>>
>> - Can I remove the old ".." button, as now, you can  move to upper 
>> folder with the upper left corner button ?
>
> Hello,
>
> I would not remove it, I don't think all users are aware that gem way 
> of going one level up was by clicking the upper left corner (and quite 
> frankly, I don't think the way gem worked was the more intuitive way).
>
>>
>> - some suggestions ?
>
> pressing the up/down arrow in the scrollbar is doing a fast scrolling, 
> which is nice, but holding up/down keyboard key doesn't have 
> autorepeat. Could you add it ?
>
>
> More generally, changing the UI can be nice to propose some new ways 
> to work, but I think it would be best in that case to provide some 
> code than can be turned on/off using a "define".
> Once we agree on a new UI, we can remove the #ifdef and the old code, 
> but in the meantime, I think it's best to be able to choose old or new 
> ui at compile time to test it and go back to old ui in case some 
> regressions are found.
>
>
>
> Nicolas
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>




More information about the hatari-devel mailing list