SUMMARY I'm using a small MacBook Air and I'm using multiple desktops to switch between, however kStars and Ekos are always limited to just one desktop (at least I was unable to move Ekos to another desktop to have enough space). There is a lot of wasted space and on the other hand there are lots of checkboxes and textfields and all together takes much space. Using multiple monitors this would not be a big deal, however when I'm using this on a single notebook outside I don't have multiple monitors and this ends up with changing the size of windows, switching between them and search where other windows are behind each other. A bigger screen would help a little bit but I think not so much. I know this is nothing to be solved in short terms. However, there are also some small improvements that could make our lives easier. On the other hand, for new users the overwhelming amount of settings is hard to handle - so I would recommend some small short term solutions and a step by step improvement of the Ekos UI as a long term solution. I would also like to contribute if this is okay for you. I'm a developer with experience in UX and I could at least contribute by help with translations into German language (I have no experience with Qt, I'm a experienced Swift and C# developer with C++ experience long ago in the past. These things could be helpful as future improvements: 1.) Let the user resize the log view control. It can be resized already, but it shrinks to zero height and cannot be restored to another size, because now its top border is identical to the bottom of the Ekos window. Include a small handle to avoid this situation or add another button/check box to show/hide it. This saves space when the log view is not of concern for the user. When the screen is large enough you can already resize it back, but do this with cold fingers on a touchpad outside on a 11" screen and you will end up closing and reopening Ekos to get the log view back. 2.) Make the buttons on top of Ekos smaller in size. If you don't want to support a touch screen these buttons are very large and are wasting much space. Another approach would be to locate them on the left window border. The height of the window is more limited. 3.) Make some changes to make it possible to hide things not needed. If a user is using no autofocus device it does not make sense to occupy space on screen for things the user does not need. 4.) Hide things which are not needed at this time. I.e. when using the alignment module before it runs it is not required to see the results, but it is necessary to let the user change things like binning (if supported) and the scope/camera combination to be used. However, these things are no longer required when the user clicks on capture and solve, now the results are more important. Both things could share the same space via a tab controller, so the user could still switch between them (people often don't like that something is removed from a software :-)). 5.) If no image is shown inside the image preview (for the settings panel) it just shows a useless nice image and occupies a lot of space. 6.) General window management: Could you make it possible to move Ekos to a separate virtual screen on windows/linux/Mac? At least we should find a better solution to avoid the need for searching a window below multiple others. Often a message box occurs and is below Ekos or I open the mount control panel and it is behind Ekos and on top of kStars, this is a bit annoying. 7.) Why does the Indi control panel open on connect? If I need to change things or something went wrong then its okay, otherwise it should not open. 8.) CCD panel: very confusing: - When using a DSLR why I have a filter wheel and a cooling option and so on? I think when we need to configure so many things then why not this? When I don't need it it could be removed from the UI. - Why ISO and Gain? Again, one of the two. - Two folders to save the images? And a combobox for both or remote or locally? When I set both I could have two paths to be changed, otherwise its only lost space. - Type: combobox with light and dark, but also a dark library below? In general: make the UI much cleaner (and as I see in the forum this seems to be already a considered topic) - the problem is of course to support those how have all this hardware and still want to control it without too many additional clicks. I would like to help here if this is okay, at least I could do the missing German translations. Let me know for any support/contribution I can give to make improvements to Ekos, because I really appreciate what you are doing here!
Thank you for the valuable feedback Jurgen. Do you think perhaps you can checkout Qt? If you have experience in C#, then it's just a matter of learning a new toolkit. With QtCreator, you can checkout KStars code from GIT and start checking the UI files (e.g. capture.ui) and then check capture.cpp how how the items are shown in there. Perhaps you can come up with a smart way to adapter the interface dynamically depending on the state and selected device.
Hi Jasem, Not sure if I will become so much familiar with Qt to make my contributions, but at least I will have a deeper look on it - perhaps this could really work. Do you have some „communication channels“ for development? And what about some prototyping tools? For my iOS development I used Sketch and for prototyping at work (windows development) we are using Adobe XD in the company where I’m working - this is not the best choice I think. Today I would prefer Figma. The benefit of this is that you can change the UI and discuss all things until everybody is happy, the huge benefit is the possible discussion to come to a really good UX and when you have a prototype this is the blueprint for development. I think we could show the changes in the forum…. I know this process takes a little bit more time, but it can really make a huge difference, because while prototyping the small changes are done really fast and when prototyping is finished the developer(s) really know what to do and this makes development really much faster - most developers don’t have the „feeling“ for UX design decisions and are concentrated on the solution - this is another learning curve. :-) Because several years ago I was also not so much concerned about UX I really know what I’m talking about. Not sure, if this could fit in the workflow of the rest of the team, however. > Am 25.07.2021 um 13:06 schrieb Jasem Mutlaq <bugzilla_noreply@kde.org>: > > https://bugs.kde.org/show_bug.cgi?id=440254 > > --- Comment #1 from Jasem Mutlaq <mutlaqja@ikarustech.com> --- > Thank you for the valuable feedback Jurgen. Do you think perhaps you can > checkout Qt? If you have experience in C#, then it's just a matter of learning > a new toolkit. With QtCreator, you can checkout KStars code from GIT and start > checking the UI files (e.g. capture.ui) and then check capture.cpp how how the > items are shown in there. Perhaps you can come up with a smart way to adapter > the interface dynamically depending on the state and selected device. > > -- > You are receiving this mail because: > You reported the bug.
We do have online chat here: https://webchat.kde.org/#/room/#kstars:kde.org Though it's best to send emails to kstars mailing list: https://mail.kde.org/mailman/listinfo/kstars-devel You can download QtCreator as well for MacOS and build KStars there. There is a script for this purpose: https://github.com/rlancaste/kstars-on-osx-craft Might take a little bit to get everything up and running. I know there is a lot of work that can be done to improve the UI, so any input and contributions are greatly appreciated.
Okay, Jasem, Just downloaded QtCreator and it looks interesting (although it seems to have some incompatibility with macOS Monterey). I will spend some time to bring everything to work on my Mac and will do some investigations. Perhaps this is not so different from my other projects, at least I’m really excited about it. We will see, if I can manage this beside my other activities and regular work, but this depends on Qt for me. Best regards, Jürgen > Am 25.07.2021 um 16:52 schrieb Jasem Mutlaq <bugzilla_noreply@kde.org>: > > https://bugs.kde.org/show_bug.cgi?id=440254 > > --- Comment #3 from Jasem Mutlaq <mutlaqja@ikarustech.com> --- > We do have online chat here: https://webchat.kde.org/#/room/#kstars:kde.org > > Though it's best to send emails to kstars mailing list: > https://mail.kde.org/mailman/listinfo/kstars-devel > > You can download QtCreator as well for MacOS and build KStars there. There is a > script for this purpose: https://github.com/rlancaste/kstars-on-osx-craft > > Might take a little bit to get everything up and running. I know there is a lot > of work that can be done to improve the UI, so any input and contributions are > greatly appreciated. > > -- > You are receiving this mail because: > You reported the bug.
Please check against KStars 3.6.1 and report back.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!