中文 
bannax1994
deepin
2017-09-27 07:11 deepin I would be very happy to develop "native" applications for Deepin. By native I mean in the context and use the same components and the same philosophy of the system. I would be delighted to study your system components / widgets (GTK / QT), to understand which language is best matched with deepin. It would also be a good idea to read what your approach to application events (as Massimo C said: first startup, session recovery, etc.) without leaving anything to chance. Examples of applications are equally useful. 
Reply Like 1 View the author
it would be great more applications with the philosophy and design of deepin created by community users
Many users now know Deepin Linux, thanks to all great work on the Distro and blogs who talks about it.
I think now it’s time to attract more and more users, and one key could be the opportunity of customize Deepin in all its components.
But how?
The main point is to provide instruments to develop custom plugin. Indipendent developers could spread Deepin by customizing it and create custom plugin, like the Weather plugin in the Control Center!
What is provided by Deepin? Not enough. The Developerpage on Deepin website is not the best starting point.
Due to Deepin-GALA link, I think Deepin Dev Team has to analyze Elementary Philosophy, starting from here: https://developer.elementary.io/
This is the home every Dev dream: one single point to get instruments/documentation/examples and start developing its own App/Plugin!
For a Dev, start developing is really simple with the following page: https://elementary.io/it/docs/code/getting-started
Another important point is design: an app could be useful, but also provide the best design available: https://elementary.io/it/docs/human-interface-guidelines
About this point, I think is important to note:
- What Design Is Not
—- Avoid Configuration
—- First-Launch Experience: when a user first launches an app, they should be able to get down to business as quickly as possible. If configuration is not absolutely required for the first use, they should not be required to configure anything. If configuration is required, they should be presented with a clean and simple welcome screen within the app. Avoid separate configuration dialogs when launching.
- Normal Launch: When a user launches an app, they're performing an explicit action and expecting a fast, oftentimes immediate response. You should focus on three key areas for app launching: speed, obviousness of what to do next, and state.
Last but not least: provide working examples. Here a series of example to get the Devs involvement easily! --> https://github.com/robertsanseries/template-for-vala-app
So, please hurry up and take Developers advantages!