From: Gopala K. <kri...@gm...> - 2007-04-17 19:26:43
|
Hello guys, For this week I implemented a filter, which filters components based on name typed in line edit in sidebar. This really helps to locate components at faster rate instead of navigating through all types of sources. Please do give me feedback about this feature! One good news. Ruso (or Martin) , friend of Lisandrop helped me by implementing slots corresponding to zoom and also some few other slots. Oh yeah, theres one more big change. Hence forth we thought of using Qt's resource system to store icons in binary format in platform independent way. Ruso did that and I commited that too. You can have a look at this link for more info http://doc.trolltech.com/4.2/resources.html Please do give feedback. -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2007-04-18 05:40:37
|
Am Di, 17.04.2007, 21:26, schrieb Gopala Krishna: > Hello guys, Hello Gopala, > For this week I implemented a filter, which filters components > based on name typed in line edit in sidebar. This really helps to > locate components at faster rate instead of navigating through all > types of sources. > Please do give me feedback about this feature! I will look at it. Thanks. > One good news. Ruso (or Martin) , friend of Lisandrop helped me > by implementing slots corresponding to zoom and also some few other > slots. Good to hear that. :-) > Oh yeah, theres one more big change. Hence forth we thought of using > Qt's resource system to store icons in binary format in platform > independent way. Ruso did that and I commited that too. You can have a > look at this link for more info > http://doc.trolltech.com/4.2/resources.html > > Please do give feedback. Actually I don't like the idea. I don't see an advantage for now. It's not related to "porting Qucs" and also not a conceptional change. With the bitmaps as seperate files it is easier to change them even with the application compiled and installed... Anyway, please don't feel bothered. If you really require the change you can leave it as is. Cheers, Stefan. |
From: Lisandro
<per...@gm...> - 2007-04-18 14:58:45
|
El Mi=E9rcoles 18 Abril 2007 02:40, Stefan Jahn escribi=F3: > Am Di, 17.04.2007, 21:26, schrieb Gopala Krishna: > > Hello guys, > > Hello Gopala, > > > For this week I implemented a filter, which filters components > > based on name typed in line edit in sidebar. This really helps to > > locate components at faster rate instead of navigating through all > > types of sources. > > Please do give me feedback about this feature! > > I will look at it. Thanks. > > > One good news. Ruso (or Martin) , friend of Lisandrop helped me > > by implementing slots corresponding to zoom and also some few other > > slots. > > Good to hear that. :-) > > > Oh yeah, theres one more big change. Hence forth we thought of using > > Qt's resource system to store icons in binary format in platform > > independent way. Ruso did that and I commited that too. You can have a > > look at this link for more info > > http://doc.trolltech.com/4.2/resources.html > > > > Please do give feedback. Please, note that I am writing this without any idea of doing a troll or=20 something like that, so if you find something written in a harsh way, pleas= e=20 let me know so as to try to avoid this kind of phrases in the future :-) > Actually I don't like the idea. I don't see an advantage for now. It's > not related to "porting Qucs" and also not a conceptional change.=20 I desagree here, please see my recent mail. > With=20 > the bitmaps as seperate files it is easier to change them even with the > application compiled and installed...=20 If changing icons it's a feature qucs would like to have (I guess not), the= n=20 it's as simple as using dynamic resources. They have the same advantages th= an=20 what I described, plus that they can be changed during execution time. > Anyway, please don't feel bothered.=20 > If you really require the change you can leave it as is. I don't really think it's a matter of "do as you think you need", but "hey,= =20 would this be useful or not?", which is a _very_ good question. Regards, Lisandro. =2D-=20 Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer a la comunidad SL como una sarta de fan=E1ticos que viven dentro de un tupperware. Pablo Di Noto - GruLic Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ |
From: roucaries b. <rou...@gm...> - 2007-04-18 08:10:56
|
On 4/18/07, Stefan Jahn <st...@gr...> wrote: > Am Di, 17.04.2007, 21:26, schrieb Gopala Krishna: > > > Hello guys, > > Hello Gopala, > > > For this week I implemented a filter, which filters components > > based on name typed in line edit in sidebar. This really helps to > > locate components at faster rate instead of navigating through all > > types of sources. > > Please do give me feedback about this feature! > > I will look at it. Thanks. > > > One good news. Ruso (or Martin) , friend of Lisandrop helped me > > by implementing slots corresponding to zoom and also some few other > > slots. > > Good to hear that. :-) > > > Oh yeah, theres one more big change. Hence forth we thought of using > > Qt's resource system to store icons in binary format in platform > > independent way. Ruso did that and I commited that too. You can have a > > look at this link for more info > > http://doc.trolltech.com/4.2/resources.html > > > > Please do give feedback. > > Actually I don't like the idea. I don't see an advantage for now. It's > not related to "porting Qucs" and also not a conceptional change. With > the bitmaps as seperate files it is easier to change them even with the > application compiled and installed... Anyway, please don't feel bothered. > If you really require the change you can leave it as is. Here I agree with Stephan. It will be better to keep the icons as files. It will be also better to describe each component in the gui by an xml file, that will include the number of port, the name of the component, the path to an icon file (preferably in vector graphics format) and a regexp (or a printf like string) for creating the simulation file. If we could do this, qucs core and qucs will be fully decoupled, ie we do not need to recompile qucs-gui if we add a new components to qucs-core. But I suppose it is a mid term goal. Regards Bastien > Cheers, Stefan. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Stefan J. <st...@gr...> - 2007-04-18 10:31:26
|
Am Mi, 18.04.2007, 10:10, schrieb roucaries bastien: Hello! >> > For this week I implemented a filter, which filters components >> > based on name typed in line edit in sidebar. This really helps to >> > locate components at faster rate instead of navigating through all >> > types of sources. >> > Please do give me feedback about this feature! >> >> I will look at it. Thanks. >> >> > One good news. Ruso (or Martin) , friend of Lisandrop helped me >> > by implementing slots corresponding to zoom and also some few other >> > slots. >> >> Good to hear that. :-) >> >> > Oh yeah, theres one more big change. Hence forth we thought of using >> > Qt's resource system to store icons in binary format in platform >> > independent way. Ruso did that and I commited that too. You can have a >> > look at this link for more info >> > http://doc.trolltech.com/4.2/resources.html >> > >> > Please do give feedback. >> >> Actually I don't like the idea. I don't see an advantage for now. It's >> not related to "porting Qucs" and also not a conceptional change. With >> the bitmaps as seperate files it is easier to change them even with the >> application compiled and installed... Anyway, please don't feel >> bothered. >> If you really require the change you can leave it as is. > > Here I agree with Stephan. It will be better to keep the icons as files. Thanks. > It will be also better to describe each component in the gui by an xml > file, that will include the number of port, the name of the component, > the path to an icon file (preferably in vector graphics format) and a > regexp (or a printf like string) for creating the simulation file. > If we could do this, qucs core and qucs will be fully decoupled, ie we > do not need to recompile qucs-gui if we add a new components to > qucs-core. But I suppose it is a mid term goal. This I also had it mind already. It would be something like the description of library elements. There is already a Symbol, Ports and Netlist description contained... Also it would be a step towards loadable add-on modules for components which is (I agree) a mid term goal. But also not related to actually porting Qucs to Qt4. Cheers, Stefan. |
From: Gopala K. <kri...@gm...> - 2007-04-18 12:15:12
|
Hello guys, Stefan says: > Actually I don't like the idea. I don't see an advantage for now. It's > not related to "porting Qucs" and also not a conceptional change. With > the bitmaps as seperate files it is easier to change them even with the > application compiled and installed... Anyway, please don't feel > bothered. > If you really require the change you can leave it as is. > You are right. Actually I didn't apply ruso's patch directly instead modified Qucs::bitmapDirectory() to return qucs-resource prefix. To be frank ruso consulted me before this change and I said ok since he told me its very minor change( with somewhat big impact). Its easy to undo. I also know that its not exactly related to "porting Qucs" but it does have its advantages ;-) Please note that it was just experimental (i forgot to specify that) . I had to try qucs-resource system for myself. roucaries bastien said: > It will be also better to describe each component in the gui by an xml > > file, that will include the number of port, the name of the component, > > the path to an icon file (preferably in vector graphics format) and a > > regexp (or a printf like string) for creating the simulation file. > > If we could do this, qucs core and qucs will be fully decoupled, ie we > > do not need to recompile qucs-gui if we add a new components to > > qucs-core. But I suppose it is a mid term goal. > stefan replied: > This I also had it mind already. It would be something like the > description of library elements. There is already a Symbol, Ports and > Netlist description contained... Also it would be a step towards > loadable add-on modules for components which is (I agree) a mid term > goal. But also not related to actually porting Qucs to Qt4. Hey actually even I had this concept in mind. What I have in mind is to represent the whole component in xml file, i.e an xml file should have following info - * number of port and corresponding location centred around (0,0) * icon path * symbol described in terms of lines, arcs.. * netlist text * sidebar appearance info * some other helpful info and totally eliminate .cpp and .h files for all the components. I can do this after some progress in other aspects of port. Whats you opinion ? -- Cheers, Gopala Krishna A -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2007-04-18 12:59:09
|
Am Mi, 18.04.2007, 14:15, schrieb Gopala Krishna: > Hello guys, Hi Gopala, > roucaries bastien said: >> It will be also better to describe each component in the gui by an xml >> > file, that will include the number of port, the name of the component, >> > the path to an icon file (preferably in vector graphics format) and a >> > regexp (or a printf like string) for creating the simulation file. >> > If we could do this, qucs core and qucs will be fully decoupled, ie we >> > do not need to recompile qucs-gui if we add a new components to >> > qucs-core. But I suppose it is a mid term goal. >> > stefan replied: >> This I also had it mind already. It would be something like the >> description of library elements. There is already a Symbol, Ports and >> Netlist description contained... Also it would be a step towards >> loadable add-on modules for components which is (I agree) a mid term >> goal. But also not related to actually porting Qucs to Qt4. > > Hey actually even I had this concept in mind. What I have in mind is > to represent the whole component in xml file, i.e an xml file should > have following info - > * number of port and corresponding location centred around (0,0) > * icon path > * symbol described in terms of lines, arcs.. > * netlist text > * sidebar appearance info > * some other helpful info > > and totally eliminate .cpp and .h files for all the components. I can > do this after some progress in other aspects of port. > Whats you opinion ? I think for certain components this may be possible at a later point of time. It won't be possible for lot's of other components (e.g. components with various symbols depending on properties of the component, or for variable port components and other special-typed components as there are logical_* which have a netlist entry for digital verilog/vhdl as well as analog). Please concentrate for now on the actual port. Thanks in advance, Stefan. |
From: Gopala K. <kri...@gm...> - 2007-04-18 13:21:56
|
Hello Stefan, > I think for certain components this may be possible at a later point of > time. It won't be possible for lot's of other components (e.g. components > with various symbols depending on properties of the component, or > for variable port components and other special-typed components as there > are logical_* which have a netlist entry for digital verilog/vhdl as > well as analog). For some components we may implement the c++ code. But xml serves for lot of purposes. I have a solution for multi symbol components - check out multisymbolcomponent.h. Also verilog/vhdl code can be included in xml file. There are infinite possibilities ;) > Please concentrate for now on the actual port. Please understand that I am concentrating on port too (infact the only one with latest addition of 2). See, these changes affect the way code is written. If they are not discussed before then, it becomes difficult to re-port to new way. You may feel so with qt3 codebase in mind. But since the qt4 port is not a literal port, we can take advantage by applying the new changes now itself. Also note that, I clearly mentioned I would do that after some progress in the port. Please never come into conclusion that I am concentrating on something else :) -- Cheers, Gopala Krishna A |
From: roucaries b. <rou...@gm...> - 2007-04-18 13:07:26
|
On 4/18/07, Gopala Krishna <kri...@gm...> wrote: > Hello guys, > > Stefan says: > > Actually I don't like the idea. I don't see an advantage for now. It's > > not related to "porting Qucs" and also not a conceptional change. With > > the bitmaps as seperate files it is easier to change them even with the > > application compiled and installed... Anyway, please don't feel > > bothered. > > If you really require the change you can leave it as is. > > > > You are right. Actually I didn't apply ruso's patch directly instead > modified Qucs::bitmapDirectory() to return qucs-resource prefix. To be > frank ruso consulted me before this change and I said ok since he told > me its very minor change( with somewhat big impact). Its easy to undo. > I also know that its not exactly related to "porting Qucs" but it does > have its advantages ;-) > Please note that it was just experimental (i forgot to specify that) . > I had to try qucs-resource system for myself. > > roucaries bastien said: > > It will be also better to describe each component in the gui by an xml > > > file, that will include the number of port, the name of the component, > > > the path to an icon file (preferably in vector graphics format) and a > > > regexp (or a printf like string) for creating the simulation file. > > > If we could do this, qucs core and qucs will be fully decoupled, ie we > > > do not need to recompile qucs-gui if we add a new components to > > > qucs-core. But I suppose it is a mid term goal. > > > stefan replied: > > This I also had it mind already. It would be something like the > > description of library elements. There is already a Symbol, Ports and > > Netlist description contained... Also it would be a step towards > > loadable add-on modules for components which is (I agree) a mid term > > goal. But also not related to actually porting Qucs to Qt4. > > Hey actually even I had this concept in mind. What I have in mind is > to represent the whole component in xml file, i.e an xml file should > have following info - > * number of port and corresponding location centred around (0,0) No need of this kind of thing see below > * icon path > * symbol described in terms of lines, arcs.. Why using description wheras they exist svg. We could create a svg file for symbols and use id field for naming and automagically find port. Ie port have always an id like port%i where %i is an integer. > * netlist text > * sidebar appearance info > * some other helpful info > > and totally eliminate .cpp and .h files for all the components. I can > do this after some progress in other aspects of port. > Whats you opinion ? Regards bastien |
From: Gopala K. <kri...@gm...> - 2007-04-18 13:33:48
|
Hello, > No need of this kind of thing see below > > * icon path > > * symbol described in terms of lines, arcs.. > Why using description wheras they exist svg. We could create a svg > file for symbols and use id field for naming and automagically find > port. Ie port have always an id like port%i where %i is an integer. Unfortunately I hardly have experience with svg. Since we also want to store netlist and other data I feel an xml file suits better. If I misunderstood you or you have any other proposal please correct me. -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2007-04-18 14:14:26
|
Am Mi, 18.04.2007, 15:45, schrieb Gopala Krishna: > Hi, Hello! >> Actually I don't like the idea. I don't see an advantage for now. It's >> not related to "porting Qucs" and also not a conceptional change. With >> the bitmaps as seperate files it is easier to change them even with the >> application compiled and installed... Anyway, please don't feel >> bothered. >> If you really require the change you can leave it as is. > > Resource changes reverted :) Ok, thanks. > Will do some more progress today, hopefully I can do most of the port > soon. > If you are free now , can you come to efnet so that we can discuss > exactly where to focus and what changes to do ? I'll be home in 2/3 hours... Anyway. What I imagine are some components which I can place and wire as well as simulation components. These I want to be able to edit (component properties). That's the first step. Then I want to load/save this. Then I want to create netlist and start simulator. Then I want to display data in a diagram. I think if this route is focused on, then the rest may be straight forward. What do you think? Cheers, Stefan. |
From: Gopala K. <kri...@gm...> - 2007-04-18 14:24:15
|
Hello, > Anyway. What I imagine are some components which I can place and wire > as well as simulation components. These I want to be able to edit > (component properties). That's the first step. > > Then I want to load/save this. > > Then I want to create netlist and start simulator. > > Then I want to display data in a diagram. > > I think if this route is focused on, then the rest may be straight > forward. > > What do you think? I agree with you. What i thought was, suppose we implement components as svg/xml , that will result in huge changes. Also I havent ported some 30 components since I manually need to edit them (scripts cant be too intelligent ;) ) So that will save some work for me if we implement that now. Well I will do one thing. Finish of the other parts of port and then port the remaining components. -- Cheers, Gopala Krishna A |
From: Lisandro
<per...@gm...> - 2007-04-18 14:52:02
|
El Mi=E9rcoles 18 Abril 2007 05:10, roucaries bastien escribi=F3: > On 4/18/07, Stefan Jahn <st...@gr...> wrote: > > Am Di, 17.04.2007, 21:26, schrieb Gopala Krishna: > > > Hello guys, > > > > Hello Gopala, > > > > > For this week I implemented a filter, which filters components > > > based on name typed in line edit in sidebar. This really helps to > > > locate components at faster rate instead of navigating through all > > > types of sources. > > > Please do give me feedback about this feature! > > > > I will look at it. Thanks. > > > > > One good news. Ruso (or Martin) , friend of Lisandrop helped me > > > by implementing slots corresponding to zoom and also some few other > > > slots. > > > > Good to hear that. :-) > > > > > Oh yeah, theres one more big change. Hence forth we thought of using > > > Qt's resource system to store icons in binary format in platform > > > independent way. Ruso did that and I commited that too. You can have a > > > look at this link for more info > > > http://doc.trolltech.com/4.2/resources.html > > > > > > Please do give feedback. > > > > Actually I don't like the idea. I don't see an advantage for now. It's > > not related to "porting Qucs" and also not a conceptional change. With > > the bitmaps as seperate files it is easier to change them even with the > > application compiled and installed... Anyway, please don't feel bothere= d. > > If you really require the change you can leave it as is. > > Here I agree with Stephan. It will be better to keep the icons as files. Why? :-)=20 I do considere it as a part of porting qucs to qt4, it's part of adding the= =20 new features that qt4 offers. Else, it will run in Qt4 but the Qt3 way :-) My reasons: * If we continue with the separate icons: ** each time the application is loaded the hard drive has to seek for the specific file and load it into memory. Repeat that for _every_ icon. ** we have to care during the installation process (ok, when coding the= =20 installer, be it autotools based or nsi based) that the correct paths for _each_ OS is right, take care of file permissions, etc. * If we use resources: ** the application loads only one file, the binary, with the icons emmbeded. Only one hard drive access has to be done. The files would = be stored in a sequential array optimized by Qt's resources compiler. Mo= re than that, it is _possible_ that memory consumption will decrease due= to such compilation (no separate files in memory). ** we do not have to care about instaling the files with the correct permissions if possible, etc. Any thoughts would be much appreciated. Regards, Lisandro. =2D-=20 $ make war make: *** No rule to make target `war'. Stop. Try `love' instead David Gravereaux Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ |
From: roucaries b. <rou...@gm...> - 2007-04-18 15:00:55
|
On 4/18/07, Lisandro Dami=E1n Nicanor P=E9rez Meyer <per...@gm...> = wrote: > El Mi=E9rcoles 18 Abril 2007 05:10, roucaries bastien escribi=F3: > > On 4/18/07, Stefan Jahn <st...@gr...> wrote: > > > Am Di, 17.04.2007, 21:26, schrieb Gopala Krishna: > > > > Hello guys, > > > > > > Hello Gopala, > > > > > > > For this week I implemented a filter, which filters components > > > > based on name typed in line edit in sidebar. This really helps to > > > > locate components at faster rate instead of navigating through all > > > > types of sources. > > > > Please do give me feedback about this feature! > > > > > > I will look at it. Thanks. > > > > > > > One good news. Ruso (or Martin) , friend of Lisandrop helped= me > > > > by implementing slots corresponding to zoom and also some few other > > > > slots. > > > > > > Good to hear that. :-) > > > > > > > Oh yeah, theres one more big change. Hence forth we thought of usin= g > > > > Qt's resource system to store icons in binary format in platform > > > > independent way. Ruso did that and I commited that too. You can hav= e a > > > > look at this link for more info > > > > http://doc.trolltech.com/4.2/resources.html > > > > > > > > Please do give feedback. > > > > > > Actually I don't like the idea. I don't see an advantage for now. I= t's > > > not related to "porting Qucs" and also not a conceptional change. Wi= th > > > the bitmaps as seperate files it is easier to change them even with t= he > > > application compiled and installed... Anyway, please don't feel bothe= red. > > > If you really require the change you can leave it as is. > > > > Here I agree with Stephan. It will be better to keep the icons as files= . > > Why? :-) > > I do considere it as a part of porting qucs to qt4, it's part of adding t= he > new features that qt4 offers. Else, it will run in Qt4 but the Qt3 way :-= ) > > My reasons: > * If we continue with the separate icons: > ** each time the application is loaded the hard drive has to seek for = the > specific file and load it into memory. Repeat that for _every_ icon= . - Do you know readahead (even dark side OS do readahead) ? Moreover we could put all the svg files and model description in one single file (xml in xml) > ** we have to care during the installation process (ok, when coding th= e > installer, be it autotools based or nsi based) that the correct pat= hs > for _each_ OS is right, take care of file permissions, etc. - Not really a problem. Moreover with the file approach each user could use its own icons and model (we could begin to search in $HOME). Something that is not possible with ressource > * If we use resources: > ** the application loads only one file, the binary, with the icons > emmbeded. Only one hard drive access has to be done. The files woul= d be > stored in a sequential array optimized by Qt's resources compiler. = More > than that, it is _possible_ that memory consumption will decrease d= ue to > such compilation (no separate files in memory). - It a gui we do not care about memory usage > ** we do not have to care about instaling the files with the correct > permissions if possible, etc. > Any thoughts would be much appreciated. Thanks bastien > Regards, Lisandro. > > > -- > $ make war > make: *** No rule to make target `war'. Stop. Try `love' instead > David Gravereaux > > Lisandro Dami=E1n Nicanor P=E9rez Meyer > http://perezmeyer.com.ar/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Lisandro
<per...@gm...> - 2007-04-18 15:38:07
|
El Mi=E9rcoles 18 Abril 2007 12:00, escribi=F3: [snip] > > Why? :-) > > > > I do considere it as a part of porting qucs to qt4, it's part of adding > > the new features that qt4 offers. Else, it will run in Qt4 but the Qt3 > > way :-) > > > > My reasons: > > * If we continue with the separate icons: > > ** each time the application is loaded the hard drive has to seek for > > the specific file and load it into memory. Repeat that for _every_ icon. > > - Do you know readahead (even dark side OS do readahead) ?=20 Yes, I forgot this part. > Moreover we=20 > could put all the svg files and model description in one single file > (xml in xml) As I said in the IRC, while botter to do that when you already have it=20 implemented in a similar-working fashion? I guess pasting the log will be helpful to others to understand :-) <BastienN7> - for hard drive seeking we could put all the files in one big= =20 file thanks to xml <BastienN7> Moreover OS we do readahead <lisandrop> ok, and why will you take the time to do that if it's allready= =20 implemented in a convenient way? <BastienN7> And For qucs-core teams it will be easier to decouple qucs-gui = and=20 qucs-core <lisandrop> because, resources will end doing the same thing <BastienN7> For quick and dirty testing of new components <lisandrop> there's nothing in resources that will get in between qucs-core= =20 and qucs-gui <BastienN7> With file we need to only add a new file <BastienN7> But with ressource we need to do a new compile cycle <lisandrop> easy, add a 1-port, 2-port,... images for non-known components <lisandrop> after all, you are testing it <lisandrop> and, by the way, how do you associate the components with the=20 images? <lisandrop> moreover, you do not have to put the components in the resources Yes, it was in the line above that I realized that most of you are thinking= in=20 adding the component's files to the resources. Bastien explained to me: [12:09:43] <lisandrop> just the icons [12:09:58] <BastienN7> Yes but the goal is to create a component xml file OK, I do realize that, for components, it would be much easier to use xml, = but=20 not for the rest of the icons (think about the toolbars, for example). > > ** we have to care during the installation process (ok, when coding > > the installer, be it autotools based or nsi based) that the correct pat= hs > > for _each_ OS is right, take care of file permissions, etc. > > - Not really a problem. Moreover with the file approach each user > could use its own icons and model (we could begin to search in $HOME). > Something that is not possible with ressource Agree with the components side of the discussion. > > * If we use resources: > > ** the application loads only one file, the binary, with the icons > > emmbeded. Only one hard drive access has to be done. The files > > would be stored in a sequential array optimized by Qt's resources > > compiler. More than that, it is _possible_ that memory consumption will > > decrease due to such compilation (no separate files in memory). > > - It a gui we do not care about memory usage Put it in another perspective: the qucs-gui-qt4 team is porting and trying = to=20 use the new Qt4's features that fits in the design. We do care about the gu= i.=20 So, less memory consumption and/or more speed are important variables to us. Regards, Lisandro. =2D-=20 "So long, and thanks for all de fish!" The Hitchhickers guide to the Galaxy Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ |
From: Gopala K. <kri...@gm...> - 2007-04-18 15:16:09
|
Hello, On 4/18/07, roucaries bastien <rou...@gm...> wrote: > On 4/18/07, Lisandro Dami=E1n Nicanor P=E9rez Meyer <per...@gm...= > wrote: > > El Mi=E9rcoles 18 Abril 2007 05:10, roucaries bastien escribi=F3: > > > On 4/18/07, Stefan Jahn <st...@gr...> wrote: > > > > Am Di, 17.04.2007, 21:26, schrieb Gopala Krishna: > > > > > Hello guys, > > > > > > > > Hello Gopala, > > > > > > > > > For this week I implemented a filter, which filters componen= ts > > > > > based on name typed in line edit in sidebar. This really helps t= o > > > > > locate components at faster rate instead of navigating through al= l > > > > > types of sources. > > > > > Please do give me feedback about this feature! > > > > > > > > I will look at it. Thanks. > > > > > > > > > One good news. Ruso (or Martin) , friend of Lisandrop help= ed me > > > > > by implementing slots corresponding to zoom and also some few oth= er > > > > > slots. > > > > > > > > Good to hear that. :-) > > > > > > > > > Oh yeah, theres one more big change. Hence forth we thought of us= ing > > > > > Qt's resource system to store icons in binary format in platform > > > > > independent way. Ruso did that and I commited that too. You can h= ave a > > > > > look at this link for more info > > > > > http://doc.trolltech.com/4.2/resources.html > > > > > > > > > > Please do give feedback. > > > > > > > > Actually I don't like the idea. I don't see an advantage for now. = It's > > > > not related to "porting Qucs" and also not a conceptional change. = With > > > > the bitmaps as seperate files it is easier to change them even with= the > > > > application compiled and installed... Anyway, please don't feel bot= hered. > > > > If you really require the change you can leave it as is. > > > > > > Here I agree with Stephan. It will be better to keep the icons as fil= es. > > > > Why? :-) > > > > I do considere it as a part of porting qucs to qt4, it's part of adding= the > > new features that qt4 offers. Else, it will run in Qt4 but the Qt3 way = :-) > > > > My reasons: > > * If we continue with the separate icons: > > ** each time the application is loaded the hard drive has to seek fo= r the > > specific file and load it into memory. Repeat that for _every_ ic= on. > - Do you know readahead (even dark side OS do readahead) ? Moreover we > could put all the svg files and model description in one single file > (xml in xml) > > ** we have to care during the installation process (ok, when coding = the > > installer, be it autotools based or nsi based) that the correct p= aths > > for _each_ OS is right, take care of file permissions, etc. > - Not really a problem. Moreover with the file approach each user > could use its own icons and model (we could begin to search in $HOME). > Something that is not possible with ressource > > > * If we use resources: > > ** the application loads only one file, the binary, with the icons > > emmbeded. Only one hard drive access has to be done. The files wo= uld be > > stored in a sequential array optimized by Qt's resources compiler= . More > > than that, it is _possible_ that memory consumption will decrease= due to > > such compilation (no separate files in memory). > - It a gui we do not care about memory usage > > ** we do not have to care about instaling the files with the correct > > permissions if possible, etc. > > > > > Any thoughts would be much appreciated. > > Thanks bastien > > > Regards, Lisandro. > > > > > > -- > > $ make war > > make: *** No rule to make target `war'. Stop. Try `love' instead > > David Gravereaux > > > > Lisandro Dami=E1n Nicanor P=E9rez Meyer > > http://perezmeyer.com.ar/ > > > > -----------------------------------------------------------------------= -- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Qucs-devel mailing list > > Quc...@li... > > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > Every feature has its advantages as well as disadvantages. I dont mean to discourage anyone. What I want to convey is that users hardly tweak the icons. The SVG reason is valid one though. The resource system is very advantageous in qmake based projects. But for autotools based one, it doesn't make much difference although you can avoid installation step. >From myside anything is acceptable but since we are planning to try out SVG its better not to use qrc at the moment. If we drop out SVG , then we can think of resource system. Again, please my mail is not meant to discourage anyone. -- Cheers, Gopala Krishna A |
From: Svenn A. B. <sve...@go...> - 2007-04-18 19:05:59
|
Hi, I have not understood why qucs is relying on autotools at all. qmake should be able to handle most of the supported platforms by itself. --=20 Svenn On 4/18/07, Gopala Krishna <kri...@gm...> wrote: > Hello, > > On 4/18/07, roucaries bastien <rou...@gm...> wrote: > > On 4/18/07, Lisandro Dami=E1n Nicanor P=E9rez Meyer <perezmeyer@gmail.c= om> wrote: > > > El Mi=E9rcoles 18 Abril 2007 05:10, roucaries bastien escribi=F3: > > > > On 4/18/07, Stefan Jahn <st...@gr...> wrote: > > > > > Am Di, 17.04.2007, 21:26, schrieb Gopala Krishna: > > > > > > Hello guys, > > > > > > > > > > Hello Gopala, > > > > > > > > > > > For this week I implemented a filter, which filters compon= ents > > > > > > based on name typed in line edit in sidebar. This really helps= to > > > > > > locate components at faster rate instead of navigating through = all > > > > > > types of sources. > > > > > > Please do give me feedback about this feature! > > > > > > > > > > I will look at it. Thanks. > > > > > > > > > > > One good news. Ruso (or Martin) , friend of Lisandrop he= lped me > > > > > > by implementing slots corresponding to zoom and also some few o= ther > > > > > > slots. > > > > > > > > > > Good to hear that. :-) > > > > > > > > > > > Oh yeah, theres one more big change. Hence forth we thought of = using > > > > > > Qt's resource system to store icons in binary format in platfor= m > > > > > > independent way. Ruso did that and I commited that too. You can= have a > > > > > > look at this link for more info > > > > > > http://doc.trolltech.com/4.2/resources.html > > > > > > > > > > > > Please do give feedback. > > > > > > > > > > Actually I don't like the idea. I don't see an advantage for now= . It's > > > > > not related to "porting Qucs" and also not a conceptional change.= With > > > > > the bitmaps as seperate files it is easier to change them even wi= th the > > > > > application compiled and installed... Anyway, please don't feel b= othered. > > > > > If you really require the change you can leave it as is. > > > > > > > > Here I agree with Stephan. It will be better to keep the icons as f= iles. > > > > > > Why? :-) > > > > > > I do considere it as a part of porting qucs to qt4, it's part of addi= ng the > > > new features that qt4 offers. Else, it will run in Qt4 but the Qt3 wa= y :-) > > > > > > My reasons: > > > * If we continue with the separate icons: > > > ** each time the application is loaded the hard drive has to seek = for the > > > specific file and load it into memory. Repeat that for _every_ = icon. > > - Do you know readahead (even dark side OS do readahead) ? Moreover we > > could put all the svg files and model description in one single file > > (xml in xml) > > > ** we have to care during the installation process (ok, when codin= g the > > > installer, be it autotools based or nsi based) that the correct= paths > > > for _each_ OS is right, take care of file permissions, etc. > > - Not really a problem. Moreover with the file approach each user > > could use its own icons and model (we could begin to search in $HOME). > > Something that is not possible with ressource > > > > > * If we use resources: > > > ** the application loads only one file, the binary, with the icons > > > emmbeded. Only one hard drive access has to be done. The files = would be > > > stored in a sequential array optimized by Qt's resources compil= er. More > > > than that, it is _possible_ that memory consumption will decrea= se due to > > > such compilation (no separate files in memory). > > - It a gui we do not care about memory usage > > > ** we do not have to care about instaling the files with the corre= ct > > > permissions if possible, etc. > > > > > > > > > Any thoughts would be much appreciated. > > > > Thanks bastien > > > > > Regards, Lisandro. > > > > > > > > > -- > > > $ make war > > > make: *** No rule to make target `war'. Stop. Try `love' instead > > > David Gravereaux > > > > > > Lisandro Dami=E1n Nicanor P=E9rez Meyer > > > http://perezmeyer.com.ar/ > > > > > > ---------------------------------------------------------------------= ---- > > > This SF.net email is sponsored by DB2 Express > > > Download DB2 Express C - the FREE version of DB2 express and take > > > control of your XML. No limits. Just data. Click to get it now. > > > http://sourceforge.net/powerbar/db2/ > > > _______________________________________________ > > > Qucs-devel mailing list > > > Quc...@li... > > > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > > > > > -----------------------------------------------------------------------= -- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Qucs-devel mailing list > > Quc...@li... > > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > > Every feature has its advantages as well as disadvantages. I dont mean > to discourage anyone. What I want to convey is that users hardly tweak > the icons. The SVG reason is valid one though. > The resource system is very advantageous in qmake based projects. But > for autotools based one, it doesn't make much difference although you > can avoid installation step. > > >From myside anything is acceptable but since we are planning to try > out SVG its better not to use qrc at the moment. If we drop out SVG , > then we can think of resource system. > > Again, please my mail is not meant to discourage anyone. > > -- > Cheers, > Gopala Krishna A > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Oswald B. <os...@kd...> - 2007-04-18 16:36:49
|
On Wed, Apr 18, 2007 at 05:00:49PM +0200, roucaries bastien wrote: > On 4/18/07, Lisandro Damián Nicanor Pérez Meyer <per...@gm...> wrote: > > My reasons: > > * If we continue with the separate icons: > > ** each time the application is loaded the hard drive has to seek for the > > specific file and load it into memory. Repeat that for _every_ icon. > - Do you know readahead (even dark side OS do readahead) ? > and how exactly could that help with scattered files the os doesn't even know they will be needed the next half second? it should be noted that kde approved a SoC project to create an icon cache to solve exactly that problem. > Moreover we could put all the svg files and model description in one > single file (xml in xml) > now, that's *considerably* more elegant. ;) > - It a gui we do not care about memory usage > what exactly are you smoking? i want that stuff, too!! > > $ make war > > make: *** No rule to make target `war'. Stop. Try `love' instead > > hmm, that's a non-starter in the servlet field - war is a pretty common target, while love might be indeed hard to find. :))) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
From: roucaries b. <rou...@gm...> - 2007-04-18 16:46:39
|
On 4/18/07, Oswald Buddenhagen <os...@kd...> wrote: > On Wed, Apr 18, 2007 at 05:00:49PM +0200, roucaries bastien wrote: > > On 4/18/07, Lisandro Dami=E1n Nicanor P=E9rez Meyer <perezmeyer@gmail.c= om> wrote: > > > My reasons: > > > * If we continue with the separate icons: > > > ** each time the application is loaded the hard drive has to seek = for the > > > specific file and load it into memory. Repeat that for _every_ = icon. > > - Do you know readahead (even dark side OS do readahead) ? > > > and how exactly could that help with scattered files the os doesn't even > know they will be needed the next half second? > > it should be noted that kde approved a SoC project to create an icon > cache to solve exactly that problem. > > > Moreover we could put all the svg files and model description in one > > single file (xml in xml) > > > now, that's *considerably* more elegant. ;) It will even more elegant to create the global file at compile time or using something like qucs-buildcomponent-database pathtodatabase > outputfile.xml. We could therefore keep the maintenabilty of multiple files and keep high speed. A python script or a bash script will do the job. > > - It a gui we do not care about memory usage > > > what exactly are you smoking? i want that stuff, too!! :-) When you are doing EM simulation (that take hour or week) you do not care about gui. GUI is only a convinient way of visualization nothing more. |
From: Lisandro
<per...@gm...> - 2007-04-18 17:05:57
|
El Mi=E9rcoles 18 Abril 2007 13:46, roucaries bastien escribi=F3: [snip] > > > - It a gui we do not care about memory usage > > > > what exactly are you smoking? i want that stuff, too!! > > > :-) When you are doing EM simulation (that take hour or week) you do > > not care about gui. GUI is only a convinient way of visualization > nothing more. Wow, we see differents usages of qucs here! That's good! Well, it is important when the user is a student doing analogic calcs in a = PI=20 233 MHz to try to understand how things work in order to learn (and approve= a=20 subject :-) ) That added to being free software is why I am trying to help develop qucs (= I=20 hate when I see my partners using an ilegal copy of Orcad) Regards, Lisandro. =2D-=20 Primero te ignorar=E1n, luego se reir=E1n, luego te combatir=E1n, luego ganar=E1s. Mahatma Gandhi Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ |
From: Svenn A. B. <sve...@go...> - 2007-04-18 19:14:51
|
On 4/18/07, Lisandro Dami=E1n Nicanor P=E9rez Meyer <per...@gm...> = wrote: > El Mi=E9rcoles 18 Abril 2007 13:46, roucaries bastien escribi=F3: > [snip] > > > > - It a gui we do not care about memory usage > > > > > > what exactly are you smoking? i want that stuff, too!! > > > > > :-) When you are doing EM simulation (that take hour or week) you do > > > > not care about gui. GUI is only a convinient way of visualization > > nothing more. > > Wow, we see differents usages of qucs here! That's good! > Well, it is important when the user is a student doing analogic calcs in = a PI > 233 MHz to try to understand how things work in order to learn (and appro= ve a > subject :-) ) Yeah, and as a professional, I would like to see the monopoly of companies like Cadence come to an end. Their prices are way too high, and their business practice is like a monopolist. But as long as students are running the open source world, it is hard to find a piece of software that reaches beyond student work. Real IC design is not trivial, and there are too few programmers with real IC experience. > That added to being free software is why I am trying to help develop qucs= (I > hate when I see my partners using an ilegal copy of Orcad) Isn't orcad and qucs targeting two different audiences? Orcad was primarily a schematic capture for pcb last time I used it. (Mid '90s) Maybe that changed after cadence bought them. --=20 Svenn |
From: Lisandro
<per...@gm...> - 2007-04-18 21:34:30
|
El Mi=E9rcoles 18 Abril 2007 18:00, escribi=F3: > 2007/4/18, Svenn Are Bjerkem <sve...@go...>: > > Hi, > > I have not understood why qucs is relying on autotools at all. qmake > > should be able to handle most of the supported platforms by itself. > > AFAIK, because qucs-qt3 was developed using autotools. I would also > like (and I think I did propose it) to use qmake instead, ate least > for the gui. > > Regards, Lisandro. This should have gone to the list :-) =2D-=20 Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read. -- Groucho Marx Lisandro Dami=E1n Nicanor P=E9rez Meyer http://perezmeyer.com.ar/ |