Should Qucs separate Schematic, Textdoc into different window?

[yodalee]

Recently I spend some time so watch and clean up code in qucs.cpp, the main program. Here is the issue need to be discussed. Currently qucs support two type of doc: schematic, and pure text document textdoc. Both files are double inherited from Qwidget and QucsDoc, with QucsDoc provides some function interface like becomeCurrent, DocName. In mainwindow, all open files will add into tabwidget in mainwindow, and all files share same window menu. This design use single window to manage all design files, but it also shows many drawback.

• In the following code: https://github.com/Qucs/qucs/blob/master/qucs/qucs/qucs.cpp#L577 Since what QTabWidget stores is QWidget, not QucsDoc, and QWidget doesn't have the function interface needed, we need first change it into QucsDoc. If we add Layout Document, EM simulation document, the function like getDoc will become crazy. There are more function handle what to do when user switch to other tab, in every case, determining the file type, casting the pointer are also required.
• Also, every doc need a becomeCurrent: https://github.com/Qucs/qucs/blob/master/qucs/qucs/schematic.cpp#L196 In current state, there are only two doc, if we wanna add another file type, we may have to change becomeCurrent in each files. Also, each type of document uses different QActions. Insert menu in schematic and layout will definitely have different contents. The implementation of becomeCurrent will quickly become unmanageable.

---

I'm not sure how others think, but I feels that putting every file into same window will limit the progress of adding new function. I suggest that, though someone may dislike this, in the future, one file per window will be necessary, this eliminate the needs of becomeCurrent and makes the function of each window more clearly. Maybe I'm wrong, I'm still consider the design concept, but before we get to the answer, I need everyone think of this question.

[ra3xdh]

As for me, I prefer old Qucs interface with Tabs (firefox-like). A number of CAD software and IDEs have similar interface (MicroCAP, KOMPAS, Kile, Texmaker, Code::Blocks). With windowed interface we obtain GIMP-like interface that is always under strong critics. I think we should save old tabbing-style inerface. I recommend to save old interface.

What other documents types you want to embed? There will be so numerous new documents in near future? As concern two ones mentioned by you:

1. I think it's not need to embed PCB layout editor to Qucs. Circuits under simulations and circuits on PCB are rather different. Often only a part of the circuit is simualted. If we embed PCB layout editor we can get a monster like Multisim. We should implement "Export to KiCAD netlist" feature or something similar.
2. EM-simualtion is a very long future. I know only one open-source EM-simulator. It is openEMS. As alternative we can use freeFEM PDE solver. We should use one of that two. It may require standalone application (like Qucs-tool), maybe 3D openCASCADE-based. I think we should use special file component to embed EM-simulation result. It's not need to embed 3D-editor and 3D-visualization system into Qucs.

[in3otd]

as ra3xdh, I too find the tabbed interface very user-friendly. I have usually several tabs open and the ability to switch back and forth quickly is very useful. I use other (commercial) SWs that uses the one-window-per-document style and with those I find switching between windows much less practical. If one day we will really have layout and/or EM simulation might make sense to have only those in separate windows (they might be tabbed windows themselves...) .

[yodalee]

Then, what if we separate Schematic file and Text file into different window? The current design problem is that, both schematic and text file have to insert into tabWidget, and we need a common interface to access some function, like save, load. To realize this, we have to create a qucsDoc and use double inheritance, and as I talk above, we need a complex casting(QWidget-> schematic or textdoc -> qucsdoc) to perform the function. To solve this complex casting, we need to separate schematic and textdoc into different window. This will make our coding more simple, easy to modification.

[ra3xdh]

I think we should save tabbed interface despite coding problems. I used different proprietary circuit simulators (MicroCAP,EWB,Multisim,OrCAD,AWR and others) and Qucs has the best interface and circuit editor among them. If we implement your suggestion we obtain MicroCAP-style interface. I used it, and it is not so good. New document types (EM sim, PCB) will not be added in near future or require independent application. The most of people prefer tabbed interfaces. I use Qucs for teaching of students at Radioelectronics department of our University. My students prefer tabbed interface of Qucs. I don't recommend you to remove tabs.

[yodalee]

Here is what my suggestion: keep tabs interface, but separate Schematic and Text file We can open many schematic files in a tab interface, but text files in another tab. Don't keep them in the same window. A simple separation can make code in qucs.cpp much simpler.

[ra3xdh]

So you suggest one windows -- for schematics and displays and another window --- for text docs?

[yodalee]

Yes, I prefer one file one window more. But if we choose tabbed interface, at least schematic and text should not in same window. I think this design will be better for qucs.cpp, we can cast QWidget direct to Schematic. The function becomeCurrent, isTextDocument is no longer need. There are so many if(isTextDocument()) { } else { } pattern in qucs.cpp, qucs_actions.cpp, they will become simpler too.

[ra3xdh]

There is an issue only with text documents? What do you think about to remove text editor from Qucs and use system text editor instead (kwrite, gedit, etc.)? System text editor may be powerful replacement for embedded Qucs editor. There may be issue for Windows users, because the Windows has only stub instead of editor (notepad.exe)

[yodalee]

I have think about this once, that will make qucs much more simpler, and more concentrated. The only question is function: there is simulation in qucs for text file. I'm not sure whether it works actually . If using system text editor. we cannot perform the simulation any more. If you ask my opinion.... vote one for removing text editor.

[guitorri]

What is the problem? Is it about UI usability or C++ object inheritance?

@arhiv6, in case the user dislike the text file in a tab he/she can already set an external editor in the settings.

The Octave/Verilog-A rely on the TextDoc to ease the work. For example in case a compilation error is raised by the Verilog-A builder the console links back to line on the text causing the issue (to ease debugging)... There is no (simple) way of doing that with an external editor.

Qucs has the tabbed interface for schematic/display/text for as long as I remember... and so it should remain. People expect it to be the way it is now. I find it very usable and without strong arguments we are not changing this.

The point of having QucsDoc as base class for Schematic and TextDoc is to avoid code duplication. See the QucsDoc class. Basically every tab is a different container for stuff, and it is only natural that the application needs to know which is the current container it is interacting with.

@yodalee I can count 17 instances of isTextDocument and 12 of becomeCurrent, are these too many? Maybe we can let the Schematic and TextDoc inform the QucsDoc who is the current document and its type. Other than that I fail to understand what is really bothering you.

[arhiv6]

@guitorri, your called me? I sometimes use LTspice and AWR, and I like its interface. I can use tab-view or subwindow-view mode at choice. Well, when there is a choice. Qt has support it: QMdiArea::setViewMode(QMdiArea::TabbedView) and QMdiArea::setViewMode(QMdiArea::SubWindowView) respectively.

[yodalee]

• To the issue of deleting qucseditor:

If Octave/Verilog-A rely on TextDoc, then I will vote one for keeping it.

• To the issue of Qucsdoc.

I know the purpose QucsDoc well. it provides a common interface to call function. To integrate everything into Tabbed Widget, it necessary to this kind of design. But it got many drawback. We have to determines the document type, changing the UI by document type, performing different action based on type. If you ask me 17 isTextDocument is too many... YES, IT IS MANY. Imagine you wanna add another type of document, such as EM file, you need add another else if {} pattern, and go through every if ... else, it's error-prone design. The code become ugly too, you can see what we do after calling isTextDocument. We cast the QWidget to Schematic or TextDoc, then cast it to QucsDoc. If schematic and textdoc are separated, the casting is no need, either. A more serious problem is that we cannot distinguish EM file and Schematic if they are both inherited from QGraphicView, then QucsApp will have to maintain a list of type of open files. The code become more complex, and difficult to modify. The problem exist now, if you try to add a new action only for Schematic, you need to do following modification:

1. Add action to QucsApp
2. Modify becomeCurrent in Schematic
3. Modify becomeCurrent in TextDoc. (more if there are other type) The last two steps is unnecessary if we split them into two different interface. Again, the modification if error-prone. That is the difference between good design and bad one: the difficulty to add new function and do modification. And I have to say that QucsDoc didn't avoid code duplication, it IS code duplication. TextDoc don't need GridOn, tmpPos[XY], showBias, showAll(). Schematic don't need SimTime. But they all exist in QucsDoc. Take it more seriously, make Schematic and Textdoc in same Window IS code duplication. What you disable in function becomeCurrent is not necessary to that kind of document, the function can be eliminated if you choose separate window. If we wanna qucs become more flexible, easy to modify, the interface should be changed.

[guitorri]

Sorry @arhiv6, I mean to call @ra3xdh.... Thank you for the hint TabbedView and subWindowView

[ra3xdh]

I found a case where simulation of a text tab could be used. We can add direct simulation of netlists and spice-netlists without schematic. So text editor need to be saved. @yodalee , We should implement EM structure editor as separsted application. Intetfacing should be implemented via special file component. It's not need to embed these function in Qucs. Maybe this should be separated project. What new documents you want to add. @guitorri I also don'see big problems with QucsDoc

[yodalee]

What I suggest is "Implement Text Editor as a separated application". I don't see the reason to insist that Schematic and Text should be in the same window, here. While you deciding that EM structure should be a separated project, then why cannot Text Editor? I would say this: Sure there is no big problems with QucsDoc, as long as you don't touch it. So if you want Qucs become a program that never grows up, we can keep same interface do no modification to it.

[guitorri]

@yodalee, I guess you mean the TextDoc class by 'Text Editor'. How can we render text (with syntax highlight, and debugger features) in a tab without it?

I agree that most of the becomeCurrent and isTextDocument can be removed and moved to either TextDoc or the Schematic classes. It would clean a bit the mess on qucs.cpp and qucs_actions.cpp. If that is not enough we can create another abstract class that handles the 'context change' that happens when a different type of document becomes active.

[yodalee]

I'm not talking remove TextDoc. I suggest make a own window(with it's own Tab widget) to manage those file of text file. Just like what you suggest to EM structure: "implement EM structure editor as separated application.". I suggest "implement TextDoc Editor as a separated application" becomeCurrent is already in TextDoc and Schematic. isTextDocument have to be there, since what you get is only a QWidget from Tab Widget, you have to decide it is Schematic or TextDoc.

[guitorri]

So, you want to implement a general purpose text editor which is independent of Qucs-GUI?

[yodalee]

Just inherit QPlainTextEdit, like the current version, is fine. You can think like this: there will be two mainwindow, one of them only open Schematic, one of them only open TextDoc. The important point is, separate Schematic and TextDoc from the same QTabWidget, so we don't need to take care what type of document we are edit, they are all Schematic or they are all TextDoc. Remove those pointer casting in qucsApp and UI change in becomeCurrent.

[guitorri]

Well, that is not what you said. You said "implement TextDoc Editor as a separated application".

If the Schematic and TextDoc are in different QTabWidget, we cannot freely move the tabs left and right, you need two levels of tabs.

[yodalee]

Yes, I don't want user freely moving the tabs of Schematic and TextDoc freely in a same QTabWidget. I want to create another window for TextDoc. They can play moving the tabs of "ALL Schematic" or "ALL TextDoc", not mixed one.

[guitorri]

Why?

[yodalee]

I write so many reason: difficulty to expand, not necessary pointer casting. The mixed tab add additional work to programmer who modifies it Anyway, I can write a simple demo to my thought, and you can decide whether to accept it.

[in3otd]

I think the question should be seen under a different point of view: not how we should change the GUI to have a nicer and easy to maintain code but how we should change the code to have a nicer and easier to use GUI . Usability questions and the user point of view should come first always. So before digging into the implementation details we should discuss if and how the GUI should be changed to improve the so-called "user experience". Since there will be as many opinion as people involved in the discussion (or more) , this will probably be better addressed on the devel or even help mailing lists.

[guitorri]

+1

[ra3xdh]

@in3otd I am strongly agreed with you. From user point of view tabbed interface is the most preferable. There is no doubt.

@yodalee What new document types you want to add right now? How you imagining document types number growth except PCB editor and EM simulator?

[yodalee]

I make a very simple demo to my thought at here: https://github.com/yodalee/qucs/tree/demo-split-textwindow You can try activate "New Text", it pop another window with Tabwidget inside, the new file will be open there. I only implement "New Text" since I just wanna express my thought, actually "Open File" will also open TextDoc there. So what's the benefit? As I said above, we don't need becomeCurrent, qucsDoc, pointer casting. The window UI can be design specifically to TextDoc or Schematic.

---

ra3xdh you think more? Forget it. Don't even think of PCB editor or EM simulator, the current state of qucs cannot add ANY new type of document. Even if you add them brute force, you have no choice but making qucs.cpp larger and larger. Current design is a dead end, keeping adding new type of document only makes the code more messy, more difficult to maintain, and worst of all, more difficult to turn back to right path.

[guitorri]

Linking CXX executable qucs.app/Contents/MacOS/qucs
Undefined symbols for architecture x86_64:
  "TextWindow::slotFileNew()", referenced from:
      QucsApp::slotTextNew() in qucs.cpp.o
      TextWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) in moc_textwindow.cxx.o

[guitorri]

Ops, clicked commet by mistake... @yodalee something is missing, see above

[yodalee]

@guitorri I forgot add TextWindow.cpp into CMakeLists.txt, just push another commit. I will delete this message after you compile successfully

[ra3xdh]

@yodalee You firstly mentioned these new documents? I didn't want to add new documents types. At current state we have 3 types of documents:

1. Schematics
2. Display pages
3. Text documents

For example proprietary circuit simulator MicroCAP also have only these three documents types. I only want to know what new documents you want to add except three just mentioned?

[yodalee]

In road map there is layout editor and EM field simulator, I think these are two other types of document we will add in the future. Or if you guys wanna remove some plan from Roadmap.

[ra3xdh]

Only these two new documents? I think adding these documents make monster from Qucs. We can understand roadmap in a wide range. We don't need to embed them into Qucs schematic editor. It will be really dead end. Special CADs serve for PCB design purposes. We don't need build our own the best PCB CAD from the scratch. For PCB Other EDA CADs have separated schematic editor and PCB layout editor. So, old interface can serve us a very long time. Roadmap mentions only link with existing PCB design CAD KiCAD. It may be solved without new documents addition.

I wrote on EM simulator embedding above. It also don't need to be embedded in QucsGUI. It should be separated project with separated sources.

I built your experimental branch and tested your configuration. Separated text and schematic is not so convenient. It may be useful only for 2-monitor desktops. You can have schematics on one monitor and texts on another monitor. But, need we really this feature?

[yodalee]

Yes so I'm saying that, we de-embed Text Document from schematic editor, is that hard to understand? You think EM simulator should be separated sources, I suggest Text Document should be a separated source too. I will say it clearly: EM simulator is not only no need to be embedded in QucsGUI, IT IS unable to be embedded.

[ra3xdh]

I understand this. It's need to de-embed Text documents only by reason of these two nonexistent new document types?

[yodalee]

You ask my suggestion? Definitely YES. Current design make the code difficult to maintain, error-prone to modification. Think about the future. The "two nonexistent new document" are impossible to be added by the current state you understand. Unless you are satisfied with the current state of Qucs project, we have to change for expandability. I cannot understand why you think EM simulator should be a separated project while Text Document should be a integrated one, because it's fine now? Because it's like this in the beginning? Great then we stop developing now, because current state is the best one. Modification only brings error. A slightly change in GUI will kill all Qucs users. No matter what, my suggestion is very simple. What ra3xdh do to EM simulation document is what my suggestion to Text Document.

[guitorri]

@yodalee I am sorry but we are going to keep the schematic / display / text tabs as it is now. There is no user benefit on putting the text into a separate window.

It does not make sense to change the UI because the code might be difficult to maintain. We should fix the code if that is the case.

This seems appropriate: http://c2.com/cgi/wiki?YouArentGonnaNeedIt You should only write code when you need it.

Note that the EM simulator and layout tools mentioned on the roadmap are supposed to be third party tools. Just like we do with Icarus, ASCO and freehdl. Strong candidates are openEMS, KiCad and KLayout. It does not make much sense to incorporate the functionality from these packages inside Qucs. That would create an excessive bloat that we don't want. Qucs is known for its simplicity. We should focus on the "do one thing and to it well".

About the EM simulator, is more like Qucs being able to drive the simulator and collect the results. If the EM simulator has no graphical 2D/3D model builder, we might need to do that. But it would be another tool, not incorporated on the Qucs schematic capture/simulation tool. Anyway, things might look different is in the future...

If you have suggestions on how we can improve the situation in current code, please open another issue or PR.

[yodalee]

Yes so I suggest: do one thing and do it well. The current mainwindow do many things. It do schematic editor, and Text editor at the same time, is that one thing? Do Text Document needs "Calculate DC Bias" button? Do "Activate/Deactivate" a proper name for "comment out" in Text Document? There are all mixing together OK. The mainwindow is not do one thing and do it well. It is do many things and do them only. Try to modify it, you will find you stick in the mud of code. －－ We should do one thing -> current window do so many thing We should separate EM into another tool -> Text should be integrated You guys are contradict to yourself. And yes, I code when I need it. I need the simplicity and expandability after refactor. That is not only "easy to maintaining" but also "easy to expand" it. As I said, unless you want Qucs stops here and never adds new functionality, otherwise, we have to move forward. －－ I don't care about what you think about EM simulator or Layout or other things. They are all bubble now. Because you stick on the current state, not changing the UI just because some easy heart-breaking users.

[guitorri]

Yes, the idea is to have a simple and ease to use schematic capture and circuit simulator. This is one thing.

We need text files to simulate stuff (spice netlists, octave, verilog...). It helps to have them in a tab besides the schematic where they are being used. If the user don't like that, you can override the editor in the settings and use an external editor. In the text mode the "Calculate DC bias" is disabled. The "Activate/Deactivate" should also be disabled, it is a bug.

Frankly I don't see any contradiction.

I don't understand why seem so defensive, you asked a question and you got 3 answers.

As a result we are not separating the TextDoc from the QTabWidget at this moment.

As you said the if EM and layout are "all bubble now", then we have to agree that we don't need refactoring right now.

If you feel like doing the refactoring anyway, please open another issue or PR and we can discuss it further.

It is not about user hearts here, but we should try to make the UI more usable not less...

[yodalee]

Maybe I'm too offensive, but I just don't understand why we stop here. There is many things we can do in the future, I don't want to stop here and see this project never change here after. Why you just give up and say "Yeah, they are all bubble and we will not support them forever". I want the bubble become REAL OK. If the answer of you guys are all definitely no, then I think there is nothing this issue can talk about. There is vision about the future. Try to make it real, and you will find that refactor is needed.

---

Actually "Activate/Deactivate" is not a bug, in Text Document it becomes "Comment out" text. But see, it's error-prone. Adding one Action into the window, forgot to change it in the becomeCurrent of Text Document. I remember someone call this self-commented, but the truth is what you see(activate/deactivate) becomes something else. Maybe I should call this self-misleading-commented. The refactor is trying to solve this problem, making the code more easy to expand and not so error-prone. Simply split into two window solve this problem, I don't see the usability of UI downgrade here. Multi-window are common to other simulation software, some even split schematic with display, like Agilent ADS.