Hi,
Keep in mind that the UI Toolkit is just a delivery boy. It is natural
that the visual and ueser experience designs evolve and improve as
further we go. Also it is important to note that the convergence
requirements influenced the APIs too.
If you find something in the Toolkit code what you do not like, please
feel free to file a bug, propose a change or simple talk to us on the
IRC. If your proposal fits to the picture then I promise it will be
taken in consideration. I have just checked that in the recent years we
had contribution from 66 developers and the whole SDK team is 6 heads.
So, the UITK is a very open project. If you find something wrong, please
feel free to help us fixing it.
Same goes with the new APIs. The lost of components we are going to work
on are as published in the blog post. You are more than welcome if you
wish to take part of the API design and API scpecification review
process. I am sorry about your frustration, I do know how it feels when
an API does not behave the way i expect. The best solution for it is to
talk to the SDK team :)
One unquestionable advantage of the Ubuntu UI Toolkit versus of many
other toolkits out there is exactly the openness. If you do not like the
APIs in iOS/OSX or on Windows all you can do is being angry. In our case
you can influence.
cheers,
bzoltan
On 17/03/16 11:27, Roman Shchekin wrote:
Hi all
>> In addition to improving the components we will check out the most
critical core applications and consult with their developers on how to
get the most out of the UITK
Yes, I want to discuss few things. General advice is to make SDK more
stable and universal. Current situation - step to the left step to the
right (Russian idiom, I hope you can understand me) leads to very
unpredictable behaviour, which is different from release to release.
A lot of logic is implemented in QML and very frequently code looks
strange (like workaround). SDK development requires *deep
understanding* of technologies and best practices. Code is not
signalling about this.
Next thing I want to discuss - API. API author should *foresee *all
use cases of his library/component, provide minimum set of methods
with *very predictable behaviour*. On practice with Ubuntu SDK - every
time I want to use new SDK components, I am struggling with it, and
only my mate Stefano Verzegnassi knows how angry I become. Make it
more programmer friendly, *please*!
2016-03-17 11:33 GMT+03:00 Alberto Mardegan
<alberto.marde...@canonical.com <mailto:alberto.marde...@canonical.com>>:
On 03/17/2016 03:38 AM, Zoltán Balogh wrote:
The driving force of the UI Toolkit development are the
applications. So
it would support this idea a lot if you could describe few
exact use
cases where this component would be used.
While I never felt a need for such a component, I would probably
use it in Imaginario (a photo manager app) if it were available.
Imaginario's main view is a gridview of the user's photos, and all
the photo-managing functionality (such as setting a photo's tags,
geolocation, description, deletion, etc.) is available only once
you open the image. If there was a component which allowed to
bring some of these functionalities directly on the main page,
that would be certainly a plus.
Ciao,
Alberto
--
Mailing list: https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
Post to : ubuntu-phone@lists.launchpad.net
<mailto:ubuntu-phone@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~ubuntu-phone
<https://launchpad.net/%7Eubuntu-phone>
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp