From: Gopala K. <kri...@gm...> - 2006-10-15 10:53:28
|
Hello guys, I have finished porting qucs-help, qucs-transcalc, qucs-attenuator and qucs-filter to Qt4. Now i am planning to start with qucs schematic application. This will involves a major re-write since I've decided to use QGraphicsView framework which comes with qt4.2 (was released on 4th october) to draw the schematics. Therefore I thought I can do the following improvements to the design of qucs. Firstly, I plan to adopt plugin structure to qucs. This has really many advantages. Qt4 has really made it easy to adopt plugin structure. In this case the above mentioned qucs tools will be made into plugins. The main advantage is many users will be able to write plugins that simplifies usage of qucs. For example some one could come up with advanced plotting tool. He need not go through the entire code at all. This greatly simplifies his work. Or he may write some interface plugin that convert the plot file structure to that of plot application he prefers. The second example could be that an advanced user can write a plugin to add specially improved component/model to suit him. Secondly, i have plans to make some changes to user interface and make it more intutive. I plan to provide interface to resemble ideal theme of kde apps(default in kdevelop) I also want to make qucs completely customizable. i have ideas to add progress bar to statusbar and maintain responsiveness when qucsator is running in background. So please guys, give me your opinions about this. Also please do give some IDEAS about any feature you feel like to be added to qucs so that i can plan for those too. Thanks for your response in advance. -- Cheers, Gopala Krishna A |
From: Gopala K. <kri...@gm...> - 2006-11-01 11:20:54
|
Hello all, The qt4 port is coming well. I am testing it now and then. But still it has to go long way. I had to inform you that it will take still more time. It is almost like a complete rewrite. Also I need to make sure that I learn and utilize the new qt4 frameworks very well. The current status of the port is, it displays a main window, with few components in left toolview and tabs containg schematic views. The components like resistor,capacitor etc can be moved and rotated in the view. But still I got to do with wire and connection management. Currently i am working on undo-redo functionality based on command pattern. -- Cheers, Gopala Krishna A |
From: Raimund 'R. J. <ra...@lk...> - 2006-10-15 11:52:53
|
Gopala Krishna wrote: Hello Gopala! > I have finished porting qucs-help, qucs-transcalc, qucs-attenuator > and qucs-filter to Qt4. Now i am planning to start with qucs schematic > application. This will involves a major re-write since I've decided to > use QGraphicsView framework which comes with qt4.2 (was released on > 4th october) to draw the schematics. Therefore I thought I can do the > following improvements to the design of qucs. thanks for all your work so far. using qt4.2 is ok, so go for it. > Firstly, I plan to adopt plugin structure to qucs. This > has really many advantages. Qt4 has really made it easy to adopt > plugin structure. In this case the above mentioned qucs tools will be > made into plugins. (how does pair with stefan's wish of not putting everything in one big application but rather use a shared library between stand-alone applications?) [...] > Secondly, i have plans to make some changes to user > interface and make it more intutive. I plan to provide interface to > resemble ideal theme of kde apps(default in kdevelop) > I also want to make qucs completely customizable. i have ideas to add > progress bar to statusbar and maintain responsiveness when qucsator is > running in background. those changes are ok for me as long as you can manage to finish within a reasonable amount of time. there are translations and features already that need to be ported to your branch once it compiles cleanly. the longer you need the more such features may creep in, although stefan and michael are keeping their feet still. when making your plugin-infrastructure dont over-generalize! it's very very hard to create a pluggable architecture when you dont know any plugins, yet (so you dont know what APIs a plugin-author might need). also, i hope you refer to source-level plugins. i think qucs is not (yet) the kind of application to dynamically load binary plugins from .so/.dll files. i dont want to discourage you, just remind you on what the other developers are currently waiting for. i think your main focus should be to converge towards a compilable branch of pure qt4-code. once you have this, everyone can help you with the bigger ideas. the original idea of this branch was indeed to convert it to qt4 as quickly as possible and then improve qucs from there. good luck, Raimund -- ___ ___ _____________ / /| / /_ / ____/ ___/\ Nothing useful for / / / / _ / / __/ / __\/ more than a decade / /_/_/ \/ /_/_/ /_/ {www.|raimi@} /______/__/\._\.____/\.____/\ .org \._____\._\/\._\.___\/\.___\/ |
From: Gopala K. <kri...@gm...> - 2006-10-15 12:51:17
|
Hello Raimund, > thanks for all your work so far. using qt4.2 is ok, so go for it. Thanks. > (how does pair with stefan's wish of not putting everything in one big > application but rather use a shared library between stand-alone > applications?) This is a different issue i thought of recently so that you can provide more features to qucs and make it easier to code. Its not related to the idea of shared library. > those changes are ok for me as long as you can manage to finish within a > reasonable amount of time. there are translations and features already > that need to be ported to your branch once it compiles cleanly. the > longer you need the more such features may creep in, although stefan and > michael are keeping their feet still. I'll try to finish it as fast as possible. I also finished my tests recently so will have more time for qucs. :-) > when making your plugin-infrastructure dont over-generalize! it's very > very hard to create a pluggable architecture when you dont know any > plugins, yet (so you dont know what APIs a plugin-author might need). Yeah. I'll follow your guideline. > also, i hope you refer to source-level plugins. i think qucs is not > (yet) the kind of application to dynamically load binary plugins from > .so/.dll files. But qt4 has really eased to develop plugin structure. Why can't we take advantage of this ? > i dont want to discourage you, just remind you on what the other > developers are currently waiting for. i think your main focus should be > to converge towards a compilable branch of pure qt4-code. once you have > this, everyone can help you with the bigger ideas. the original idea of > this branch was indeed to convert it to qt4 as quickly as possible and > then improve qucs from there. i'm sorry for this change of idea. I never knew i will go for qt4.2 since I didn't know it will be released so soon. I will try my best to do it fast. :-) > good luck, Thanks for your kind support ! -- Cheers, Gopala Krishna A |
From: Raimund 'R. J. <ra...@lk...> - 2006-10-15 20:25:51
|
Gopala Krishna wrote: Hello again! >> also, i hope you refer to source-level plugins. i think qucs is not >> (yet) the kind of application to dynamically load binary plugins from >> .so/.dll files. > But qt4 has really eased to develop plugin structure. Why can't we > take advantage of this ? ok, i didnt know there would be something providing by qt4 you want to use. since i've never done qt stuff by myself (i'm more of a backend programmer) i trust your judgement :) just watch your priorities :) keep up the good work, Raimund -- ___ ___ _____________ / /| / /_ / ____/ ___/\ Nothing useful for / / / / _ / / __/ / __\/ more than a decade / /_/_/ \/ /_/_/ /_/ {www.|raimi@} /______/__/\._\.____/\.____/\ .org \._____\._\/\._\.___\/\.___\/ |
From: Stefan J. <st...@gr...> - 2006-10-19 18:01:47
|
Am So, 15.10.2006, 14:51, schrieb Gopala Krishna: Hi! >> when making your plugin-infrastructure dont over-generalize! it's very >> very hard to create a pluggable architecture when you dont know any >> plugins, yet (so you dont know what APIs a plugin-author might need). > Yeah. I'll follow your guideline. > >> also, i hope you refer to source-level plugins. i think qucs is not >> (yet) the kind of application to dynamically load binary plugins from >> .so/.dll files. > > But qt4 has really eased to develop plugin structure. Why can't we > take advantage of this ? So which are the advantages? Because something is easy and sounds good (I consider the word "plugin" a "buzzword") you do not want to just use it because it was praised somewhere... Never mind! Cheers, Stefan. |
From: Stefan J. <st...@gr...> - 2006-10-19 17:58:10
|
Am So, 15.10.2006, 12:53, schrieb Gopala Krishna: > Hello guys, Hi Gopala, > I have finished porting qucs-help, qucs-transcalc, qucs-attenuator > and qucs-filter to Qt4. Now i am planning to start with qucs schematic > application. This will involves a major re-write since I've decided to > use QGraphicsView framework which comes with qt4.2 (was released on > 4th october) to draw the schematics. Sounds good. Thanks for all your efforts so far! > Therefore I thought I can do the > following improvements to the design of qucs. > > Firstly, I plan to adopt plugin structure to qucs. This > has really many advantages. Qt4 has really made it easy to adopt > plugin structure. In this case the above mentioned qucs tools will be > made into plugins. > The main advantage is many users will be able to write plugins that > simplifies usage of qucs. For example some one could come up with > advanced plotting tool. He need not go through the entire code at all. > This greatly simplifies his work. Or he may write some interface > plugin that convert the plot file structure to that of plot > application he prefers. > The second example could be that an advanced user can write a plugin > to add specially improved component/model to suit him. It is not very likely that anyone else than yourself, Michael and me is going to modify anything in the Qucs GUI. That is why the plugin- thingie isn't that necessary. Is the plotting plugin the only example you have in mind? Or even others? > Secondly, i have plans to make some changes to user > interface and make it more intutive. I feel like it is intuitive already. > I plan to provide interface to > resemble ideal theme of kde apps(default in kdevelop) Please don't mix Qt and KDE. :-) > I also want to make qucs completely customizable. What exactly do you mean? > i have ideas to add > progress bar to statusbar Not that necessary I think, but if you want to... > and maintain responsiveness when qucsator is > running in background. I think it is responsive. You can start another simulation, modify schematics, etc. when a simulation runs. What do you mean? > So please guys, give me your opinions about this. Also > please do give some IDEAS about any feature you feel like to be added > to qucs so that i can plan for those too. > Thanks for your response in advance. Currently I just have this layout editor in mind... Cheers, Stefan. |
From: Gopala K. <kri...@gm...> - 2006-10-19 18:45:50
|
Hello Stefan, > Is the plotting plugin the only example you have in mind? Or even others? The other examples might be circuit optimizers( i think this exists already), gnucap/spice netlist generators, components arranger - that aligns the components with some AI ,... and we can come out with many more. > It is not very likely that anyone else than yourself, Michael and me > is going to modify anything in the Qucs GUI. That is why the plugin- > thingie isn't that necessary. Ok I do understand so i'll give low priority for this but still i wish this feature exists. What suppose qucs becomes very famous (recieves many awards) and many developers creep in ?? > I feel like it is intuitive already. yeah it is. that line slipped in by chance. i actually meant to improve the look and feel. > Please don't mix Qt and KDE. :-) I don't mean mixing. I have found a small library called Ideality. this will help in arrangement of sidebar windows (individually). i mean for example you can have components on left, projects on right , content below ... > > I also want to make qucs completely customizable. > > What exactly do you mean? Of course this is of lower priority. Customizable in the sense users should be able to set different colours to components. And yes the important one would be to redefine keys(shortcuts). Font and other settings are already supported , so thats it. > > i have ideas to add > > progress bar to statusbar > > Not that necessary I think, but if you want to... Actually what i feel is we can eliminate simulation dialog and display output in bottom sub-window( or sidebar) Thats why i told to replicate design of kdevelop and display progress in statusbar. But as i learnt we may not be able to display more than one progressbar(if 2 simulations are running) in statusbar. So i'll think about this later. > > and maintain responsiveness when qucsator is > > running in background. > > I think it is responsive. You can start another simulation, modify > schematics, etc. when a simulation runs. What do you mean? Ahh i see. The dialog resembles modal dialog. Modal dialogs are those which block input to other windows. So I'm sorry for this confusion. So we can add minimize button to this dialog to remove this confusion. Thanks for your response. Now I am going in depth of QGraphicsView thingie. It surely seems to make work easier. I want to make it clear that, my primary aim is to port to qt4.2 with no bugs. All other stuff will be added gradually (including plugins) -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2006-10-24 06:27:11
|
Am Do, 19.10.2006, 20:45, schrieb Gopala Krishna: > Hello Stefan, Hi Gopala, >> Is the plotting plugin the only example you have in mind? Or even >> others? > The other examples might be circuit optimizers( i think this exists > already), gnucap/spice netlist generators, components arranger - that > aligns the components with some AI ,... and we can come out with many > more. Well, I see. >> It is not very likely that anyone else than yourself, Michael and me >> is going to modify anything in the Qucs GUI. That is why the plugin- >> thingie isn't that necessary. > Ok I do understand so i'll give low priority for this but still i wish > this feature exists. What suppose qucs becomes very famous (recieves > many awards) and many developers creep in ?? > >> I feel like it is intuitive already. > yeah it is. that line slipped in by chance. i actually meant to > improve the look and feel. > >> Please don't mix Qt and KDE. :-) > I don't mean mixing. I have found a small library called Ideality. > this will help in arrangement of sidebar windows (individually). i > mean for example you can have components on left, projects on right , > content below ... > >> > I also want to make qucs completely customizable. >> >> What exactly do you mean? > Of course this is of lower priority. Customizable in the sense users > should be able to set different colours to components. And yes the > important one would be to redefine keys(shortcuts). Font and other > settings are already supported , so thats it. > >> > i have ideas to add >> > progress bar to statusbar >> >> Not that necessary I think, but if you want to... > Actually what i feel is we can eliminate simulation dialog and display > output in bottom sub-window( or sidebar) Thats why i told to replicate > design of kdevelop and display progress in statusbar. But as i learnt > we may not be able to display more than one progressbar(if 2 > simulations are running) in statusbar. So i'll think about this later. > >> > and maintain responsiveness when qucsator is >> > running in background. >> >> I think it is responsive. You can start another simulation, modify >> schematics, etc. when a simulation runs. What do you mean? > Ahh i see. The dialog resembles modal dialog. Modal dialogs are those > which block input to other windows. So I'm sorry for this confusion. > So we can add minimize button to this dialog to remove this confusion. > > Thanks for your response. Now I am going in depth of QGraphicsView > thingie. It surely seems to make work easier. I want to make it clear > that, my primary aim is to port to qt4.2 with no bugs. All other stuff > will be added gradually (including plugins) Thanks! Keep up the good work, Stefan. |
From: Stefan J. <st...@gr...> - 2006-10-24 06:29:50
|
Am Do, 19.10.2006, 20:48, schrieb Gopala Krishna: > Hello Stefan, Hi! >> So which are the advantages? Because something is easy and sounds good >> (I consider the word "plugin" a "buzzword") you do not want to just use >> it because it was praised somewhere... Never mind! > The main advantage is EXTENSIBILITY. Any average developer good in > some part can write plugins and the other advantage is that we may not > even accept plugin to be on our code. It can be 3rd party too. :-) In free software extensibility is given -- also without a plugin interface. But -- this 3rd party thing might be a good idea... not sure about that. Cheers, Stefan. |