← Back to team overview

kicad-developers team mailing list archive

Re: Re: AUI support


flm_mail wrote:
Hello. Thanks for advices.
I understand that the focus is not about GUI look but how the GUI and the code is written.

The focus depends on whether you are a user or a developer. They are both important. The end user cares about GUI design and consistency not that the underlying code is well written. A well designed UI will attract users to and that should be one of the goals of the project. If I thought no one was going to use it, I wouldn't invest my time in the project. However, if you create the "perfect" UI but the underlying code is a mess, I can assure you that most (if not all) of the developers on this list will care. That was the point I was trying to make. If changing something as trivial a dialog box layout was as much effort as I have put into the annotate dialog, I can't imagine how difficult changing the UI design would be. I was just trying to save you (and the other developers) a lot of grief.

I share genral opinion that SDI is simpler than MDI, and I don't want to change it. However, wxAUI support could be the starting point for internal frames, such as snapping panels, toolbars, command line and look and feel customization. I also understand this is not an easy task. The question is: at actual status, is it really needed? Or others improvements are more important? I think (this is no more than my very humble opinion) a better look and feel could help new users to move to Kicad.

I have seen both good and poor implementations of SDI, MDI, CLI, etc. I think most people have their own personal preference. I do agree that Kicad needs some UI polishing to help attract new users.

For what is about menus, my opinion is still not changed. I'm talking to one of the main developers, and this should be enought to make me silent. However, let me explain something. For programs witch looks standard, like kicad (standard behavoir, usual menus, toolbars), the first user expects to find every common command also on menus. I agree that a Draw menu with each drawing command is not necessary, but I don't understand why undo/redo/save/print and similar commands are both in menus and toolbars, but there is not New into File menu, cut/copy/paste into edit, and something similar. This looks incomplete (for me). Last message I referred to Blender to make an opposite example. This is not standard, in other words, when you open it, you understand: "Hello. I'm not standard, and you need time to learn how to draw. But this improves your drawing speed and possibilities.". Actually there is not this galvanic separation between standard and non standard application. The same problem will be only moved to future. If extended menus are not needed, the code will be only for personal use.

You have just described why writing end user software is so difficult. If it were easy, everyone would be doing it.

I hope to do something useful, and I know this could be a very long operation. As soon as there is something working, I'll post a new message.


I'll give a try when it's ready. Just don't for get about the rest of use poor developers while you are coding.


Yahoo! Groups Links