You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
(4) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Michael M. <mic...@gm...> - 2007-01-11 15:15:38
|
Just checking in to see if there is any interest (within the existing community) in restarting work on Internet Explorer Validation and QA Toolbar? -- Michael W. Mistak "Patriotism is loving your country always and your government when it deserves it" -Mark Twain "If one would give me six lines written by the hand of the most honest man, I would find something in them to have him hanged." - Cardinal Richelieu |
From: Bjoern H. <der...@gm...> - 2004-04-28 23:13:10
|
* Kim Gräsman wrote: >I meant the header files and libraries - though maybe it's a bit tricky to >keep them synchronized with the main lines of development of these >libraries...? I just feel there should be a way of getting everything from >CVS, open the .vcproj, and build it. How about regular source code snapshots as a .zip including all necessary files? |
From: Bjoern H. <der...@gm...> - 2004-04-28 22:16:57
|
* Kim Gräsman wrote: >> You mean, the header files and libraries? Of their complete source >> trees? Wouldn't that be a bit odd? It's certainly doable though. > >I meant the header files and libraries - though maybe it's a bit tricky to >keep them synchronized with the main lines of development of these >libraries...? I just feel there should be a way of getting everything from >CVS, open the .vcproj, and build it. OTOH, it may be problematic if these >libraries are continually developed... Then we'd have to merge in new >versions every now and then. Of course, if we did that, we'd know everybody >was working with the same version of the libs, and it wouldn't matter who >built the project, as long as they had the latest stuff from *our* CVS tree. I would rather avoid the trouble, whether you have a .zip file providing the necessary header and library files should not matter much, it's already more than you get from typical open source projects with external dependencies. |
From: <kim...@la...> - 2004-04-27 20:10:34
|
> > I am fine with project files in CVS as long as someone > maintains them. > > Feel free to add them (I would suggest in > build\ieqacmd\ieqacmd.vcproj > > etc.) > > That's my plan - I'll go over them again, and make sure > they're coherent. Done! I added a commit comment to indicate where to get the dependencies until we've figured something out. Kim |
From: <kim...@la...> - 2004-04-27 19:33:57
|
Hi Bj=F6rn, > Unfortunately, yes. I took a few minutes and wrote up something like a > homepage, <http://ieqabar.sourceforge.net/> Nice!=20 > I am fine with project files in CVS as long as someone maintains them. > Feel free to add them (I would suggest in build\ieqacmd\ieqacmd.vcproj > etc.) That's my plan - I'll go over them again, and make sure they're = coherent. > > Any chance we can add genx, opensp and tidylib to the same CVS tree? > > That would make it sooo much easier to get going and build the = stuff. >=20 > You mean, the header files and libraries? Of their complete source > trees? Wouldn't that be a bit odd? It's certainly doable though. I meant the header files and libraries - though maybe it's a bit tricky = to keep them synchronized with the main lines of development of these libraries...? I just feel there should be a way of getting everything = from CVS, open the .vcproj, and build it. OTOH, it may be problematic if = these libraries are continually developed... Then we'd have to merge in new versions every now and then. Of course, if we did that, we'd know = everybody was working with the same version of the libs, and it wouldn't matter = who built the project, as long as they had the latest stuff from *our* CVS = tree. You know better than I how active the other projects are... And there = may be licensing issues; but these are all hosted at Sourceforge, right? > > Also, I found a couple of memory leaks when I looked through the > > IEDocument.cxx file - I don't have time to fix them right now, but > > I'll look into it later. >=20 > Oh, any insight here would be greatly appreciated. Sure, I'll put some effort into it when I've put the project structure together properly. Cheers, Kim |
From: Bjoern H. <der...@gm...> - 2004-04-26 20:33:29
|
* Kim Gräsman wrote: >Long time no see! Unfortunately, yes. I took a few minutes and wrote up something like a homepage, <http://ieqabar.sourceforge.net/>, there are some screenshots for what I currently got working, maybe these help to get an idea where this is going... >I just cooked up a buildable VS.NET project of the ieqacmd files - any >reason we shouldn't add a project file to CVS? I wanted to ask, since you >didn't do it yourself. I am fine with project files in CVS as long as someone maintains them. Feel free to add them (I would suggest in build\ieqacmd\ieqacmd.vcproj etc.) >Any chance we can add genx, opensp and tidylib to the same CVS tree? >That would make it sooo much easier to get going and build the stuff. You mean, the header files and libraries? Of their complete source trees? Wouldn't that be a bit odd? It's certainly doable though. >Also, I found a couple of memory leaks when I looked through the >IEDocument.cxx file - I don't have time to fix them right now, but >I'll look into it later. Oh, any insight here would be greatly appreciated. I probably took care that it consistently leaks memory then. The new, malloc(), and CoTaskMemAlloc() calls should all have their corresponding delete, free, CoTaskMemFree(), and the genx/tidy/osp wrappers should properly call the corresponding object destructors, other than that I carefully avoided freeing resources... As I've said, I've been unable to detect leaks using _Crt* etc. at that time though. >It seems to be working anyhow - I validated http://www.w3c.org/ and no >warnings showed up (as opposed to MSDN...) Ah! Cool! regards. |
From: <kim...@la...> - 2004-04-26 18:20:46
|
Bj=F6rn, Long time no see! I just cooked up a buildable VS.NET project of the ieqacmd files - any reason we shouldn't add a project file to CVS? I wanted to ask, since = you didn't do it yourself. This project relies on the following structure: genx opensp generic include src ieqacmd include library tidylib Any chance we can add genx, opensp and tidylib to the same CVS tree? That would make it sooo much easier to get going and build the stuff. Also, I found a couple of memory leaks when I looked through the IEDocument.cxx file - I don't have time to fix them right now, but I'll = look into it later. It seems to be working anyhow - I validated http://www.w3c.org/ and no warnings showed up (as opposed to MSDN...) Best wishes, Kim > -----Original Message----- > From: ieq...@li...=20 > [mailto:ieq...@li...] On Behalf=20 > Of Bjoern Hoehrmann > Sent: den 25 mars 2004 15:53 > To: ieq...@li... > Subject: [qabar-dev] CVS and build instructions >=20 > Hi, >=20 > I've checked what I've got so far into our CVS repository. In order > to check it out, use something like >=20 > % cvs -d:ext:na...@cv...:/cvsroot/ieqabar co ieqabar >=20 > where "name" is your sf.net login name. In order to built it, you need > Genx, OpenSP and a modified version of HTML Tidy. The necessary files > can (currently) be found at >=20 > http://ieqabar.sf.net/temp/ieqabar-dep.zip >=20 > This archive contains headers and .lib/.exp/.dll files. In order to > build the sample ieqacmd program you would need to include from the > archive >=20 > ...\genx > ...\opensp\include > ...\opensp\generic > ...\tidylib >=20 > and from the CVS sources=20 >=20 > ...\src\include >=20 > and in order to link it, you need to link the corresponding libs, i.e. > for release builds >=20 > genx\genx-r.lib > tidylib\tidylib-r.lib > opensp\osp151.lib >=20 > and for debug builds >=20 > genx\genx-d.lib > tidylib\tidylib-d.lib > opensp\osp15d.lib >=20 > (these are all -MT builds, btw) In order to run the sample > application, you need to >=20 > % set SP_CHARSET_FIXED=3D0 > % set SP_ENCODING=3DUTF-8 > % set SP_BCTF=3DUTF-8 >=20 > and copy the dtd directory from CVS checkout to c:\dtd, the programm > currently looks for c:\dtd\dtd\sgml.soc and=20 > c:\dtd\dtd\xml.soc. Then you > can run >=20 > % ieqacmd http://msdn.microsoft.com/ >=20 > (or, if I get around to change the hardcoded file paths, probably) >=20 > % ieqacmd c:\dtd\dtd\ http://msdn.microsoft.com/ >=20 > for the same effect. >=20 > HTH. >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > https://lists.sourceforge.net/lists/listinfo/ieqabar-devel >=20 |
From: Bjoern H. <der...@gm...> - 2004-03-25 14:53:01
|
Hi, I've checked what I've got so far into our CVS repository. In order to check it out, use something like % cvs -d:ext:na...@cv...:/cvsroot/ieqabar co ieqabar where "name" is your sf.net login name. In order to built it, you need Genx, OpenSP and a modified version of HTML Tidy. The necessary files can (currently) be found at http://ieqabar.sf.net/temp/ieqabar-dep.zip This archive contains headers and .lib/.exp/.dll files. In order to build the sample ieqacmd program you would need to include from the archive ...\genx ...\opensp\include ...\opensp\generic ...\tidylib and from the CVS sources ...\src\include and in order to link it, you need to link the corresponding libs, i.e. for release builds genx\genx-r.lib tidylib\tidylib-r.lib opensp\osp151.lib and for debug builds genx\genx-d.lib tidylib\tidylib-d.lib opensp\osp15d.lib (these are all -MT builds, btw) In order to run the sample application, you need to % set SP_CHARSET_FIXED=0 % set SP_ENCODING=UTF-8 % set SP_BCTF=UTF-8 and copy the dtd directory from CVS checkout to c:\dtd, the programm currently looks for c:\dtd\dtd\sgml.soc and c:\dtd\dtd\xml.soc. Then you can run % ieqacmd http://msdn.microsoft.com/ (or, if I get around to change the hardcoded file paths, probably) % ieqacmd c:\dtd\dtd\ http://msdn.microsoft.com/ for the same effect. HTH. |
From: Bjoern H. <der...@gm...> - 2004-03-19 01:31:40
|
* Kim Gräsman wrote: >> I would like to import it into our CVS repository, I think of having >> >> /src/ -- the source files mentioned above (except ieg.cpp) >> /dtd/ -- local copies of the HTML/XHTML dtds for OpenSP >> /xslt/ -- XSLT documents to turn the XML into HTML/... >> >> I would like to have both, a toolbar that integrates into IE >> and a command line driver. > >Looks good. How about the /src/ dir - what's the sub-structure? I'm >imagining something like; > > /src/ > /src/common > /src/common/include -- shared helper code, etc. > /src/common/lib -- if necessary. > /src/yadayada -- common validation code, tidy, etc. > /src/yadayada/foo? -- further sub-division? > /src/ieqabar -- toolbar driver > /src/ieqa -- command-line driver Well, I guess I'd be fine with anything as long as I know where to put what, but I am not sure whether there is real benefit in such a fine grained structure, just stuffing everything into src/ would work for me, but how about src/include/ -- headers for the library part src/library/ -- library code src/ieqabar/ -- toolbar code src/ieqacmd/ -- command line driver code without any current subdirectory? I think there won't be much additional files and this seems to be a simple and clean solution. We can change things later if that makes sense. Did you have a look at my source code? >Nope, that's a sure way of scaring off users ;). I've used NullSoft's NSIS >[1] before - it's not developer-friendly, but for simplistic setups like >this, it's pretty good. I'll be happy to take ownership of the installer. Great! >Ha! Good luck with that! ;) On a serious note, I've just resigned from my >job, and am looking at joining another position within a couple of months, >so I'll likely be pretty busy for a while. Hopefully I'll be able to help >out with the toolbar, but I can't take any driving role, due to lack of >time. > >Anyway, the sooner we can get things into CVS, the easier it is to get an >idea of what we're doing and what needs to be done. OTOH, maybe I'm the only >one who isn't sure what we're doing ;) Well, I guess I won't have much time to work on this either in the next few months. Hence it becomes even more important to publish something soon. What needs to be done is actually quite simple, have a look at http://www.bjoernsworld.de/temp/opensp-tb-qa-homepage-inval.png I took <http://www.codeproject.com/wtl/toolband.asp>, threw superfluous GUI widgets away, wait for Invoke() with a DocumentComplete event and run OpenSP; the error handler adds error messages to the combo box and that's it. What I want is something in that direction with an interface that does not suck. A minimal interface would offer a [V] (alidate this page) button that opens a new window with the output of SaveSnapshot(). Having code in CVS that provides just such a button plus an installer would in fact justify an alpha release to get people contribute to the project. To get this basic toolbar code is probably only a matter of copy&paste... |
From: <kim...@la...> - 2004-03-18 14:19:59
|
Hi Bj=F6rn, The XML/XSL idea sounds nice. It makes for reports in other formats as = well if necessary. > I would like to import it into our CVS repository, I think of having >=20 > /src/ -- the source files mentioned above (except ieg.cpp) > /dtd/ -- local copies of the HTML/XHTML dtds for OpenSP > /xslt/ -- XSLT documents to turn the XML into HTML/... >=20 > I would like to have both, a toolbar that integrates into IE=20 > and a command line driver. Looks good. How about the /src/ dir - what's the sub-structure? I'm imagining something like; /src/ /src/common /src/common/include -- shared helper code, etc. /src/common/lib -- if necessary. /src/yadayada -- common validation code, tidy, etc. /src/yadayada/foo? -- further sub-division? /src/ieqabar -- toolbar driver /src/ieqa -- command-line driver Does that make sense? The /common dir always comes in handy, even if it = may turn out empty to begin with... :) yadayada/ and foo/ are placeholders for more appealing names. > Once we reached that point, how to continue? What we need is=20 > code for the toolbar and some install system would be nice,=20 > too. I'd be fine with a .zip, a text/plain config file I can=20 > edit and a readme.txt that tells me what to regserv32 and a=20 > .reg file to manipulate the registry, but I guess there=20 > aren't many users who share that view... :-) > I never wrote an installer for Win32, so, ... ideas? Nope, that's a sure way of scaring off users ;). I've used NullSoft's = NSIS [1] before - it's not developer-friendly, but for simplistic setups like this, it's pretty good. I'll be happy to take ownership of the = installer. > And how do I get you to=20 > work on the GUI/COM part? ;-) Ha! Good luck with that! ;) On a serious note, I've just resigned from = my job, and am looking at joining another position within a couple of = months, so I'll likely be pretty busy for a while. Hopefully I'll be able to = help out with the toolbar, but I can't take any driving role, due to lack of time. Anyway, the sooner we can get things into CVS, the easier it is to get = an idea of what we're doing and what needs to be done. OTOH, maybe I'm the = only one who isn't sure what we're doing ;) See ya, Kim [1] http://nsis.sourceforge.net |
From: Bjoern H. <der...@gm...> - 2004-03-18 06:50:08
|
Hi, I think the most flexible approach to generate human-readable and machine-processable reports is to use a simple XML language and to provide default XSLT templates to turn such a report into (X)HTML which could then be rendered in Internet Explorer, see [1] for a sample of what I am thinking of (some things changed since though). Internet Explorer 6 ships with MSXML3 and Internet Explorer 5 can be upgraded to use MSXML3. IE5 also ships with an implementation of a working draft for XSLT, so I think this approach is compatible with out compatibility goals. We would just generate such a report with <?xml-stylesheet href = 'file:///...' ... ?> at the beginning and then navigate an Internet Explorer to the document, IE would automatically transform the document, so this is even simple implementation-wise. I wrote the interface code for HTML Tidy, OpenSP and Genx (a simple toolkit to generate XML) [4] and wrote a command line application (based on [4] which explains SaveSnapshot()) that takes a URI and generates a report such as [1]. I've used the command line application to validate all W3C Member homepages, the (XML) results are available at [2], hence I can claim this works quite good so far. Source code is available from [5]. I would like you to look at the source code and tell me whether this looks reasonable to you. There is Doctypes.cxx -- Document type declarations Helper.cxx -- Some helper routines Message.cxx -- Classes for a Message and lists thereof IEDocument.cxx -- Wrapper for get_document()'s IDispatch OpenSP.cxx -- Wrapper for OpenSP HTMLTidy.cxx -- Wrapper for HTML Tidy XmlWriter.cxx -- Wrapper for Genx plus accompanying header files, IEQABase.hxx -- #includes for ATL, etc. and ieg.cpp -- the command line application where basically only the misnamed SaveSnapshot() is of interest (little, however, there are a number of issues with this code). VC++ does not emit warnings caused by my code using -Wp64 and -W4 and I've been unable to detect memory leaks, and outside of ieg.cpp I have tried to catch most errors. There are still some issues when for example the source document or messages from OpenSP/Tidy contain 0x00, but nothing really critical, as far as I can tell. I appreciate any comment on the code. I think in auto-validation mode what SaveSnapshot() currently does should happen in a way that does not block Invoke(). Even though running HTML Tidy and/or OpenSP is typically pretty fast, it would be better if it does not hinder browsing experience, hence Invoke() should return without waiting for the result. I do not know how to do that. I guess you would spawn a separate thread for it, but I am not sure how this would affect the design so far. Maybe it does not... If it does not and you think the code looks reasonably well, I would like to import it into our CVS repository, I think of having /src/ -- the source files mentioned above (except ieg.cpp) /dtd/ -- local copies of the HTML/XHTML dtds for OpenSP /xslt/ -- XSLT documents to turn the XML into HTML/... I would like to have both, a toolbar that integrates into IE and a command line driver. ieg.cpp is not quite what I want... There should probably some base thing with the SaveSnapshot() code currently in ieg.cpp. Ideas where to put/how to organize that? Does the CVS structure look reasonable to you? You will not be able to build the code, it depends on a custom extension to HTML Tidy which I would need to redesign a bit and integrate into Tidy... I will provide what is necessary to build it once it is in CVS. Once we reached that point, how to continue? What we need is code for the toolbar and some install system would be nice, too. I'd be fine with a .zip, a text/plain config file I can edit and a readme.txt that tells me what to regserv32 and a .reg file to manipulate the registry, but I guess there aren't many users who share that view... :-) I never wrote an installer for Win32, so, ... ideas? And how do I get you to work on the GUI/COM part? ;-) [1] http://tinyurl.com/yw399 [2] http://tinyurl.com/3dyu7 [3] http://tinyurl.com/2u9uf [4] http://tinyurl.com/2kgfy [5] http://tinyurl.com/2gh7c |