Re: [orca-list] GUI Redesign or clearup and modernization

[Luke Yelavich <luke yelavich canonical com>]

Re-sending to list, forgot to reply to list.

On 28 Aug 2015, at 8:37 am, chrys87 <chrys87 web de> wrote:
> Howdy,
>
> nomnom :) a redesign is a fully redesigned new GUI. so almost written from scratch. newly designed code, 
> and maybe layout (i looks really stalled, i do not use orca often. but my girlfriend do, she dont like it 
> because a "card layout" its not the best in things of navigation. I agree with her that a more "list" 
> orientated layout would be more efficient (also in things like we are more able to keep things more generic 
> in the codebase, what lead to more easy contribution to orca).
>
> A "clearup and modernization" its mosstly clean up the really stalled code ( its hard to integrate some new 
> things, thats what i learned in my work on the orca beeps). no real name convention, confuse names 
> (combobox1, combobox2, combobox3), fix warnings while start the GUI, port to more current techniques. :).

I’d be interested in having a look at what you are working on. I have been working on a GSettings backend for 
Orca for a week or so now, just about to start the actual coding, after much planning and writing out the 
GSettings metadata. Longer term, to properly support individual desktop environments offering Orca settings 
in their system settings control panels, it may be worth moving settings management, both in the storage and 
retrieval of settings, as well as presenting settings in the UI to a C library. The desktop environments that 
work with Orca now are written in either C/GObject C, or C++. Orca itself would make use of this C library, 
and with some planning, we could develop an API that allows a the settings for Orca to dynamically be 
presented and updated, such that any new settings only need to be added to Orca, and the UI in the desktop 
environments dynamically updates based on what they retrieve via Orca’s settings API. This library would then 
take care of storing the settings, most likely in GSettings.

I suspect one reason why some people are against individual desktop environments offering Orca settings in 
their control center, is due to the possibility of Orca settings being out of sync with what is offered in 
their control center. I’d argue that it would not be too far fetched, and not too difficult to implement 
things such that desktop environment developers only need to implement Orca’s settings API once, and then any 
new settings Orca offers are automatically presented when they are added to Orca. Would that be enough to 
convince you folks that using the control centre of your desktop environment to change Orca settings is the 
way to go?

Luke