themis-dev — Development list.

Re: [Themis-dev] Some changes

[Raymond C. R. <z3r...@bb...>]

Fredrik Modéen wrote:
> When It comes to bookmarks/history I think we should use NetPositive's
>
> I know we talked about not use NetOptimist (from now NetOpt) code but when
> I checked there code I found some gui part's that I couldn't resist using.
>
> I think that we should use gui part from NetOpt and later when we want to
> rewrite the gui we can remove them. (I can make big remarks around them :)
> )
>
> Any way here are some copy/modify/enhanced code from NetOpt
>
> Now working are
> - Fullscreen (not using boolean NetOpt did we are using SetMarked/IsMarked
> in menu) - Show bookmarks (from NetOpt) will soon remove and use
> Themis/bookmarks - List bookmarks (this one are a big copy from NetOpt) to
> see if it works start NetPositive and save bookmarks
>
> Not working fully but will be easy to fix when you can brows with Themis -
> Drag/Drop a NetPositive bookmark and get the URL
> - Forward, Backward, Home these have now a menu option and arrows should
> work.
>
> Will work on next
> - Get a print window pop up don't know what else it should send. (Not from
> NetOpt) - Save bookmark (Not from NetOpt)
>
> The only thing left from NetOpt that can perhaps be used are Proxy
> settings  (don't know if it can)
>
> One thing I would like to do are follow BeBook and Haiku way of coding.
> Changing win.cpp to ThemisWin, app.cpp to ThemisApp and so on. Also
> changing some Methods (don't remember the c++/c name for the same) to
> start with uppercase letter.
>
> all of this are only in the framwork directory and commondef.h
>   
I'm going to be taking a look at your changes in a few minutes, after I 
finish installing BeOS Max in Virtual PC again... It seems that my old 
BeOS Max VPC installation has disappeared... possibly due to my wife... 
possibly due to some drive cleaning that I did a few weeks ago. The 
latter is unlikely since I know I've run BeOS since then... My work was 
lost but yours won't be... :-)

Raymond

Re: [Themis-dev] Some changes

[Michael W. <em...@m-...>]

Fredrik Modéen schrieb:
>> Fredrik Modéen schrieb:
>>>>> When It comes to bookmarks/history I think we should use NetPositive's
>>>>>
>>>>> I know we talked about not use NetOptimist (from now NetOpt) code but
>>>>> when
>>>>> I checked there code I found some gui part's that I couldn't resist
>>>>> using.
>>>>>
>>>>> I think that we should use gui part from NetOpt and later when we want
>>>>> to
>>>>> rewrite the gui we can remove them. (I can make big remarks around
>>>>> them
>>>>> :)
>>>>> )
>>>> Pending a response from the devs of Themis, I'd suspect that would be a
>>>> good way to go....  Just make sure you do this on all the pieces you
>>>> pull
>>>> in from NetOptimist.  Then, later Mark or Raymond can note what they
>>>> want
>>>> done.  You mentioned rewriting the code later..., did you have a better
>>>> design in mind that meant you might want to write the UI code from
>>>> scratch
>>>> according to that design?
>>> No  most clean up but Raymond talked about rewriting the gui :)
>> Why not taking any NetOptimist code as inspiration and implementing our
>> own? This way you don't scew the code with comments and code which might
>> be adopted to the existing ui framework and be later removed or
>> refactored anyway. Sounds like work done twice. Nobody hinders you/us to
> It would be work done twice :) and I have no problem with both :)

I was just arguing for not replicating work. But hey, I don't mind at 
all helping out with the adopted code if I once get a usable development 
system ;)

>> take inspiration from other code. And btw, it doesn't hurt if the
>> Bookmarks implementation takes a little longer as there is nothing to
>> show your rendered bookmarks right now.
> Right now nothing happens but years ago I think one was able to surf the net?
> Are this anything we can do to show anything? like the html text?

http://themis.m-phasis.de/shots/Themis_20040314_1.png ;) So still a long 
way to go.

Michael

>> When it comes to storing bookmarks, a file system hierarchy would do,
>> but at some point one might wan't arrange entries. So a flat filesystem
>> won't do. I guess that is why Mozilla & Co is going for some crazy
>> netscape bookmark html. Filesystem plus display-position attribute,
>> favicon as attrib or icon anyone?
> About file bookmarks as netposetive does, makes them search able from the
> OS taking advantage of BFS. If wee need more information in a file then we
> can add those.
> 
>> Greets,
>> Michael
>>
>>>> I don't know if this would be appropriate or not, but maybe add a TODO
>>>> file to the main Themis directory and make a note in there that there
>>>> is
>>>> code with the weird comments around it that need to be cleaned up or
>>>> dealt
>>>> with at some point (so it isn't forgotten about).  Or if you think this
>>>> is
>>>> redundant or a bad idea, then don't bother.
>>> To me the code from NetOpt are not a bad thing it's more what Raymond
>>> says
>>> and accepts in to svn :)
>>>
>>> I have looked at UZI but having problem compiling it. Will take that in
>>> the UZI project and some other questions like images are handled and so
>>> on.
>>>
>>>
>>>> Kevin
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>> _______________________________________________
>>>> Themis-dev mailing list
>>>> The...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/themis-dev
>>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Themis-dev mailing list
>> The...@li...
>> https://lists.sourceforge.net/lists/listinfo/themis-dev
>>
> 
> 

Re: [Themis-dev] Some changes

[Fredrik <fr...@mo...>]

> Fredrik Modéen schrieb:
>>>> When It comes to bookmarks/history I think we should use NetPositive's
>>>>
>>>> I know we talked about not use NetOptimist (from now NetOpt) code but
>>>> when
>>>> I checked there code I found some gui part's that I couldn't resist
>>>> using.
>>>>
>>>> I think that we should use gui part from NetOpt and later when we want
>>>> to
>>>> rewrite the gui we can remove them. (I can make big remarks around
>>>> them
>>>> :)
>>>> )
>>> Pending a response from the devs of Themis, I'd suspect that would be a
>>> good way to go....  Just make sure you do this on all the pieces you
>>> pull
>>> in from NetOptimist.  Then, later Mark or Raymond can note what they
>>> want
>>> done.  You mentioned rewriting the code later..., did you have a better
>>> design in mind that meant you might want to write the UI code from
>>> scratch
>>> according to that design?
>> No  most clean up but Raymond talked about rewriting the gui :)
>
> Why not taking any NetOptimist code as inspiration and implementing our
> own? This way you don't scew the code with comments and code which might
> be adopted to the existing ui framework and be later removed or
> refactored anyway. Sounds like work done twice. Nobody hinders you/us to
It would be work done twice :) and I have no problem with both :)

> take inspiration from other code. And btw, it doesn't hurt if the
> Bookmarks implementation takes a little longer as there is nothing to
> show your rendered bookmarks right now.
Right now nothing happens but years ago I think one was able to surf the net?
Are this anything we can do to show anything? like the html text?

> When it comes to storing bookmarks, a file system hierarchy would do,
> but at some point one might wan't arrange entries. So a flat filesystem
> won't do. I guess that is why Mozilla & Co is going for some crazy
> netscape bookmark html. Filesystem plus display-position attribute,
> favicon as attrib or icon anyone?
About file bookmarks as netposetive does, makes them search able from the
OS taking advantage of BFS. If wee need more information in a file then we
can add those.

>
> Greets,
> Michael
>
>>
>>> I don't know if this would be appropriate or not, but maybe add a TODO
>>> file to the main Themis directory and make a note in there that there
>>> is
>>> code with the weird comments around it that need to be cleaned up or
>>> dealt
>>> with at some point (so it isn't forgotten about).  Or if you think this
>>> is
>>> redundant or a bad idea, then don't bother.
>> To me the code from NetOpt are not a bad thing it's more what Raymond
>> says
>> and accepts in to svn :)
>>
>> I have looked at UZI but having problem compiling it. Will take that in
>> the UZI project and some other questions like images are handled and so
>> on.
>>
>>
>>> Kevin
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Themis-dev mailing list
>>> The...@li...
>>> https://lists.sourceforge.net/lists/listinfo/themis-dev
>>>
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Themis-dev mailing list
> The...@li...
> https://lists.sourceforge.net/lists/listinfo/themis-dev
>


-- 
MVH
Fredrik Modéen

Re: [Themis-dev] Some changes

[Michael W. <em...@m-...>]

Fredrik Modéen schrieb:
>>> When It comes to bookmarks/history I think we should use NetPositive's
>>>
>>> I know we talked about not use NetOptimist (from now NetOpt) code but
>>> when
>>> I checked there code I found some gui part's that I couldn't resist
>>> using.
>>>
>>> I think that we should use gui part from NetOpt and later when we want
>>> to
>>> rewrite the gui we can remove them. (I can make big remarks around them
>>> :)
>>> )
>> Pending a response from the devs of Themis, I'd suspect that would be a
>> good way to go....  Just make sure you do this on all the pieces you pull
>> in from NetOptimist.  Then, later Mark or Raymond can note what they want
>> done.  You mentioned rewriting the code later..., did you have a better
>> design in mind that meant you might want to write the UI code from scratch
>> according to that design?
> No  most clean up but Raymond talked about rewriting the gui :)

Why not taking any NetOptimist code as inspiration and implementing our 
own? This way you don't scew the code with comments and code which might 
be adopted to the existing ui framework and be later removed or 
refactored anyway. Sounds like work done twice. Nobody hinders you/us to 
take inspiration from other code. And btw, it doesn't hurt if the 
Bookmarks implementation takes a little longer as there is nothing to 
show your rendered bookmarks right now.
When it comes to storing bookmarks, a file system hierarchy would do, 
but at some point one might wan't arrange entries. So a flat filesystem 
won't do. I guess that is why Mozilla & Co is going for some crazy 
netscape bookmark html. Filesystem plus display-position attribute, 
favicon as attrib or icon anyone?

Greets,
Michael

> 
>> I don't know if this would be appropriate or not, but maybe add a TODO
>> file to the main Themis directory and make a note in there that there is
>> code with the weird comments around it that need to be cleaned up or dealt
>> with at some point (so it isn't forgotten about).  Or if you think this is
>> redundant or a bad idea, then don't bother.
> To me the code from NetOpt are not a bad thing it's more what Raymond says
> and accepts in to svn :)
> 
> I have looked at UZI but having problem compiling it. Will take that in
> the UZI project and some other questions like images are handled and so
> on.
> 
> 
>> Kevin
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Themis-dev mailing list
>> The...@li...
>> https://lists.sourceforge.net/lists/listinfo/themis-dev
>>
> 
> 

Re: [Themis-dev] Some changes

[Fredrik <fr...@mo...>]

>> When It comes to bookmarks/history I think we should use NetPositive's
>>
>> I know we talked about not use NetOptimist (from now NetOpt) code but
>> when
>> I checked there code I found some gui part's that I couldn't resist
>> using.
>>
>> I think that we should use gui part from NetOpt and later when we want
>> to
>> rewrite the gui we can remove them. (I can make big remarks around them
>> :)
>> )
> Pending a response from the devs of Themis, I'd suspect that would be a
> good way to go....  Just make sure you do this on all the pieces you pull
> in from NetOptimist.  Then, later Mark or Raymond can note what they want
> done.  You mentioned rewriting the code later..., did you have a better
> design in mind that meant you might want to write the UI code from scratch
> according to that design?
No  most clean up but Raymond talked about rewriting the gui :)


>
> I don't know if this would be appropriate or not, but maybe add a TODO
> file to the main Themis directory and make a note in there that there is
> code with the weird comments around it that need to be cleaned up or dealt
> with at some point (so it isn't forgotten about).  Or if you think this is
> redundant or a bad idea, then don't bother.
To me the code from NetOpt are not a bad thing it's more what Raymond says
and accepts in to svn :)

I have looked at UZI but having problem compiling it. Will take that in
the UZI project and some other questions like images are handled and so
on.


>
> Kevin
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Themis-dev mailing list
> The...@li...
> https://lists.sourceforge.net/lists/listinfo/themis-dev
>


-- 
MVH
Fredrik Modéen

Re: [Themis-dev] Some changes

[<Ar...@co...>]

> When It comes to bookmarks/history I think we should use NetPositive's
> 
> I know we talked about not use NetOptimist (from now NetOpt) code but when
> I checked there code I found some gui part's that I couldn't resist using.
> 
> I think that we should use gui part from NetOpt and later when we want to
> rewrite the gui we can remove them. (I can make big remarks around them :)
> )
Pending a response from the devs of Themis, I'd suspect that would be a good way to go....  Just make sure you do this on all the pieces you pull in from NetOptimist.  Then, later Mark or Raymond can note what they want done.  You mentioned rewriting the code later..., did you have a better design in mind that meant you might want to write the UI code from scratch according to that design?

I don't know if this would be appropriate or not, but maybe add a TODO file to the main Themis directory and make a note in there that there is code with the weird comments around it that need to be cleaned up or dealt with at some point (so it isn't forgotten about).  Or if you think this is redundant or a bad idea, then don't bother.

Kevin

[Themis-dev] Another code base

[Cyril R. <sta...@la...>]

Hi all,

  As Kevin told you earlier, I'm the main dev of another project called UZI.
I won't dig to much in infinite details about UZI, I'll try to describe
what I've done, my choices, and my future commitments.

Starting from Jan 07, I had an idea about a new kind of "office"
software. I started documenting on it, the functionalities, the
requirements, and so on.
After some time (I could explain what UZI is in private email, as it's
not Themis theme), I came to the conclusion that I needed a HTML renderer.

So I started to dig the internet about every renderer source code I
could find.
Obviously, I came to the very common one:
  - WebKit
  - Gecko

I've also resurrected links to the outsiders:
  - Themis
  - CHTMLViewer
  - Tcl/Tk HTML
  - Links
  - All those based on GLib

I've looked at the source, and I've made the following conclusions:
  - WebKit, cross-platform, dependent on Quartz or for the KHTML engine
Qt. C++, easy to understand, quite clean, maintained. Not vector-based
rendering
  - Gecko, cross-platform, dependent on too many librairies, huge. C++,
but using extention like XPCom
  - Themis, dependent on BeOS API, quite clean, not supported anymore.
C++, easy to understand.
  - CHTMLViewer, dependent on MFC, could be changed easily to base Win32
code, but specific to Win32 anyway. C++ code, but messy.
  - Tcl/Tk HTML, cross-platform, but dependent on Tcl/Tk I don't know about
  - others...

I wanted UZI to be cross platform, so I only had 3 choices (actually, 4
if including Themis with rewriting)
I excluded WebKit and Gecko due to their license on the dependencies for
the former, and their dependencies for the latter.
I decided not to learn another programming language, so I excluded
Tcl/Tk browser too (which is CSS 2 compliant, and pass the Acid2 test BTW)

So I finally started to look more closely into Themis by march 07.
I checked out the code. The boost dependency was very unexpected (as
it's not compiling everywhere, and slow any compilation by a factor of
at least 2)
Other dependencies were cryptlib, and libz. The javascript engine looked
like those of Mozilla.
I then dug into the modules folder; and started examining the code down
there.
The HTML parser used a lot of heap allocation (new ...), without obvious
object life cycle (where does the object goes, is it shared, and so
on...). Sure the dev relied on boost shared_ptr for their deallocation.
The parser also defined it's internal constant as char *, so it will be
broken with unicode content down there. I've checked the fetching code,
and it didn't convert to UTF-8, so I thought it was WIP.
The parser was cleanly structured between every kind of elements as a
class hierarchy.
However, the class hierarchy didn't looked that obvious to me.

I would have expected an HTMLParser to be a SGMLParser (as HTML is a
part of SGML).
In place of this, HTMLParser is dependent on BeOS code (why ?), deals
with OS specific task and message handling (why ?)
And in fact it doesn't parse anything.

The DOM tree is correct (in fact it's very clean implementation) of DOM
interfaces.
The renderer was inexistant (no rendering at all, in fact, it even
lacked the CSS box model's algorithm to map DOM nodes to boxes, and
reflow them).

As I didn't took time to understand the structure of the code, creating
a renderer from Themis project would have required studying this in
details, and rewriting a lot of BeOS specific code (even probably
rewriting the hierarchy).

So finally, I decided to roll my own.
I priviledged compliant and memory clean code over speed.
I started to implement DOM v2.1 interfaces in UZI.
Then an charset aware SGML parser (even through only UTF8 and latin1 is
supported for now)
Then I added an HTML parser to produce a DOM tree
I then added an CSS box model mapper (including CSS types parsing, and
structures), and table rendering
I finally implemented a renderer for all the CSS boxes spit from the
mapper.
I've added a CacheEngine with fast lookup too.

My design included allocators from the beginning (meaning there is no
"new" in the code except in the allocators, and every object is returned
to the allocator when required). This means that I'll be able to reuse
returned objects instead of calling the heap again (a page like
news.google.fr can take up to12MB of memory just for storing the picture
and text).
I also added test vectors from the beginning (I'm amazed to see that
they are still some many projects around that doesn't even test their
code correctness), so I'm sure the DOM implementation works 100% as
expected. The HTML parser works 100% as expected on VALID documents with
supported charset.
The testing the CSS mapping isn't concluant yet (and testing them
automatically is very difficult), so there is no test vector for it,
and, as obvious as it may seems, most of the issue I had (and still
have) come from that part exactly.

I wanted the design to be as platform dependent as possible.
As such, from the HTML parser up to the boxes to render, there is no
platform specific code. There is no dependency (not even on STL, as
cross platform STL code doesn't work) at all except C library.

I've simplified the renderer code to a single 14 methods interface, so
implementing a renderer only requires to implement 14 methods (for
measuring text, images and replaced content...)
The HTML parser take a stream as input, and it currently accept UTF8
streams, but adding charset is foreseen (requires implementing a 28
methods interface).

Having done this, I needed to check all that code in real world scenario.
I've choosen Juce ( http://www.rawmaterialsoftware.com/juce ) as the
cross platform engine because it natively support vector graphics (this
is needed for UZI), it's really, really clean C++.
I've then implemented the renderer in a Juce component (the total
renderer code is 2k lines, including own Juce code for rendering)
I've implemented a HTTP client using Juce primitives, a Thread pool for
fetching jobs, a DOM viewer, an error console, and finally a almost
fully functionnal browser.

Ouf,  here we are.
I needed a browser to test the renderer on real world code.
I started testing sites around, and got very pleasant and unpleasant
surprises.
The hardest part is probably creating a DOM tree like the author
intended, but correcting the errors the author made.
There is a DTD for validating documents, but most (if not all) website
just don't care about this, and almost no website validates the DTD.
So I had to handle so many errors, I not even sure I'm correct by now.

The current state is:
  - The browser actually renders web pages, like any non CSS browser and
allow to browse (well... sortof as form aren't POSTed yet)
  - I still need to include the CSS parsing code to CSS properties
  - I still need to correct some rendering error on the CSS mapper
  - I still need to find a way to map CSS rules to DOM node very very fast.
  - I still have to choose a Javascript engine, and bind it to the DOM
interface (my current choice would probably be See).
  - I still have to write tests for all the above.

I'm amazed to see Themis starting to work again. I don't follow that
much Haiku, but I do think it's good to have choice.
I've met Kevin on SeeDev mailing list, and he told me about your great news.

I'm not going to tell you "trash themis, use UZI's renderer, you'll have
results in 2 weeks".
I'm proud of my code and I suppose you are proud of yours.

Anyway, I'm telling you about my experiences, so you can avoid falling
in the same traps.
I'm copying a discussion we had with Kevin:

Kevin wrote:
>Unlike most open source projects you will find for other Operating 
Systems, Haiku projects can be quite different.
>The design of the BeOS (and now Haiku) focused on performance and 
providing a great API.
>As I understand it, designing a native BeOS and Haiku app almost 
forces you to develop applications in a multi-threaded manner (though
you can get around this).
>So, although you can port applications from another OS to Haiku, you 
will not get the benefits of developing a native app unless you take the
time to make things more multi-threaded as you move to Haiku.
>So, in the case of Themis, and Haiku applications, it is almost a bad 
idea to try for cross-platform.
>The goals are to develop high performance apps, based on a cleaner 
API, and taking advantage of Haiku's features.
>So, often this means developing a native Haiku app first.
>
>As for Themis, the design concepts for the project seems rather 
interesting:
>The core of Themis has a multi-threaded approach using messaging. 
>As one person described it, each component broadcasts a message that 
gets picked up by the appropriate component and gets used.
>For example, as he described it, a user types in an address and the 
address bar broadcasts a message about the address typed in...
>the appropriate component picks that up (whether that be ftp or http 
handling or whatever).
>The http handler would get the data and broadcast the message that it 
has the data.
>Then the appropriate component (say the parser to DOM) picks that up 
and so on....
>I would think going back to any other less threaded solution would be 
a step backwards for Themis.
>If anything from UZI was integrated, it would have to incorporate this 
multi-threaded approach using messaging (which I suspect is quite
possible).
>It would also need to take advantage of Haiku's APIs and widgets, as 
opposed to using cross-platform ones, where possible (not sure how
difficult this is).

I answered:
>I've used this programming scheme before (well, Win32 message 
programming I mean).
>However I've dropped the idea of message based task management.
>If you think about this, the application is only always doing the same 
task in the same order (HTML fetching -> HTML parsing -> DOM CSS mapping
-> CSS box rendering) everytime.
>This means that you pay the message queue cost between every subtask 
while you really don't need to (no one else is using this message anyway).
>Sure it looks like your application is more modular, but in reality 
it's not, because all modules still depends on each other (structure
declaration for one when passing objects in messages), and it adds
useless the OS messaging queue dependency.
>
>In UZI application part, I'm using a thread pool.
>Each thread can execute jobs (like fetching documents from server).
>However, from the parsing to the mapping it's a single job.
>
>I'm more concerned about memory handling than making the parser run in 
a separate thread than the renderer.
>UZI memory allocation all goes to a specific interface (BaseAllocator) 
that can decide to reuse objects and so on.
>There is more performance to gain from a correct memory allocation 
than from multithreading something that is inherently linear and
sequential.

Concerning the license through, we have discussed a lot with Kevin.
Initially this is what I want to ensure:
1) UZI is open-source (it'll never become closed source, à la Sourceforge)
2) Anyone is free to use it in open-source project, provided (s)he
doesn't change the license and send back any change they make to us.
3) There is no restriction to the other license in the project you use
UZI in (it's not viral)
4) UZI can be used in commercial application from some organization,
provided the organization release the source code of UZI to their
customers, and send back the changes they've made to UZI to us
5) If used in a closed source product, then some organization need to
buy a license. The license money will be shared between UZI contributors
proportionnally to their contribution as a correct retribution for their
hard work
6) UZI can't be relicensed differently unless all contributors agree to
do so commonly.

I haven't found exactly this license terms anywhere. Initially, I've put
UZI in dual licensing, GPL (for the restrictive part it includes), and
commercial license (like Trolltech or Juce). I don't like the current
terms, as it's very restrictive, doesn't allow external contributors
(unless they want to work for free, and have their name on top of a
file, but I don't believe this happens). If any of you have better idea
for the license, please answer to me, I'll talk with you directly.

UZI is currently my own work, 100% personal, so I can decide to license
it the way I want (for now). Later in time, it might not be the case.
Please dig around in UZI source code (
http://tools.assembla.com/uzi/browser/trunk/include and
http://tools.assembla.com/uzi/browser/trunk/src ) if you want to select
stuff you could be interested in.

Ok, that's it.
I'll look further to your answer.

Cheers,
Cyril

[Themis-dev] Some changes

[Fredrik <fr...@mo...>]

When It comes to bookmarks/history I think we should use NetPositive's

I know we talked about not use NetOptimist (from now NetOpt) code but when
I checked there code I found some gui part's that I couldn't resist using.

I think that we should use gui part from NetOpt and later when we want to
rewrite the gui we can remove them. (I can make big remarks around them :)
)

Any way here are some copy/modify/enhanced code from NetOpt

Now working are
- Fullscreen (not using boolean NetOpt did we are using SetMarked/IsMarked
in menu) - Show bookmarks (from NetOpt) will soon remove and use
Themis/bookmarks - List bookmarks (this one are a big copy from NetOpt) to
see if it works start NetPositive and save bookmarks

Not working fully but will be easy to fix when you can brows with Themis -
Drag/Drop a NetPositive bookmark and get the URL
- Forward, Backward, Home these have now a menu option and arrows should
work.

Will work on next
- Get a print window pop up don't know what else it should send. (Not from
NetOpt) - Save bookmark (Not from NetOpt)

The only thing left from NetOpt that can perhaps be used are Proxy
settings  (don't know if it can)

One thing I would like to do are follow BeBook and Haiku way of coding.
Changing win.cpp to ThemisWin, app.cpp to ThemisApp and so on. Also
changing some Methods (don't remember the c++/c name for the same) to
start with uppercase letter.

all of this are only in the framwork directory and commondef.h
-- 
MVH
Fredrik Modéen

Re: [Themis-dev] CSS

[<Ar...@co...>]

> (We already know this grammar is LL(1).  In fact, CSS2.1 syntax is a
> regular language, unless I missed something.  The parser I've written so
> far for Synura is a DFA-which is why I'm throwing it out to upgrade to
> CSS3.)
Why do they have LALR on there for CSS2.1?  Is that portion of the spec an actual official spec or is it just an example to help out developers and you should base the grammar on what it actually written elsewhere?

> The grammar that I'm studying, and hoping to write a parser for, is #3.
> In practice everybody uses a grammar and object model somewhere between
> #2 and #3, but I'm hoping to get closer to #3 than most people.
> 
> The tasks required to complete an analysis are:
> 1. Write a CFG for #3, preferably in a form that can be read by
> automated tools.
> 2. See if the grammar is LL(1), LALR(1), or whatever, switching between
> left & right recursion and stuff as necessary.  (And yes, the CSS spec
> does mention these for the stated grammars, but it appears to be
> non-normative and the stated grammars have all the above shortcomings).
> 
> I'd like to tackle task #1 by myself at first, but you're of course
> welcome to try your hand at it too.  As far the second task, I could
> really benefit from some software that will automagically figure this
> stuff out for me.  SLK will do it for 'strong' LL(k), but I'd like a
> more general tool in addition.  ANTLR might do it for LL(k), but I can't
> get it to run.  If we can't find tools to do it, I'm in the process of
> writing some quick-and-dirty scripts that might be able to figure it
> out.**
Is this software that will need to become a part of the project or just something you need to get started?

Re: [Themis-dev] CSS

[<Ar...@co...>]

What are the pros and cons to a handwritten parser?

Can it potentially be more standards compliant (since it's not limited)?

Would it be harder or easier to make faster and/or multithreaded?

Does a handwritten parser tend to get overly complicated after a while as you attempt to factor in every possibility (which would mean something too buggy and complicated to handle in the end)?

A handwritten parser will be harder for newcomers to get into (though this can be helped by extensive documentation), am I right?

Others?


Kevin

Re: [Themis-dev] CSS

[Maxwell C. <ma...@um...>]

Yep, that is (most) of the basic information on the grammar.  Lost count
of how many times I've read those pages :-).

You seem to have gotten understandably a little lost on what exactly the
CSS grammar is.  It's really not a straightforward question.  There's
really 3 different grammars we're discussing here.

1. The underlying CSS grammar.  This describes a few very basic CSS
structures.  It is pretty much only used for error handling, and will be
a small part of the real parser as kind of an underlying layer.  You
can't actually get any useful information from parsing CSS this way.

This is the part you're referring to that ostensibly never changes
between different versions of CSS (in real life it does).

2. The stated grammar for each version.  The CSS spec for 2.1 and 3 both
contain a grammar in pseudo-EBNF.  With this you can parse well enough
to get information to construct most of a CSSOM tree if you follow their
recommendations on the CSSOM (more on this in my real message).  Most of
the parsers I've really dug into roughly follow this, as does the parser
I wrote for UMM.  However, this still isn't a complete enough
description of the grammar to get all of the information that Themis
needs.  It contains only a general grammar for individual property
values, which isn't enough if we intend to actually use this CSS to
display a document.

Usually what is done is that a parser is written for this grammar that
is officially called the CSS parser.  Unfortunately you then have to
graft somewhere in your program code that checks that the parsed
expression for a property value is actually valid for that property and
extracts the information in some useful form, which ends up doing most
of the work of a parser, and badly.

(We already know this grammar is LL(1).  In fact, CSS2.1 syntax is a
regular language, unless I missed something.  The parser I've written so
far for Synura is a DFA-which is why I'm throwing it out to upgrade to
CSS3.)

3. The complete grammar.  The language described by this grammar should
be exactly equal to the language of stylesheets which correctly follow
*every* part of the spec (or as close as you can get while keeping the
language context-free).  It'll contain a rule like:

color_value: color_keyword |
             HASH |
             'rgb(' NUMBER COMMA NUMBER COMMA NUMBER ')'


The distinction between #2 and #3 is really important for the kind of
objects your parser spits out.  If your parser doesn't go beyond #2, for
the color value 'rgb(255, 255, 255)', it'll spit out a tree of objects
like:

Expression
  Term
    Function
      Expression
        Number
        Comma
        Number
        Comma
        Number

(see libcroco* for a library that outputs stuff like this.  Synura was
originally intended to be a layer on top of libcroco that actually made
it usable)

If a parser/CSSOM package recognizes grammar #3 it can spit out
something like

class Color
{
  int red, green, blue;
};

for the same input, which is clearly far more useful.

The grammar that I'm studying, and hoping to write a parser for, is #3.
In practice everybody uses a grammar and object model somewhere between
#2 and #3, but I'm hoping to get closer to #3 than most people.

The tasks required to complete an analysis are:
1. Write a CFG for #3, preferably in a form that can be read by
automated tools.
2. See if the grammar is LL(1), LALR(1), or whatever, switching between
left & right recursion and stuff as necessary.  (And yes, the CSS spec
does mention these for the stated grammars, but it appears to be
non-normative and the stated grammars have all the above shortcomings). 

I'd like to tackle task #1 by myself at first, but you're of course
welcome to try your hand at it too.  As far the second task, I could
really benefit from some software that will automagically figure this
stuff out for me.  SLK will do it for 'strong' LL(k), but I'd like a
more general tool in addition.  ANTLR might do it for LL(k), but I can't
get it to run.  If we can't find tools to do it, I'm in the process of
writing some quick-and-dirty scripts that might be able to figure it
out.**

Again, once I'm done with this I can write a the listserve with a
complete write-up on all our options for getting a modern CSS parser.
I'll have 3 components:

1. What needs to be done to update the current CSS code in Themis to
work with a more modern version of CSS and really form a solid
foundation for future work.

Themis has the most advanced parser I've seen in a long while, but is
unfortunately completely handwritten.  After I've finished my research
some people more involved in the project than me should have a
discussion on whether it is worth the effort to maintain and update a
handwritten parser.

2. Our options for other CSS libraries and code Themis can take (haven't
looked at UZI but most of the stuff out there-outside of the big stuff
like Firefox and Prince-is pretty dismal).

3. What I will write if I decide to really let loose and create the
perfect CSS parser from scratch, maybe using a few pieces of code from
Themis and Synura's old parser.

* To be fair to libcroco, it handled the 'color' property just fine - it
was other properties and some other related shortcomings that made me
come to find that library limiting.

** The omission of flex/bison here is completely intentional - I spent a
few months going down that road.  Of course these tools can
theoretically parse CSS grammar, but in practice it becomes unspeakable
ugly due to the aforementioned quirks of CSS syntax.  The prevalence of
hand-written parsers suggests most people agree with me.

On Sat, 2007-09-15 at 02:23 +0000, Ar...@co... wrote:
> > I'm currently doing a more in-depth analysis of the CSS grammar
> > (currently trying to determine if the CSS3 grammar is LL(1)), so I can
> > better judge the available parsers.  There is a number of really odd
> Not sure how much this helps:
> 
> CSS 2.1 Revision 1 Parsing rules:
> http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#syntax
> All futures versions of CSS will conform to these parsing rules (including CSS 3 -- so says the spec at least :) )
> This page has some additional notes about the grammar:
> http://www.w3.org/TR/2007/CR-CSS21-20070719/grammar.html
> It is in LALR(1) but suggests not to use it in the real world, since it doesn't conform perfectly to the parsing standards.
> 
> For CSS3 selectors, the specs has an LL(1) sample here:
> http://www.w3.org/TR/css3-selectors/#w3cselgrammar
> Again it states: "but note that most UA's should not use it directly, since it doesn't express the parsing conventions"
> 
> Also, here's something interesting....  An older working draft of CSS 2 has a sample using LL1:
> http://www.w3.org/TR/2002/WD-CSS21-20020802/grammar.html
> 
> 
> From what I can make out, it needs to follow the parsing conventions for CSS and that part will never change on any version of CSS.  However, beyond that I don't really know what's going on.  Does the spec require the browser to use LALR(1) for CSS 2.1 or is that merely there as an example?
> 
> If you could help explain a few things to me, maybe I could ask around for you.
> 
> Thanks,
> Kevin
>  -------------- Original message ----------------------
> From: Maxwell Collins <ma...@um...>
> > Yes, I've been following the mailing list.
> > 
> > I'm currently doing a more in-depth analysis of the CSS grammar
> > (currently trying to determine if the CSS3 grammar is LL(1)), so I can
> > better judge the available parsers.  There is a number of really odd
> > properties of the CSS grammar, and one of the most important properties
> > of a CSS parser is how it handles these.  I'm going to completely
> > analyze all of the oddities of the CSS 2.1 grammar (which I'm familiar
> > with), then try to see if I can anticipate any similar issues that may
> > have arisen with some of the new CSS3 stuff.
> > 
> > Once I've completed that, I'll send my thoughts on all of the available
> > CSS Parsers/CSSOM packages (including some beyond the three you listed).
> > 
> > On Fri, 2007-09-14 at 06:32 +0000, Ar...@co... wrote:
> > > Hey,
> > > Are you still following the mailing list?
> > > I posted something about a person working on a project called UZI....  Have 
> > you looked at any of the stuff he has to see if it might be something worth 
> > considering for Themis?
> > > 
> > > Anyways, what's your thoughts on CSS (if you've gotten a chance to look)?  
> > Does the current CSS look like it's a good start, does it look like the 
> > foundation is bad and that it would just be better to start with a new CSS 
> > parser (like yours).  I know you were interested in the particular area of CSS, 
> > but the reason I'm contacting you is to see how UZI mixes into things.  In 
> > comparing the 3: Themis' CSS, your CSS, or UZI's CSS, which appears to have the 
> > more solid foundation (regardless of whether it's even close to feature 
> > complete)... and which is closer to feature complete?
> > > Of course, what involvement UZI might have in the Themis project is uncertain 
> > at this point, but I didn't want their to be a conflict between what you were 
> > interested in and that project (since that project also include CSS stuff).
> > > 
> > > Kevin
> > 
> > 
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Themis-dev mailing list
> > The...@li...
> > https://lists.sourceforge.net/lists/listinfo/themis-dev
> 

Re: [Themis-dev] CSS

[<Ar...@co...>]

> I'm currently doing a more in-depth analysis of the CSS grammar
> (currently trying to determine if the CSS3 grammar is LL(1)), so I can
> better judge the available parsers.  There is a number of really odd
Not sure how much this helps:

CSS 2.1 Revision 1 Parsing rules:
http://www.w3.org/TR/2007/CR-CSS21-20070719/syndata.html#syntax
All futures versions of CSS will conform to these parsing rules (including CSS 3 -- so says the spec at least :) )
This page has some additional notes about the grammar:
http://www.w3.org/TR/2007/CR-CSS21-20070719/grammar.html
It is in LALR(1) but suggests not to use it in the real world, since it doesn't conform perfectly to the parsing standards.

For CSS3 selectors, the specs has an LL(1) sample here:
http://www.w3.org/TR/css3-selectors/#w3cselgrammar
Again it states: "but note that most UA's should not use it directly, since it doesn't express the parsing conventions"

Also, here's something interesting....  An older working draft of CSS 2 has a sample using LL1:
http://www.w3.org/TR/2002/WD-CSS21-20020802/grammar.html


>From what I can make out, it needs to follow the parsing conventions for CSS and that part will never change on any version of CSS.  However, beyond that I don't really know what's going on.  Does the spec require the browser to use LALR(1) for CSS 2.1 or is that merely there as an example?

If you could help explain a few things to me, maybe I could ask around for you.

Thanks,
Kevin
 -------------- Original message ----------------------
From: Maxwell Collins <ma...@um...>
> Yes, I've been following the mailing list.
> 
> I'm currently doing a more in-depth analysis of the CSS grammar
> (currently trying to determine if the CSS3 grammar is LL(1)), so I can
> better judge the available parsers.  There is a number of really odd
> properties of the CSS grammar, and one of the most important properties
> of a CSS parser is how it handles these.  I'm going to completely
> analyze all of the oddities of the CSS 2.1 grammar (which I'm familiar
> with), then try to see if I can anticipate any similar issues that may
> have arisen with some of the new CSS3 stuff.
> 
> Once I've completed that, I'll send my thoughts on all of the available
> CSS Parsers/CSSOM packages (including some beyond the three you listed).
> 
> On Fri, 2007-09-14 at 06:32 +0000, Ar...@co... wrote:
> > Hey,
> > Are you still following the mailing list?
> > I posted something about a person working on a project called UZI....  Have 
> you looked at any of the stuff he has to see if it might be something worth 
> considering for Themis?
> > 
> > Anyways, what's your thoughts on CSS (if you've gotten a chance to look)?  
> Does the current CSS look like it's a good start, does it look like the 
> foundation is bad and that it would just be better to start with a new CSS 
> parser (like yours).  I know you were interested in the particular area of CSS, 
> but the reason I'm contacting you is to see how UZI mixes into things.  In 
> comparing the 3: Themis' CSS, your CSS, or UZI's CSS, which appears to have the 
> more solid foundation (regardless of whether it's even close to feature 
> complete)... and which is closer to feature complete?
> > Of course, what involvement UZI might have in the Themis project is uncertain 
> at this point, but I didn't want their to be a conflict between what you were 
> interested in and that project (since that project also include CSS stuff).
> > 
> > Kevin
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Themis-dev mailing list
> The...@li...
> https://lists.sourceforge.net/lists/listinfo/themis-dev

[Themis-dev] CSS

[Maxwell C. <ma...@um...>]

Yes, I've been following the mailing list.

I'm currently doing a more in-depth analysis of the CSS grammar
(currently trying to determine if the CSS3 grammar is LL(1)), so I can
better judge the available parsers.  There is a number of really odd
properties of the CSS grammar, and one of the most important properties
of a CSS parser is how it handles these.  I'm going to completely
analyze all of the oddities of the CSS 2.1 grammar (which I'm familiar
with), then try to see if I can anticipate any similar issues that may
have arisen with some of the new CSS3 stuff.

Once I've completed that, I'll send my thoughts on all of the available
CSS Parsers/CSSOM packages (including some beyond the three you listed).

On Fri, 2007-09-14 at 06:32 +0000, Ar...@co... wrote:
> Hey,
> Are you still following the mailing list?
> I posted something about a person working on a project called UZI....  Have you looked at any of the stuff he has to see if it might be something worth considering for Themis?
> 
> Anyways, what's your thoughts on CSS (if you've gotten a chance to look)?  Does the current CSS look like it's a good start, does it look like the foundation is bad and that it would just be better to start with a new CSS parser (like yours).  I know you were interested in the particular area of CSS, but the reason I'm contacting you is to see how UZI mixes into things.  In comparing the 3: Themis' CSS, your CSS, or UZI's CSS, which appears to have the more solid foundation (regardless of whether it's even close to feature complete)... and which is closer to feature complete?
> Of course, what involvement UZI might have in the Themis project is uncertain at this point, but I didn't want their to be a conflict between what you were interested in and that project (since that project also include CSS stuff).
> 
> Kevin

Re: [Themis-dev] Another dev? Another code base we can use?

[<Ar...@co...>]

> > I should note something, lest there is a misunderstanding and you all think I 
> was looking to replace Themis or something.
> >
> > I was actually looking to see if anyone might be interested in implementing 
> the SEE EMCAScript Interpereter for the Themis project....  The person from the 
> UZI project replied and told me about the UZI project, why he didn't use Themis 
> in his project, etc.... In the course of things, he suggested using UZI as a 
> starting point instead of the Themis code base (because it's parsing is further 
> along and more complete than Themis).
> >   
> I apologize if you think that I was implying that, but reading your 
> message combined with what I saw on the web site gave me two distinct 
> impressions:
Sure.
In actuality, I wasn't replying to your post.  After I wrote my original message, I thought it would be a good idea to post that disclaimer (so nobody misunderstood), but couldn't get around to it till several hours later.  I actually did not read the replies until after I posted that.

> Perhaps if the roles were reversed I might have said something similar, 
> but I think I would probably have taken a slightly different approach 
> stating that I'd be willing to work with him to see how both our 
> projects can benefit from cooperation.
> 
> Again, I apologize if I'm overracting, and I don't mean or intend to 
> scare you or anyone away from this project or any other through overly 
> emotional responses. But this one got to me.
> 
> Raymond
Sure, that's ok.
My first reaction wasn't the best either.  However, as you reconsider it, there are lots of possibilities:
*) His native language is not English, so he may not smooth over his words as much :)
*) He may not understand all the nuances of why things are done the way they are done for Haiku.  This may motivate him to do things differently.
*) He may have some points that we should consider.  Who knows, maybe a best of both worlds can be accomplished through some discussion (if his project does indeed contain some very useful material).

Regarding him not understanding the Haiku/Themis approach to programing, I consider that a failure on our part -- as I always assume it is my responsibility to explain things to someone when they are misunderstanding something and I know how to explain it to them.  I had considered the possibility of having a resource to help new developers understand Haiku and why people develop native BeOS/Haiku apps.

In the case of this individual, maybe something can come of your suggestion of cooperating with him.  I'll see if he comes online later... he probably should start posting here if he plans on getting involved in any way. :)

Anyways... regarding UZI,  do you think that this project might be of use?
Here's some stuff he sent me via email:

What's in UZI:
HTML error resilient parser with HTML Strict and Traditional DTD validation
DOM engine
HTML Attribute validation
CSS 2.0 parser
(soon) CSS 2.0 dynamic rule selection in rendering
CSS box model based layout and reflow computation, including CSS table 
model
(soon) Javascript engine
URL related stuff

CSS:
Interestingly, he says "Themis CSS code is good. It's probably the best part of Themis. To be honest, I've thought about using it 2 month ago, but I finally decided to make my own so it's more homogenous."

And finally some notes about Themis:
[Keep in mind the following: Like most other people, when I'm presented with a strong statement, I can get emotional about it tool.  However, it is often to good to look things over and consider what does this person mis-understand, or why do they think that?  If they seem to be misunderstanding something, I take that as a great opportunity to explain the part they misunderstand.  In the end, their view on the issue is usually much better, and sometimes it might dramatically change things for the better.  In area of programming, it might mean gaining another Haiku developer -- that develops apps the Haiku way. :)]
Anyways, here's his comments:
I've used this programming scheme before (well, Win32 message programming I mean). However I've dropped the idea of message based task management. If you think about this, the application is only always doing the same task in the same order (HTML fetching -> HTML parsing -> DOM CSS mapping -> CSS box rendering) everytime. This means that you pay the message queue cost between every subtask while you really don't need to (no one else is using this message anyway). Sure it looks like your application is more modular, but in reality it's not, because all modules still depends on each other (structure declaration for one when passing objects in messages), and it adds useless the OS messaging queue dependency.

In UZI application part, I'm using a thread pool. Each thread can execute jobs (like fetching documents from server). However, from the parsing to the mapping it's a single job.

I'm more concerned about memory handling than making the parser run in a separate thread than the renderer. UZI memory allocation all goes to a specific interface (BaseAllocator) that can decide to reuse objects and so on. There is more performance to gain from a correct memory allocation than from multithreading something that is inherently linear and sequential.

Re: [Themis-dev] Another dev? Another code base we can use?

[Raymond C. R. <z3r...@bb...>]

Ar...@co... wrote:
> I should note something, lest there is a misunderstanding and you all think I was looking to replace Themis or something.
>
> I was actually looking to see if anyone might be interested in implementing the SEE EMCAScript Interpereter for the Themis project....  The person from the UZI project replied and told me about the UZI project, why he didn't use Themis in his project, etc.... In the course of things, he suggested using UZI as a starting point instead of the Themis code base (because it's parsing is further along and more complete than Themis).
>   
I apologize if you think that I was implying that, but reading your 
message combined with what I saw on the web site gave me two distinct 
impressions:

#1 That the UZI developer was looking for something he could just drop 
his code into and call a browser, without having to do any work. He 
dismissed Themis not because his code is any further along, but because 
he'd have to do some work to understand its admittedly chaotic and still 
early architecture. Some of which leads to point #2...

#2 I don't get the impression in any way from the project web site that 
his work has anything to do with BeOS or Haiku. I got the impression 
that he's working on something under Linux or another operating system, 
and wanted something he could use directly on another platform without 
having to port it. Themis does indeed use some code that would be easy 
to port, but it uses a lot more that is specifically tied to the Be API, 
and I'm sure eventually to Haiku specific APIs. In order for it to have 
been suitable for his needs, he'd have to figure out how to accomplish 
those tasks under whatever operating system he's using, AND still deal 
with our bugs. So he dismissed Themis stating that we'd be better off 
building around his code.

Now, I don't believe that you implied or intended to imply that we 
should do just that, but in my opinion (through a bit of "hearsay" since 
I don't have a direct quote of what he did say), I think he did imply 
just that.

I ask you and all others on this list to forgive me for being offended 
and a bit angry about this, but even though this project is way overdue, 
very much incomplete, and even I haven't spent as much time on it as I 
should have and wanted to, I still take it very personally. I've put a 
lot of hours into it, and I know the others have as well, and I still 
consider his implications an assault on me.

Perhaps if the roles were reversed I might have said something similar, 
but I think I would probably have taken a slightly different approach 
stating that I'd be willing to work with him to see how both our 
projects can benefit from cooperation.

Again, I apologize if I'm overracting, and I don't mean or intend to 
scare you or anyone away from this project or any other through overly 
emotional responses. But this one got to me.

Raymond

Re: [Themis-dev] Another dev? Another code base we can use?

[<Ar...@co...>]

> It's my understanding of GPL (and I may be completely wrong) but once 
> something has been GPLed it can't be unGPLed. It can have a second 
> "compatible" license added, or if it was originally something else, GPL 
> can be added to it, but it can't go from GPL to BSD/MIT, as far as I 
> know. Personally, I'm not willing to make Themis GPL for his project's 
> sake. Open source may be open source, but GPL and MIT are a world apart 
> in my opinion, and I also have no intention of throwing out my work so 
> that I can base the project around UZI. That would hurt my ego too much, 
> and more importantly, it would feed his entirely too much.
> 
> Raymond
To add more detail to what Cian said....  if you include GPL code into your project and then distribute your project that has some of the GPL code in it, then your entire project must be GPLed -- but you already know that. :)

Anyways, the GPL cannot go back and "infect" the original code you wrote....  If, somehow, the original code you wrote can still be separated from the GPLed part, then you are free to release just your code under a different license (as long as you remove all GPL stuff).
However, and here is the twist.  If, after you made your project GPL and someone else contributed a piece of code to your project, no matter how small, under the GPL license, you would then be unable to release your code under a non-GPL license... unless you also removed every piece of GPL coded contributed by other people.
Alternatively, there is another solution.  If you happen to know every single person who contributed every single piece of code to the project, then you can get permission from all the authors to change licenses....  This actually presents an interesting scenario if ever you find a project early on that is under the GPL... there might be a chance it can be re-licensed under such conditions.

On another note, you don't have to worry about me suggesting the use of GPLed code in Themis or any Haiku app.  In fact, I prefer not to use any of the copyleft ones (like MPL, LGPL, etc...).  Although, they do not affect other code like the GPL does, I still am not too happy about their restrictions.  If you are curious, that's one of the reasons I wanted to see if it might be possible to get help with the SEE EMCAScript engine for Themis.

Kevin

Re: [Themis-dev] Another dev? Another code base we can use?

[<Ar...@co...>]

I should note something, lest there is a misunderstanding and you all think I was looking to replace Themis or something.

I was actually looking to see if anyone might be interested in implementing the SEE EMCAScript Interpereter for the Themis project....  The person from the UZI project replied and told me about the UZI project, why he didn't use Themis in his project, etc.... In the course of things, he suggested using UZI as a starting point instead of the Themis code base (because it's parsing is further along and more complete than Themis).

Kevin

 -------------- Original message ----------------------
From: Ar...@co...
> I have emailed the developer of the following project:
> http://uziproject.free.fr/main.html
> 
> The person evaluated Themis a while back, but decided to roll his own when he 
> found Themis lacking in many areas.
> 
> Based on the front page, it shows he's done work on HTML, CSS and the DOM.
> 
> In our email, he has suggested that Themis should just start from his code base 
> instead of trying to resurrect the Themis project and improve on it.  Now, I 
> don't really know whether this is such a good idea or not, so can some of you 
> check it out? :)
> 
> Some thoughts....
> As I explained in the email, there are actually several things going for Themis:
> * Themis has a great design concept by using a threaded messaging system
> * Themis uses or plans to use Haiku APIs and widgets
> * Themis has no need to be cross-platform, but it must take every advantage of 
> Haiku for performance and design.
> In other words, Themis must be desiged to take advantage of Haiku.
> 
> Ok, so it'd probably be crazy to consider starting from a different code base.  
> However, I also think about the fact that many aspects of Themis need 
> re-working, even the all important messaging system.  Considering all the work 
> to be done, maybe it could be of use to bring together to best of both projects.  
> Then again, the project may not be what Themis needs, but I don't really know...  
> So, maybe some of you who know these things can take a look and see what to make 
> of it? :)  Perhaps evaluated from the perspective of if it will produce a better 
> browser in the long run?
> 
> BTW, the project is GPLed, but that was only because he used a GPLed renderer.  
> He wrote the rest of the code, so he'd be willing to change the license on his 
> code.
> 
> Kevin
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Themis-dev mailing list
> The...@li...
> https://lists.sourceforge.net/lists/listinfo/themis-dev

Re: [Themis-dev] Another dev? Another code base we can use?

[Cian D. <my...@gm...>]

On 13/09/2007, Raymond C. Rodgers <z3r...@bb...> wrote:
>
>
> It's my understanding of GPL (and I may be completely wrong) but once
> something has been GPLed it can't be unGPLed. It can have a second
> "compatible" license added, or if it was originally something else, GPL
> can be added to it, but it can't go from GPL to BSD/MIT, as far as I
> know. Personally, I'm not willing to make Themis GPL for his project's
> sake. Open source may be open source, but GPL and MIT are a world apart
> in my opinion, and I also have no intention of throwing out my work so
> that I can base the project around UZI. That would hurt my ego too much,
> and more importantly, it would feed his entirely too much.



 Assuming you fully own the source you can relicenced it to whatever you
want and continue from then on as that licence, but any previous releases
under the GPL must remain as GPL. This is how GPL projects such as the
Sourceforge engine become commercial products, and so on.


Cian
-- 
-------------------------
"We're busy running out of time"

Re: [Themis-dev] Another dev? Another code base we can use?

[Raymond C. R. <z3r...@bb...>]

Ar...@co... wrote:
> I have emailed the developer of the following project:
> http://uziproject.free.fr/main.html
>
> The person evaluated Themis a while back, but decided to roll his own when he found Themis lacking in many areas.
>
> Based on the front page, it shows he's done work on HTML, CSS and the DOM.
>
> In our email, he has suggested that Themis should just start from his code base instead of trying to resurrect the Themis project and improve on it.  Now, I don't really know whether this is such a good idea or not, so can some of you check it out? :)
>
>   
I don't mind that he found Themis lacking, especially since it has been 
incomplete for so many years. I don't mind that he started his own 
browser. But I find it insulting that he would suggest that we should 
start from scratch on his code base instead of resuming work on Themis. 
Nothing in or about Themis has ever been declared anything other than 
"alpha", which by itself indicates incomplete or buggy. It looks to me 
that he has as far to go from the non-rendering direction as we do in 
towards rendering, if not more.
> Some thoughts....
> As I explained in the email, there are actually several things going for Themis:
> * Themis has a great design concept by using a threaded messaging system
> * Themis uses or plans to use Haiku APIs and widgets
> * Themis has no need to be cross-platform, but it must take every advantage of Haiku for performance and design.
> In other words, Themis must be desiged to take advantage of Haiku.
>
> Ok, so it'd probably be crazy to consider starting from a different code base.  However, I also think about the fact that many aspects of Themis need re-working, even the all important messaging system.  Considering all the work to be done, maybe it could be of use to bring together to best of both projects.  Then again, the project may not be what Themis needs, but I don't really know...  So, maybe some of you who know these things can take a look and see what to make of it? :)  Perhaps evaluated from the perspective of if it will produce a better browser in the long run?
>
> BTW, the project is GPLed, but that was only because he used a GPLed renderer.  He wrote the rest of the code, so he'd be willing to change the license on his code.
>   
It's my understanding of GPL (and I may be completely wrong) but once 
something has been GPLed it can't be unGPLed. It can have a second 
"compatible" license added, or if it was originally something else, GPL 
can be added to it, but it can't go from GPL to BSD/MIT, as far as I 
know. Personally, I'm not willing to make Themis GPL for his project's 
sake. Open source may be open source, but GPL and MIT are a world apart 
in my opinion, and I also have no intention of throwing out my work so 
that I can base the project around UZI. That would hurt my ego too much, 
and more importantly, it would feed his entirely too much.

Raymond

[Themis-dev] Another dev? Another code base we can use?

[<Ar...@co...>]

I have emailed the developer of the following project:
http://uziproject.free.fr/main.html

The person evaluated Themis a while back, but decided to roll his own when he found Themis lacking in many areas.

Based on the front page, it shows he's done work on HTML, CSS and the DOM.

In our email, he has suggested that Themis should just start from his code base instead of trying to resurrect the Themis project and improve on it.  Now, I don't really know whether this is such a good idea or not, so can some of you check it out? :)

Some thoughts....
As I explained in the email, there are actually several things going for Themis:
* Themis has a great design concept by using a threaded messaging system
* Themis uses or plans to use Haiku APIs and widgets
* Themis has no need to be cross-platform, but it must take every advantage of Haiku for performance and design.
In other words, Themis must be desiged to take advantage of Haiku.

Ok, so it'd probably be crazy to consider starting from a different code base.  However, I also think about the fact that many aspects of Themis need re-working, even the all important messaging system.  Considering all the work to be done, maybe it could be of use to bring together to best of both projects.  Then again, the project may not be what Themis needs, but I don't really know...  So, maybe some of you who know these things can take a look and see what to make of it? :)  Perhaps evaluated from the perspective of if it will produce a better browser in the long run?

BTW, the project is GPLed, but that was only because he used a GPLed renderer.  He wrote the rest of the code, so he'd be willing to change the license on his code.

Kevin

Re: [Themis-dev] Taking advantage of Haiku's features?

[Raymond C. R. <z3r...@bb...>]

Ar...@co... wrote:
> I can begin looking for some things that would fit... if you want to go ahead and give a roundup of what all the site would need (kinds of software, features, and why you need it/what you want to accomplish with it).
>   
I think that Joomla (http://www.joomla.org ) or something similar would 
more than suit our needs. Basically, we need to be able to:

    * Describe the project
    * Provide news/updates
    * List FAQs
    * Provide a list of relevant links (such as to the source
      repositories, mailing lists, Haiku-os.org, etc)
    * List the developers, possibly with a simple profile page.
    * Post screenshots.
    * Have controlled access to the backend and update process so that
      only chosen individuals (such as those involved with the project
      :-) ) can update the content.


This is all easily accomplished with Joomla, but again I look at it as a 
complicated beast. If there's another CMS that can accomplish all that 
without being too complicated, I'm all for it.

Re: [Themis-dev] Taking advantage of Haiku's features?

[Michael W. <em...@m-...>]

I can always help with some webspace to some extent. Even mailinglists, 
ftp accs, mysql-dbs and subdomains. But hey, as Raymond already said...

SF provides everything one needs. Even mirroring isn't an issue where 
you'd have to put application binaries somewhere else... So go with 
everythings sf provides. That's what it's there for :)

Michael

Raymond C. Rodgers schrieb:
> Ar...@co... wrote:
>> I can begin looking for some things that would fit... if you want to go ahead and give a roundup of what all the site would need (kinds of software, features, and why you need it/what you want to accomplish with it).
>>
>> As for hosting, I don't suppose anyone here has a server? :)  I can see if we can find some hosting somewhere other than sourceforge...  I usually try to find host with PostgreSQL support...  Otherwise, maybe I can take care of hosting... it's probably about time I did something like that anyways.  Anyways... whatever you think.
>>
>>   
> 
> As much as I dislike MySQL, I think it best to stick with SF and use 
> MySQL since we already have it available to us. Plus it eliminates the 
> need to find a hosting provider, come up with the hosting fees or a 
> sponsor to pay for the space and bandwidth. SF gives us these things for 
> free.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Themis-dev mailing list
> The...@li...
> https://lists.sourceforge.net/lists/listinfo/themis-dev
> 
> 

Re: [Themis-dev] Taking advantage of Haiku's features?

[Raymond C. R. <z3r...@bb...>]

Ar...@co... wrote:
> I can begin looking for some things that would fit... if you want to go ahead and give a roundup of what all the site would need (kinds of software, features, and why you need it/what you want to accomplish with it).
>
> As for hosting, I don't suppose anyone here has a server? :)  I can see if we can find some hosting somewhere other than sourceforge...  I usually try to find host with PostgreSQL support...  Otherwise, maybe I can take care of hosting... it's probably about time I did something like that anyways.  Anyways... whatever you think.
>
>   

As much as I dislike MySQL, I think it best to stick with SF and use 
MySQL since we already have it available to us. Plus it eliminates the 
need to find a hosting provider, come up with the hosting fees or a 
sponsor to pay for the space and bandwidth. SF gives us these things for 
free.

Re: [Themis-dev] Mails arriving out of order?

[Raymond C. R. <z3r...@bb...>]

Ar...@co... wrote:
> Hmm...  maybe it's the To line... or the Subject line... or the content....
> Let me try editing the To line....
>
> If this message messes up as well, can someone reply to this message and post the following info:
> * Exactly what shows up in your "To:" line.
> * Exactly what shows up in your "Subject:"
> * Exactly what appears in your content box (before you add your own comments)
> Maybe I can figure out which one is wrong from looking at how yours works.  It sometimes works, sometimes doesn't
> BTW, does it matter to the mailing list where you add your reply or whether you even include pieces of the original message you are replying to?
>
> Thanks,
> Kevin
>
>  -------------- Original message ----------------------
> From: Michael Weirauch <em...@m-...>
>   
>> Kevin, can it be that you are still not registered with the list and 
>> your mailings are waiting approval from Raymond?
>>
>> If so, please register with this list (and any other if you like) here:
>> http://sourceforge.net/mail/?group_id=13124
>>
>> Most active (will and) have been dev and devcvs.
>>
>> Greetings,
>> Michael
>>     
It could just be the mailing list... It has been known to act up in the 
past, but unfortunately it's an aspect of SF over which I only have 
general control.

Re: [Themis-dev] Mails arriving out of order?

[Michael W. <em...@m-...>]

As I meantioned just out of time. No other subject/thread issues imho.

Ar...@co... schrieb:
> Hmm...  maybe it's the To line... or the Subject line... or the content....
> Let me try editing the To line....
> 
> If this message messes up as well, can someone reply to this message and post the following info:
> * Exactly what shows up in your "To:" line.
> * Exactly what shows up in your "Subject:"
> * Exactly what appears in your content box (before you add your own comments)
> Maybe I can figure out which one is wrong from looking at how yours works.  It sometimes works, sometimes doesn't
> BTW, does it matter to the mailing list where you add your reply or whether you even include pieces of the original message you are replying to?
> 
> Thanks,
> Kevin
> 
>  -------------- Original message ----------------------
> From: Michael Weirauch <em...@m-...>
>> Kevin, can it be that you are still not registered with the list and 
>> your mailings are waiting approval from Raymond?
>>
>> If so, please register with this list (and any other if you like) here:
>> http://sourceforge.net/mail/?group_id=13124
>>
>> Most active (will and) have been dev and devcvs.
>>
>> Greetings,
>> Michael
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Themis-dev mailing list
>> The...@li...
>> https://lists.sourceforge.net/lists/listinfo/themis-dev
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Themis-dev mailing list
> The...@li...
> https://lists.sourceforge.net/lists/listinfo/themis-dev
> 
>