You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <ben...@id...> - 2004-05-22 12:26:30
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Marco M. <ma...@ac...> - 2003-10-01 01:09:28
|
On Wed, Sep 24, 2003 at 09:40:15AM +0100, Jorge Gustavo Rocha wrote: > Bom dia, > > Descobri que a malta do java n?o gosta de Makefiles e, por isso, usam > uma coisa chamada 'Ant' para compilar os programas. Como acho que n?s > dev?amos disponibilizar, juntamente com as sources, uma Makefile, n?o > acho m? ideia cri?rmos uma script Ant para gerar o Viewer. > Boas, ant é um aborto. Usa ficheiros XML para descrever o processo... tirando o formato de ficheiros do Excel, não me consigo lembrar de nada pior para a tarefa. A melhor forma de fazer o 'makefile' é criar um ficheiro java que importa todos os ficheiros que estão em packages e que contem uma classe que cria um objecto das classes que não pertencem a um package. (Tens de ler 3 (três) vezes para perceberes o que acabo de escrever.) Na minha árvore actual, seria uma coisa do género: Ficheiro Makefile.java: import org.neniu.gvs.Bezier; import org.neniu.gvs.Circle; import org.neniu.gvs.Colors; import org.neniu.gvs.Drawable; import org.neniu.gvs.Ellipse; import org.neniu.gvs.GCircle; import org.neniu.gvs.GEllipse; import org.neniu.gvs.GImage; import org.neniu.gvs.GLine; import org.neniu.gvs.GPath; import org.neniu.gvs.GPolygon; import org.neniu.gvs.GPolyline; import org.neniu.gvs.GRect; import org.neniu.gvs.GText; import org.neniu.gvs.Image; import org.neniu.gvs.Line; import org.neniu.gvs.Path; import org.neniu.gvs.Polygon; import org.neniu.gvs.Polyline; import org.neniu.gvs.Rect; import org.neniu.gvs.Shape; import org.neniu.gvs.Text; class Makefile { BoundingBox a; Debug b; GSVG c; MyGroup d; OsvCanvas e; OsvSVG f; Parser g; ToolBar h; Viewer i; } Para recompilar tudo, basta fazer 'javac Makefile.java'. Alguém que implemente isto, que eu não posso... tenho que ir alí. Marco |
From: Jorge G. R. <jg...@di...> - 2003-09-24 08:40:50
|
Bom dia, Descobri que a malta do java não gosta de Makefiles e, por isso, usam uma coisa chamada 'Ant' para compilar os programas. Como acho que nós devíamos disponibilizar, juntamente com as sources, uma Makefile, não acho má ideia criármos uma script Ant para gerar o Viewer. Eu nunca usei o Ant, mas vou ver... em http://ant.apache.org. Algum de vocês já usou o ant? Jorge -- jorge gustavo rocha departamento de informática universidade do minho 4710-057 braga portugal N 41º33'44,5" W 8º23'40,5" tel +351 253604470 fax +351 253604471 cel +351 919690914 |
From: <ma...@ac...> - 2003-08-19 18:29:49
|
I have just synchronized the CVS's gdsj tree my internal tree. Most of the changes in it were done by Miguel Angelo. Most of the work now in CVS is experimental. There are many things that are not working, but the overall program structure is much better. Marco Monteiro ma...@ac... |
From: Nuno F. <na...@al...> - 2003-08-13 02:47:31
|
Hi ppl, Since our last meeting I have been testing and working with the=20 CSIRO SVG Toolkit, and I would like to share with you some ideas and conclusions of my tasks. So, I think it won't be useful for our purposes because there are too =20 many classes using Java2. While parsing almost all created SVG elements=20 have a draw method (elements "know" how to draw themselfs,=20 which I believe to be a good idea) that implements Java2 (Graphics2D and = other Java2 methods). That compromises the direct use of this toolkit = and=20 makes the conversion to Java (jdk1.1.8) a very hard task. I have done some tests with the CSIRO Viewer and it needs some=20 considerable resources to run. In an AthlonXP 2100+ pc, it takes about 4sec to open the file Avr1.svg and uses about 30Mb of memory. Therefore, I suggest not to use CSIRO SVG Toolkit but use it's=20 architecture and organization in a brand new application. That's my opinion and I'm waiting your's ideas. Nuno Andr=E9 Faria Laborat=F3rio SIG Departamento de Inform=E1tica Universidade do Minho 4710 - 057 Braga Portugal Telefone: +351 253 604 457 http://www.nasf.cjb.net= |
From: Nuno F. <na...@al...> - 2003-07-01 15:38:43
|
Hi Marco and Miguel, Here in SIG Lab we all apreciate your good work and interest for the project. Now i will write some considerations in portuguese. Desde já axo que a ideia de dividir o projecto em três partes é boa, na medida em que me parece aceitável separar o desenvolvimento da interface gráfica do desenvolvimento do parser. A 3ª parte é a junção das outras duas para funcionar em PDAs (penso ser esta a vossa ideia). No entanto, e dado que voçês estão a pensar usar Java2 no vosso desenvolvimento, quero alertar para o facto de que o objectivo deste projecto é mesmo as plataformas móveis, porque já existem vários visualizadores de SVG "livres" (por exemplo, o Batik da Apache) que suportam toda a especificação SVG e que usam as mais recente tecnologias Java mas não funcionam nas máquinas virtuais de Java para as plataformas móveis. Daí, o nosso interesse maior é que o projecto avance para o funcionamento em PDAs e é aí que nós precisámos mais da ajuda da comunidade científica mundial :) pois o nosso conhecimento nessa área ainda é limitado. Entendo perfeitamente quais a vossas intenções visto que o mais importante serão os algoritmos usados na programação, mas queria que não se desviassem muito do objectivo principal do projecto e que também contribuissem (sempre que possível) para esse objectivo, que é por a funcionar decentemente o visualizador em PDAs.. Continuação de bom trabalho. P.S.: Temos de marcar uma reunião para discutir ideias e soluções. Pode ser pra semana? (Esta pergunta é pra todos os envolvidos no projecto... :)) Nuno Faria ----- Original Message ----- From: <ma...@ac...> To: <ope...@li...> Sent: Saturday, June 28, 2003 2:07 AM Subject: [Opensvgviewer-general] Cleaning done. > After 96 man-hours, the cleaning is done. > Results: line count down to 3333 from 13030. Speed increased, memory footprint decreased. > > The development should now proceed in two fronts: reimplementation of the GUI and reimplementation of the svg parsing. Miguel will work mostly in the GUI, and Marco in the parsing. The other developers are, of course, free to choose what they want to do. > > The reimplementation of the GUI will proceed in the current CVS tree (Viewer/). The reimplementation of the svg parsing and DOM construction will be started in a new tree (gvsj/). Both these trees will be coded for, and using, the most recent technologies. That means Java 2, including the use of Java 2D and the most recent Java libraries. The objective is to do a complete implementation of the Mobile SVG's Basic profile. These trees should be merged sometime in a not distant future. > > Of course we still want to run the viewer in pockets, which means the Java 1.1 platform. With that objective, a third tree (gvsj-fly/) will be created. The purpose of that tree is to change the code in the other trees to make it work in Java 1.1. Of course that doesn't mean we will have to change all the code from the other trees, but, instead, to create the necessary libraries to substitute the ones not present in the Java 1.1. It would be nice if someone steeped forward to manage this tree. Anyone interested? This task will not be very difficult: we, all, will be careful when choosing the code to use in the other trees to make this task of porting an easy one. > > For now, the development process should _not_ be closed. One option would be to have a maintainer for each tree that would accept patches from the other coders; no one else would have write access to the CVS tree. This is a good way to maintain a big project or one that is already in stable state. As we want to develop as fast as possible, and we sure are not big yet, the 'open access' is preferable. > > And that's it for the plans. We are really hopping for replies to this message. > > P.S.:Due to the change in the GUI, the attached file is needed to run the application. It must be copied to the directory '../icons' relative to the location of the code. That is, the directory containing the code should be sibling with the directory 'icons'. > > P.S.2: The numbers are a little misleading, and a little provocative to the original developers. Many lines came out, but we trashed some functionality in the process. To maintain the same functionality as the original code we would need, for sure, at least... lets say... 4444 lines of code. So, they are not as bad as they seem, looking just to the numbers. > > P.S.3: (Quem escreveu o P.S.2 foi o Miguel. Eu n?o tenho culpa. --Marco) > > Miguel Castro > Marco Monteiro > |
From: <ma...@ac...> - 2003-06-28 11:49:10
|
The gvsj/ tree in the CVS has been created. I'll start rebuilding the parser there. I am still designing things, but I've looked at Apache Batik and the structure of its code seems nice. I am looking for inspiration there... Marco |
From: <ma...@ac...> - 2003-06-28 01:07:26
|
After 96 man-hours, the cleaning is done. Results: line count down to 3333 from 13030. Speed increased, memory footprint decreased. The development should now proceed in two fronts: reimplementation of the GUI and reimplementation of the svg parsing. Miguel will work mostly in the GUI, and Marco in the parsing. The other developers are, of course, free to choose what they want to do. The reimplementation of the GUI will proceed in the current CVS tree (Viewer/). The reimplementation of the svg parsing and DOM construction will be started in a new tree (gvsj/). Both these trees will be coded for, and using, the most recent technologies. That means Java 2, including the use of Java 2D and the most recent Java libraries. The objective is to do a complete implementation of the Mobile SVG's Basic profile. These trees should be merged sometime in a not distant future. Of course we still want to run the viewer in pockets, which means the Java 1.1 platform. With that objective, a third tree (gvsj-fly/) will be created. The purpose of that tree is to change the code in the other trees to make it work in Java 1.1. Of course that doesn't mean we will have to change all the code from the other trees, but, instead, to create the necessary libraries to substitute the ones not present in the Java 1.1. It would be nice if someone steeped forward to manage this tree. Anyone interested? This task will not be very difficult: we, all, will be careful when choosing the code to use in the other trees to make this task of porting an easy one. For now, the development process should _not_ be closed. One option would be to have a maintainer for each tree that would accept patches from the other coders; no one else would have write access to the CVS tree. This is a good way to maintain a big project or one that is already in stable state. As we want to develop as fast as possible, and we sure are not big yet, the 'open access' is preferable. And that's it for the plans. We are really hopping for replies to this message. P.S.:Due to the change in the GUI, the attached file is needed to run the application. It must be copied to the directory '../icons' relative to the location of the code. That is, the directory containing the code should be sibling with the directory 'icons'. P.S.2: The numbers are a little misleading, and a little provocative to the original developers. Many lines came out, but we trashed some functionality in the process. To maintain the same functionality as the original code we would need, for sure, at least... lets say... 4444 lines of code. So, they are not as bad as they seem, looking just to the numbers. P.S.3: (Quem escreveu o P.S.2 foi o Miguel. Eu n?o tenho culpa. --Marco) Miguel Castro Marco Monteiro |
From: <ma...@ac...> - 2003-06-26 05:04:42
|
We have started refactoring the code of Open SVG Viewer. Until now the code has come down from approximately 13000 lines to 10000. In some .svg files, the used memory has decreased by 50%. The performance as gone up sharply. Although we haven't done extensive tests, the program is now much more responsive. Test it. The objective for this phase is only to clean the code. Parsing is going to be moved to a Parser class, the user interface is going to be cleaned up and improved (specially the red). The code shows up the changes. (Paulo: The graphics code is very different, now. Fetch the changes from the CVS and look at it. --Miguel ?ngelo) As the code base is changing rapidly, and will be, for the next week or so, we ask you, the other developers, to 'cvs update' frequently, if you want to make changes. (Maybe you don't want to, for some time, until this settles down.) Marco Miguel ?ngelo |
From: <ro...@ne...> - 2003-06-26 05:02:42
|
We have started refactoring the code of Open SVG Viewer. Until now the code has come down from approximately 13000 lines to 10000. In some .svg files, the used memory has decreased by 50%. The performance as gone up sharply. Although we haven't done extensive tests, the program is now much more responsive. Test it. The objective for this phase is only to clean the code. Parsing is going to be moved to a Parser class, the user interface is going to be cleaned up and improved (specially the red). The code shows up the changes. (Paulo: The graphics code is very different, now. Fetch the changes from the CVS and look at it. --Miguel ?ngelo) As the code base is changing rapidly, and will be, for the next week or so, we ask you, the other developers, to 'cvs update' frequently, if you want to make changes. (Maybe you don't want to, for some time, until this settles down.) Marco Miguel ?ngelo |
From: Nuno F. <na...@al...> - 2003-06-12 16:59:55
|
Ora esta =E9 a primeira mensagem da mailing list do projecto Open SVG = Viewer... =C9 em portugu=EAs porque para j=E1, s=F3 h=E1 povo portugu=EAs inscrito = na referida lista. Um abra=E7o e bom trabalho para todos... Nuno Andr=E9 Faria Laborat=F3rio SIG - Dep. Inform=E1tica Universidade do Minho 4710-059 Braga, Portugal Telf: +351253604457 |