Jump to content

Survey: Features you want to see in 2021


Hayri ASLAN
 Share

Recommended Posts

Purpose of this survey is simple. We want to shape 2021 roadmap of uniGUI according to developers' actual real world needs. We already did a similar survey before and we do this again to assure that we won't miss any important feature.

Please specify the most important features for you that you'd like to see in 2021 roadmap of uniGUI. You can write as many as features you want and please write them in order of importance with most important feature at top.

Thank you!

  • Upvote 1
Link to comment
Share on other sites

  • Hayri ASLAN changed the title to Survey: Features you want to see in 2021
  • Hayri ASLAN featured and unfeatured this topic

1- unigui is wonderfull for dev when all is defined in designtime, but when we create /change properties in runtime grid editor, filter editor, column title... it is very more difficult. i would like unigui team work on this development aspect.

2- optimisation for uploading with very big file

3- unigui hyperserver farm

4- save/load configuration grid (column position/visible/sort/filter .....)

5-having a better visiblity for current evolution under dev . what are the current evolution in progress and what is the end date ?

6- improve security

7-add a property fingerprint as brower version, ip ...properties of session

8-tools for create or own theme

 

  • Like 1
Link to comment
Share on other sites

1 - Improvements to the TUniCheckCombo, TUniTagField and other components

2 - Server Farm (Load Balancing)

3 - Performance improvements

4 - Improvements in the installation part, for example a CDN without needing files on the server

5 - Improvements in Linux integration

6 - Responsive Layout

7 -  An easier way to manipulate the application theme


 

 

  • Like 1
Link to comment
Share on other sites

Better LookupCombos with multicolumn popups (at design time) and key/value management (better is a grid inside popup)
Better data input into DbGrids, with a better key management, more natural as VCL dbgrid, for fast insert of a lot of data (VCL desktop migration) 

Optional capability to send dataset updates present on client only in one time (like applyupdate) to server dataset, for avoid continue "chatting" for every change in fields. (Sometimes I need to input and entire grid without need to exchange data with server, but I want to transfer all on save. Only for performance and better scalability).
A lot of widgets, widgets, widgets, in grids, treeview, lists, etc...
More complex components, like that with free positioning of editors or data in grid rows (like LayoutGrid of Firepower Woll2Woll), 
More complete Lists to manage at designtime.
Naturally Responsive features.
WebSockets native, chats and videoconference.


 

  • Like 1
Link to comment
Share on other sites

1. in the editor 

image.png.4617778571262980670c4ac235c68abd.png

ExtEvents and UniEvents highlighted if code present inside (without having to enter each element to see if we have activated any code).

 

2. building the user interface takes 60% of the time of building an application. 

You would need an editor with the ability to choose values like to

x-panel-header-default

x-panel-body-default

etc..

to generate custom css or  an easier way to manipulate a new application theme

 

3. a solution for custom screen mask without using EnableSynchroniusOperations passing, for example, an gif and a provedure to execute.

Of the series shows the animated git until the procedure has not finished

 

 

 

  • Like 5
Link to comment
Share on other sites

1. Smart-sizing grids options.

2. Better JavaScript code editor: Non-modal/not blocking and with SynEdit based editor.

3. Integrated into IDE context help.

4. Linux compatible graphics.

5. More units with source code.

6. Define controlled 'all-in-one' VCL/DLL/Service new project template.

7. Easier or better documented ways to access JS/ExtJS parameters from server size.

 

Link to comment
Share on other sites

On 12/15/2020 at 6:22 AM, picyka said:

1 - Improvements to the TUniCheckCombo, TUniTagField and other components

2 - Server Farm (Load Balancing)

3 - Performance improvements

4 - Improvements in the installation part, for example a CDN without needing files on the server

5 - Improvements in Linux integration

6 - Responsive Layout

7 -  An easier way to manipulate the application theme


 

 

6 - Responsive Layout for me is one the most important 

  • Like 1
  • Upvote 1
Link to comment
Share on other sites

In this first post I want to suggest a few things about this process.

It is not enough to make requests, but to try to justify it, what will bring the feature to the UniGUI ecosystem.

There are two quite different kind of requests. Some concrete feature or improvement to solve a current issue, or a big feature to make UniGUI become something much better than now.

I'll focus on the latter kind of requests.

It is important to have some feedback about our proposals (and not only from Farshad).

Link to comment
Share on other sites

  1. HyperServer should grow to HyperServer Farm with Load Balancing.
    • Current HyperServer is enough for many applications, but if the application must serve many clients, one node will not be enough
    • As soon as there are several HyperServers, server affinity, load balancing, keeping truly global sessions will become issues.
    • It is something like what happens with RemObjects DataAbstract and RemObjects SDK Olympia.
  2. A Run-Time Designer will solve many of the issues raised by many people.
    • It could allow modifying an existing design or creating a visual design from scratch.
    • As this component will execute at run-time, it will allow seeing what the customer will see. This fact will solve all the issues related to setting the correct properties for achieving the perfect alignments and any other visual properties.
    • It should be possible to save the design (*.FRM) for loading it at run-time or use it for adding it to the original project. In this case, it will be possible to define Delphi events for server-side event handling.
    • If desired, despite loading the design at run-time, it could be possible to capture client or server-side events (in Delphi or using some scripting language).
  3. Server Module shared repository
    • Some application tasks or memory structures are global and shared between sessions.
    • While in current UniGUI it is the developer responsibility to create and administer the access to these structures, when having multiple instances of an application, under a HyperServer or in a Server Farm with multiple HyperServers, UniGUI should provide some additional support to make it easier and standard.
    • This kind of global repository should provide a messaging infrastructure with point-point, broadcasting, publisher/subscriber, etc. making it easy to create real-time (chat) applications, offline messaging, etc.
  4. Marketplace
    • Free or paid components
    • I have a dream (I'm not Malcom X) about components like those used in electrical designs. I'll add more details later...
    • A few examples of possible generic solutions packed as database schemas and components:
      • Role-Based Access Control (RBAC)
      • Explicit class-to-entity mapping in the database (supporting inheritance, logging, versioning, deep copy for complex objects, dynamic classes, generic annotations)
      • Workflow Designer and Workflow Engine (with roles, work lists, statistics, chains of approval)
  5. Responsive Design
    • I didn't add this feature explicitly because it should be part of the Designer (mentioned as the second feature).
    • The Designer could be used at design-time or run-time. Whatever is created could be saved as a .DFM to replace the previous design or to override it at run-time.
    • If no scripting is needed, or if the code is already available as actions in a data module, it should be possible to keep the design only run-time.
    • If there is no way to code something required for the form, the design should be further developed at design-time.
    • In any case, the responsive features should be defined in the design, Delphi-style, with more options than just the client-side JavaScript code.
Edited by davidizadar
Unfinished post
  • Like 3
  • Upvote 1
Link to comment
Share on other sites

Greater development of mobile components.

TunimListView with constructor like Facebook, Twitter.

TunimTreeList (TunimTreeView).

TunimColorSelect.

Improvements to the TunimDBLookupCombobox.RemoteQuery (no keyfield).

Custom mobile themes.

 

So that mobile components reach the level of desktop components.

 

 

***

uniDBGrid with built-in filters, sorting

 

 

http://forums.unigui.com/index.php?/topic/15748-много-разных-вопросов-предложений-и-пожеланий-по-unigui/

 

Link to comment
Share on other sites

On 12/17/2020 at 5:19 PM, rgreat said:

5. More units with source code.

There are too many units without source ...and without sufficient information
uniGUIClasses,   ..  uniGUIForm,   uniGUIConst,  ..  uniGUIBaseClasses,.. uniGUImClasses,   uniGUImForm ... uniImageList .. etc etc
It takes at least a detail of the various object definitions
publish (for full version ) at least part of the text between "interface" <--> "implementation"

it's a lack ..
all this creates difficulties to those like me who want to implement properties and methods and create their own components.
Finally .. not having all the sources .. is a risk for those who focus their resources and projects on UniGUI.

Buone Feste e Buon 2021.

 

  • Like 2
Link to comment
Share on other sites

New Published Property called for example: "CustomAttrib" of type TString in the most ancient class.

 

This new property need to be published in all components of uniGUI in order to enable programmers to create new pseudo-properties to increase the power of components.

Link to comment
Share on other sites

The Lazarus/FPC support. Lazarus have very good Linux support. It is very actively developing. The Lazarus(IDE) works directly in the Linux. And it's absolutely free for using!

The indy already works under the FPC. It doesn't even need to be rewritten. Most of the code could be compiled without change in the delphi code mode (different units in the code could have different compilation modes).

  • Like 1
Link to comment
Share on other sites

3 hours ago, Tokay said:

The Lazarus/FPC support

Expected in the RoadMap 2019
but for FPC support you need to include uniGUI Core source code ...
that they have no intention of doing ... 

I have already written: this is a lack and a risk

Link to comment
Share on other sites

 Share

×
×
  • Create New...