I am not talking about my personal opinion.
It means that there are items that cause operational inconsistency in the described part.

I am already in operation, but with the introduction of StellarMate, several users have changed the environment from WINDOWS.

I wrote a blog so that new users will not get lost, but it took a long time to explain the setting.
blogs.yahoo.co.jp/t_studio_astro/folder/605849.html
(It is Japanese, it describes the setting procedure of server, driver, Ekos.)

That is because there is a part where server, driver, client relationships are complicated.
(Especially Ekos & Control panel)

Even when the function of familiar CanonDslr got wrong, it took a while to notice that it was a check on the driver's new item.

I feel it is difficult to set many functions for those who start from now.

Although the example described by me is also one plan, I think that rules such as setting are important because it is a multifunctional environment.

Let’s leave it there, as don’t think you are understanding me or I you properly, I think the language barrier is in the way..

I do not mention that removing the INDI control panel.

In terms of control panel like Control Panel, it is said that relationships are clearly defined by dividing the device setting items of the driver and the control items and items in the client.
In the present situation there are parts that are mixed each other.

Although Ekos is a front end for control, it also has equipment setting items, and the control panel also has control items.

I feel that relationships will become clearer after organizing this.I do not mention that removing the INDI control panel.

In terms of control panel like Control Panel, it is said that relationships are clearly defined by dividing the device setting items of the driver and the control items and items in the client.
In the present situation there are parts that are mixed each other.

Although Ekos is a front end for control, it also has equipment setting items, and the control panel also has control items.

I feel that relationships will become clearer after organizing this.

It is regrettable that I could not explain. . .

Could you give an example of an item that you would move from one area to the other? Maybe that would help with understanding the intention.

I've given the "problem" of control panel a little bit of thought. When I get a spare moment I'd like to look into how to define selected driver properties as "advanced" or something like that; either as attributes or additional elements in the driver config or as a separate xml - depending on conformity with the INDI architecture.
The idea is that those properties could be accessed through EKOS via some sort of "advanced settings" button wherever a device can be selected or configured. That could pop up a window with the defined advanced properties for the device where values can be viewed and set. Along similar lines to the way the EKOS Capture module can collect non-standard driver properties in the imaging schedule. Nomination of advanced properties could also be configurable through the INDI control panel or possibly via EKOS configuration. I think Indi is a better optiona s it makes the advanced properties available to all clients.
For instance, the ZWO driver could define Gain, Offset and Bandwidth as "advanced". So in EKOS Capture (or platesolve or guiding) module wherever the camera can be selected an advanced settings button (cogwheel icon?) would allow those values to be set. In Indi Control Panel or somewhere suitable, one could also add the 8bit/16bit property if that is desired. On the TCFS focuser driver, one could define the Auto/Manual focus mode property as advanced and maybe also temperature (read only). For a Mount maybe Guide speed would be a useful advanced property.
All properties would always be available through the Indi Control Panel.
The driver developer could pre-define typical properties as advanced so most users would have no need to configure in Indi. But anyone could redefine the advanced properties if they want. Most of the work would have to happen in the clients to enable the advanced properties.

@Kengs
I agree completely with you here, to have advanced options within the ekos window tabs for driver settings would be a very good idea, I have to go back and fourth between INdI control panel and ekos a lot, (especially with focuser driver as very limited control in ekos) and it would stop all that. As I said before, to have all controls in ekos would be a massive job for the amount of drivers and all the different settings, but to have them under an advanced options would work, as the options would be different for different drivers...

From what I read, you are all seeking better clarity on the INDI panel. I agree sometimes I'd love to have the same tooltips in that panel as there are in Ekos, but besides that, aren't all your requests directed towards INDI driver development? I don't see the advantage of getting those controls inside Ekos if they are not part of what Ekos uses: it will require massive dependency injection.
Now, there's one point I note: when Ekos is using a particular INDI panel control, it would be interesting that this area be clearly identified as under control from Ekos. And by extension, what area is NOT under control by Ekos.
Also, an option not to show the INDI panel at all when connecting, probably.

-Eric

Well I for one can ONLY fully control my focuser from the INdI panel, so if that’s not there, then I am in a mess for one...
There is not nearly enough tools for focusing from the ekos focus panel...and it will be the same for many other drivers too I would imagine.. that a lot of the control can only be done from the driver control panel..

You may compare this to ASCOM drivers I suppose. The configuration UI of an ASCOM driver is entirely in the hands of the driver developer. The support for anything else than ccd, mount and focuser is scarce for ASCOM-aware clients.
But in the end, why is your focuser not usable with Ekos? It offers too advanced features that Ekos is unable to control? It is providing controls that doesn't match what Ekos expects as methodology? Is there another client that is able to control that focuser?
I'm not really asking for a detailed answer, I just wanted to understand if the need was in Ekos, or in INDI.

-Eric

Well in ekos I can’t sync the focuser to a certain point, to get back to zero I have to travel all the way back rather than just sync to zero, that’s one feature missing in ekos...

The problem arises at the INDI/Ekos interface. INDI supplies a set of standard properties that are a subset of the full features of a device and Ekos can only manage those standard properties so it can remain device agnostic.The example of gain in a CMOS camera illustrates this. Gain is not a standard property for an INDI CCD so it cannot be set through Ekos (although counter-intuitively it does allow setting ISO). But CMOS users often want to use different gain for RGB vs L vs narrowband filters.The mechanism provided in Ekos currently is a workaround that requires going into INDI control panel to set the gain then selecting the tab that contains the gain property to add to the sequence. Its a very confusing workflow.
My focuser example is the auto temperature compensation mode for TCFS. Once the camera has been focussed I want to switch on the temperature compensation and can only do this by going into INDI control panel as it is not a standard property.
My proposal in effect provides through the driver a kind of standard tab containing non-standard properties that are frequently used. It is also a virtual tab in that it is just a collection of properties that would otherwise appear on specific tabs in INDI control panel. The set of properties is initially set by the driver defaults but could also be dynamically maintained by an advanced end user. There is no problem for Ekos to get/set any property for a device as the driver provides al the information needed. It just needs to know what they do. It knows what the standard properties do but cannot know what the non-standard properties do. So the standard virtual tab simply serves up to Ekos those properties that are useful to the user(e.g Gain) and relies on the user to understand what they do and set them appropriately. Providing this information from the driver enables any client (not just Ekos) to provide the functionality.