Re: [Qucs-devel] Qucs tools

[Stefan Jahn <stefan@gr...>]

Am Do, 7.09.2006, 09:06, schrieb Gopala Krishna:

> Hello Stefan,

Hi Gopala,

>    I am facing few problem in porting Qucs-Transcalc. The problem is
> it uses some classes like QHBox,QVBox,QHButtonGroup... which are
> deprecated in Qt4 and available only in Qt3 support libs. All these
> have to be replaced by Q*Layout alternatives which is quite confusing
> for me since some functions use QVBox** as their arguments and loops
> over this.
>        I understand that Qucs-transcalc was originally ported from gtk
> to qt. But I could see from that site that there was no major work
> being done (unfortunately the commit statistics are not available for
> cvs).

Well, the major work was done, before committing...

>  So, I feel we can redesign this app to be more organised as well as
> more robust. I don't mean that , it is not robust now. But we can
> atleast improve and build upon their work.

Whose work?

>      I do have to discuss one more point with you. The qucs tools i.e
> attenuator, transcalc, edit, filter and lib (everything except help)
> are meant to be used with qucs. I mean they may not be of much use as
> individual programs (correct and excuse me if I'm wrong ). We can
> easily merge the code into main qucs and use these tools by creating
> the respective objects of their own when needed instead of creating
> new processes for them. This also improves the performance of the
> system.
>
>  So, what is your opinion about my views ?
> Please excuse me if I am wrong and do enlighten me in that case :-)

Basically I do like the idea of having different applications for different
tasks.  As long as the interface between these applications is suffieciently
easy...  Having different programs also makes maintainance a bit easier.
Of course, code-reuse would be easier if we had one big application.  But
this can also be achieved by using libraries which are shared by
applications.

Generally spoken performance is not a criteria right now, but stability
should be.  Also I think we wouldn't gain any speed when having one big
application.  I just doubt that.  Imagine you have a small little bug
in the attenuator app which causes a segfault.  That would crash the
application, which is not what you want I think.

Thus your point about the tools being "much use as individual programs"
I don't agree with.  For instance someone could make an effort to export
SPICE netlists from these (e.g. for the filters), then the program is of
use "as individual program" independent from Qucs...

Do you agree?

Stefan.

[Qucs-devel] Qucs tools

[Gopala Krishna <krishna.ggk@gm...>]

Hello Stefan,
   I am facing few problem in porting Qucs-Transcalc. The problem is
it uses some classes like QHBox,QVBox,QHButtonGroup... which are
deprecated in Qt4 and available only in Qt3 support libs. All these
have to be replaced by Q*Layout alternatives which is quite confusing
for me since some functions use QVBox** as their arguments and loops
over this.
       I understand that Qucs-transcalc was originally ported from gtk
to qt. But I could see from that site that there was no major work
being done (unfortunately the commit statistics are not available for
cvs).
 So, I feel we can redesign this app to be more organised as well as
more robust. I don't mean that , it is not robust now. But we can
atleast improve and build upon their work.

     I do have to discuss one more point with you. The qucs tools i.e
attenuator, transcalc, edit, filter and lib (everything except help)
are meant to be used with qucs. I mean they may not be of much use as
individual programs (correct and excuse me if I'm wrong ). We can
easily merge the code into main qucs and use these tools by creating
the respective objects of their own when needed instead of creating
new processes for them. This also improves the performance of the
system.

 So, what is your opinion about my views ?
Please excuse me if I am wrong and do enlighten me in that case :-)

-- 
Cheers,
Gopala Krishna A

Re: [Qucs-devel] Qucs tools

[Stefan Jahn <stefan@gr...>]

Am Do, 7.09.2006, 09:06, schrieb Gopala Krishna:

> Hello Stefan,

Hi Gopala,

>    I am facing few problem in porting Qucs-Transcalc. The problem is
> it uses some classes like QHBox,QVBox,QHButtonGroup... which are
> deprecated in Qt4 and available only in Qt3 support libs. All these
> have to be replaced by Q*Layout alternatives which is quite confusing
> for me since some functions use QVBox** as their arguments and loops
> over this.
>        I understand that Qucs-transcalc was originally ported from gtk
> to qt. But I could see from that site that there was no major work
> being done (unfortunately the commit statistics are not available for
> cvs).

Well, the major work was done, before committing...

>  So, I feel we can redesign this app to be more organised as well as
> more robust. I don't mean that , it is not robust now. But we can
> atleast improve and build upon their work.

Whose work?

>      I do have to discuss one more point with you. The qucs tools i.e
> attenuator, transcalc, edit, filter and lib (everything except help)
> are meant to be used with qucs. I mean they may not be of much use as
> individual programs (correct and excuse me if I'm wrong ). We can
> easily merge the code into main qucs and use these tools by creating
> the respective objects of their own when needed instead of creating
> new processes for them. This also improves the performance of the
> system.
>
>  So, what is your opinion about my views ?
> Please excuse me if I am wrong and do enlighten me in that case :-)

Basically I do like the idea of having different applications for different
tasks.  As long as the interface between these applications is suffieciently
easy...  Having different programs also makes maintainance a bit easier.
Of course, code-reuse would be easier if we had one big application.  But
this can also be achieved by using libraries which are shared by
applications.

Generally spoken performance is not a criteria right now, but stability
should be.  Also I think we wouldn't gain any speed when having one big
application.  I just doubt that.  Imagine you have a small little bug
in the attenuator app which causes a segfault.  That would crash the
application, which is not what you want I think.

Thus your point about the tools being "much use as individual programs"
I don't agree with.  For instance someone could make an effort to export
SPICE netlists from these (e.g. for the filters), then the program is of
use "as individual program" independent from Qucs...

Do you agree?

Stefan.

Re: [Qucs-devel] Qucs tools

[Gopala Krishna <krishna.ggk@gm...>]

Hello Stefan,

First of all thanks for your early response :-)
> Well, the major work was done, before committing...
Got it ! But I meant there won't be much changes in transcalc as of now :)

> Whose work?
Authors of transcalc(Gopal Narayanan and Claudio Giradi)

> Do you agree?

Perhaps , not exactly Stefan.

> Basically I do like the idea of having different applications for different
> tasks.  As long as the interface between these applications is suffieciently
> easy...  Having different programs also makes maintainance a bit easier.
> Of course, code-reuse would be easier if we had one big application.  But
> this can also be achieved by using libraries which are shared by
> applications.
       I don't see any differences in maintainance if the code will be
merged. Even though the code will be merged we need not clutter them.
We can have a directory called tools and in that we can again have
separate directories for each tool.
         May be you meant testing the tool will be easy after any
modification. But you can see that each tool has tQucsSettings defined
separately to suit their needs. Instead one singleton class would
suffice if the tool were to be used as part of the main application.
Also you need to have main function for each program with
Menubar,toolbar and you need to again define
loadSettings(),saveSettings() ..so we lose the advantages of code
reuse. Also new tools will be added in future as qucs progresses and
the same processes described above has to be followed to each.
  But your shared library idea is good :-)


> Generally spoken performance is not a criteria right now, but stability
> should be.  Also I think we wouldn't gain any speed when having one big
> application.  I just doubt that.  Imagine you have a small little bug
> in the attenuator app which causes a segfault.  That would crash the
> application, which is not what you want I think.
      But anyway , bugs are BUGS and are meant to be fixed. Just think
a person will be using a tool which segfaults .While using the tool ,
suddenly it disappears without any error message . Or sometimes the
tool may not even start. Then that person will be more confused. This
is because the person won't know that only the tool crashed. So he
will rarely report this !!
       But suppose the application crashes. Then the user will know
that the application crashed and there is good chance he will report
this bug and hopefully this will be fixed ! :-)

> Thus your point about the tools being "much use as individual programs"
> I don't agree with.  For instance someone could make an effort to export
> SPICE netlists from these (e.g. for the filters), then the program is of
> use "as individual program" independent from Qucs...
    Yes , I agree that the tool "as individual program" is not
useless. But I think only a few of the users will use these tools
individually. That  too , at present ,they are more useful with qucs.
I don't mean useless otherwise. Also no one can/will download only
tools without qucs.
As you mentioned about SPICE example, that can be done eventhough the
tool is not individual program.

Am I right ? If not do enlighten me :-)
-- 
Cheers,
Gopala Krishna A

Re: [Qucs-devel] Qucs tools

[Stefan Jahn <stefan@gr...>]

Am Do, 7.09.2006, 11:11, schrieb Gopala Krishna:

> Hello Stefan,

Hi Gopala,

> First of all thanks for your early response :-)
>> Well, the major work was done, before committing...
> Got it ! But I meant there won't be much changes in transcalc as of now :)

Except adding more types of transmission lines.

>> Basically I do like the idea of having different applications for
>> different
>> tasks.  As long as the interface between these applications is
>> suffieciently
>> easy...  Having different programs also makes maintainance a bit easier.
>> Of course, code-reuse would be easier if we had one big application.
>> But
>> this can also be achieved by using libraries which are shared by
>> applications.
>
>        I don't see any differences in maintainance if the code will be
> merged. Even though the code will be merged we need not clutter them.
> We can have a directory called tools and in that we can again have
> separate directories for each tool.
>          May be you meant testing the tool will be easy after any
> modification. But you can see that each tool has tQucsSettings defined
> separately to suit their needs. Instead one singleton class would
> suffice if the tool were to be used as part of the main application.
> Also you need to have main function for each program with
> Menubar,toolbar and you need to again define
> loadSettings(),saveSettings() ..so we lose the advantages of code
> reuse. Also new tools will be added in future as qucs progresses and
> the same processes described above has to be followed to each.

I see your point.  I also wished code-sharing exactly for the above
items you mentioned.

> But your shared library idea is good :-)

Probably you can improve the situation by a library.!? :-]

>> Generally spoken performance is not a criteria right now, but stability
>> should be.  Also I think we wouldn't gain any speed when having one big
>> application.  I just doubt that.  Imagine you have a small little bug
>> in the attenuator app which causes a segfault.  That would crash the
>> application, which is not what you want I think.
>
>       But anyway , bugs are BUGS and are meant to be fixed. Just think
> a person will be using a tool which segfaults .While using the tool ,
> suddenly it disappears without any error message . Or sometimes the
> tool may not even start. Then that person will be more confused. This
> is because the person won't know that only the tool crashed. So he
> will rarely report this !!
>        But suppose the application crashes. Then the user will know
> that the application crashed and there is good chance he will report
> this bug and hopefully this will be fixed ! :-)

This doesn't count!!!

A little comparison:  A bluescreen in Windows tells the user there is
something wrong.  But it simply annoys a user and does not make him write
a bug report.

Though this comparison is somewhat unfair, it clarifies my opinion.

>> Thus your point about the tools being "much use as individual programs"
>> I don't agree with.  For instance someone could make an effort to export
>> SPICE netlists from these (e.g. for the filters), then the program is of
>> use "as individual program" independent from Qucs...
>
>     Yes , I agree that the tool "as individual program" is not
> useless. But I think only a few of the users will use these tools
> individually. That  too , at present ,they are more useful with qucs.
> I don't mean useless otherwise. Also no one can/will download only
> tools without qucs.
> As you mentioned about SPICE example, that can be done eventhough the
> tool is not individual program.

This is right.

For developers who want improve a section of code somewhere in Qucs
it may be easier to understand a "smaller" individual program rather
than understanding the whole application (though she/he doesn't need
to).  Also it inhibits "side-effects" as changes to a tool (when
located in a big app) become more substantial.

Cheers, Stefan.

Re: [Qucs-devel] Qucs tools

[Gopala Krishna <krishna.ggk@gm...>]

Hello Stefan,

> Probably you can improve the situation by a library.!? :-]
I will see this matter a bit later .

> This doesn't count!!!
> A little comparison:  A bluescreen in Windows tells the user there is
> something wrong.  But it simply annoys a user and does not make him write
> a bug report.
> Though this comparison is somewhat unfair, it clarifies my opinion.
 But still bugs are quite rare in release versions (tested). And bugs
anywhere , either in main app or tools are to be fixed !! So , whether
the whole app crashes or only the tool crashes , any of these means
BUG. But to support your concern ,we can introduce autosave feature to
overcome this. This is what I feel is better.

> This is right.
>
> For developers who want improve a section of code somewhere in Qucs
> it may be easier to understand a "smaller" individual program rather
> than understanding the whole application (though she/he doesn't need
> to).  Also it inhibits "side-effects" as changes to a tool (when
> located in a big app) become more substantial.
        Since we maintain separate classes for separate tools ,the
developer interested in specific part of specific tool can easily
concentrate on only those classes. I also told you that we can
maintain separate folders for separate tools. I also assure you that
there won't be any side effects since these tools just use the
settings part of qucs application and nothing else.

But never the less , I feel the current structure of the qucs
application is not bad(not at all !!).
The current structure has its own advantages as pointed by you. What I
wanted was to reduce some code by resuse and to make the tool to be
used without starting new processes.
I don't have any problems with current structure, though !! :-)
So what is your opinion now?

-- 
Cheers,
Gopala Krishna A

Re: [Qucs-devel] Qucs tools

[Stefan Jahn <stefan@gr...>]

Am Fr, 8.09.2006, 07:44, schrieb Gopala Krishna:

> Hello Stefan,

Hi Gopala!

  I see your arguments.  There are -- finally -- cons and pros.

> But never the less , I feel the current structure of the qucs
> application is not bad(not at all !!).
> The current structure has its own advantages as pointed by you. What I
> wanted was to reduce some code by resuse and to make the tool to be
> used without starting new processes.
> I don't have any problems with current structure, though !! :-)
> So what is your opinion now?

I feel like it is going to be good idea to put common functionality
into a library which can be reused by all qucs applications.  Thus we
can ensure not to duplicate code.  The two examples which I have
in mind are:

  1) load/save settings and part of application startup code

  2) the symbol drawing routines which are used in the library manager
     and the gui

Using the library approach we can reuse code (which I feel was your
main concern?) but keep applications separate.

Cheers, Stefan.