Re: [chromium-dev] how to disable SVG when building chromium

[Jeremy Orlow]

Oh, according to the file, build/features_override.gypi will also do the
trick.

On Mon, Jan 18, 2010 at 11:53 PM, Jeremy Orlow  wrote:

> http://trac.webkit.org/browser/trunk/WebKit/chromium/features.gypi
>
> WebKit is under third_party/WebKit in the src tree
>
> On Mon, Jan 18, 2010 at 11:45 PM, n179911  wrote:
>
>> Hi,
>>
>> Webkit has an option to disable SVG build with the executable. Can you
>> please tell me how can I disable SVG when build chromium?
>>
>> Thank you.
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] how to disable SVG when building chromium

[Jeremy Orlow]

http://trac.webkit.org/browser/trunk/WebKit/chromium/features.gypi

WebKit is under third_party/WebKit in the src tree

On Mon, Jan 18, 2010 at 11:45 PM, n179911  wrote:

> Hi,
>
> Webkit has an option to disable SVG build with the executable. Can you
> please tell me how can I disable SVG when build chromium?
>
> Thank you.
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] how to disable SVG when building chromium

[n179911]

Hi,

Webkit has an option to disable SVG build with the executable. Can you
please tell me how can I disable SVG when build chromium?

Thank you.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 36513

[buildbot]

Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2413

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29

--=>  Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"  
<=--

Revision: 36513
Blame list: a...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 36512

[Satoru Takabayashi]

Thanks to tc, the build is now green, and the tree is reopened.


The problem was that the original SConstruct file in the "cros" directory
was overwritten by gclient when it generated SConstruct files for hammer.
For now, we reverted the generated SConstruct file on the machine to get
gclient sync to work. I'll talk to the build bot maintainers for the right
fix.

Satoru

On Tue, Jan 19, 2010 at 3:52 PM, Satoru Takabayashi  
wrote:



The SConstruct file seemed to be changed locally on the build bot machine,
that is preventing gclient sync from updating the file. I'll ask the build
bot maintainers to fix this.



Thanks,
Satoru





On Tue, Jan 19, 2010 at 3:42 PM, Yusuke Sato  wrote:



FYI, Satoru:




http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20(ChromiumOS)/builds/2411/steps/gclient/logs/stdio



_ src/third_party/cros at e196be04
Updating origin
cannot rebase: you have unstaged changes
M SConstruct
Checked out revision b4ce165dfdf395202f1582d553c1ce3688d135b2.




--Yusuke






On Tue, Jan 19, 2010 at 3:21 PM,  wrote:



  http://build.chromium.org/buildbot/waterfall/



Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"




http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2410



Revision: 36512
Blame list: sato...@chromium.org



  Linux Builder (ChromiumOS)
Build  
2410   
update

scripts
stdio
update
stdio
compile
failed
stdio



Changed by: *sato...@chromium.org*
Changed at: *Mon 18 Jan 2010 22:17:37*
Branch: *src*
Revision:  
*36512*

Changed files:



- *chrome/browser/chromeos/language_library.cc*
- *chrome/browser/chromeos/language_library.h*



Comments:



Add GetSupportedLanguages(), ActiveLanguage(), and DeactivateLanguage().



These are wrappers for functions added in libcros
http://git.chromium.org/cgi-bin/gitweb.cgi?p=cros.git;a=commit;h=adc84eae83d75cc6c2a59c89e5276d072ca69c8d



TEST=none
BUG=none



Review URL: http://codereview.chromium.org/542108



Properties:





--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev





-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 36512

[Satoru Takabayashi]

The SConstruct file seemed to be changed locally on the build bot machine,
that is preventing gclient sync from updating the file. I'll ask the build
bot maintainers to fix this.

Thanks,
Satoru


On Tue, Jan 19, 2010 at 3:42 PM, Yusuke Sato  wrote:


FYI, Satoru:




http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20(ChromiumOS)/builds/2411/steps/gclient/logs/stdio



_ src/third_party/cros at e196be04
Updating origin
cannot rebase: you have unstaged changes
M SConstruct
Checked out revision b4ce165dfdf395202f1582d553c1ce3688d135b2.




--Yusuke






On Tue, Jan 19, 2010 at 3:21 PM,  wrote:



  http://build.chromium.org/buildbot/waterfall/



Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"




http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2410



Revision: 36512
Blame list: sato...@chromium.org



  Linux Builder (ChromiumOS)
Build  
2410   
update

scripts
stdio
update
stdio
compile
failed
stdio



Changed by: *sato...@chromium.org*
Changed at: *Mon 18 Jan 2010 22:17:37*
Branch: *src*
Revision:  
*36512*

Changed files:



- *chrome/browser/chromeos/language_library.cc*
- *chrome/browser/chromeos/language_library.h*



Comments:



Add GetSupportedLanguages(), ActiveLanguage(), and DeactivateLanguage().



These are wrappers for functions added in libcros
http://git.chromium.org/cgi-bin/gitweb.cgi?p=cros.git;a=commit;h=adc84eae83d75cc6c2a59c89e5276d072ca69c8d



TEST=none
BUG=none



Review URL: http://codereview.chromium.org/542108



Properties:





--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev




-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 36512

[Yusuke Sato]

FYI, Satoru:

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20(ChromiumOS)/builds/2411/steps/gclient/logs/stdio

_ src/third_party/cros at e196be04
Updating origin
cannot rebase: you have unstaged changes
M SConstruct
Checked out revision b4ce165dfdf395202f1582d553c1ce3688d135b2.


--Yusuke




On Tue, Jan 19, 2010 at 3:21 PM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2410
>
> Revision: 36512
> Blame list: sato...@chromium.org
>
>  Linux Builder (ChromiumOS)
> Build 
> 2410
>   update
> scripts
> stdio
> update
> stdio
> compile
> failed
> stdio
>
> Changed by: *sato...@chromium.org*
> Changed at: *Mon 18 Jan 2010 22:17:37*
> Branch: *src*
> Revision: 
> *36512*
> Changed files:
>
>- *chrome/browser/chromeos/language_library.cc*
>- *chrome/browser/chromeos/language_library.h*
>
> Comments:
>
> Add GetSupportedLanguages(), ActiveLanguage(), and DeactivateLanguage().
>
> These are wrappers for functions added in libcros
> http://git.chromium.org/cgi-bin/gitweb.cgi?p=cros.git;a=commit;h=adc84eae83d75cc6c2a59c89e5276d072ca69c8d
>
> TEST=none
> BUG=none
>
> Review URL: http://codereview.chromium.org/542108
>
> Properties:
>
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 36512

[buildbot]

Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2410

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29

--=>  Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"  
<=--

Revision: 36512
Blame list: sato...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] gfx::Font and WebCore::Font

[hap 497]

There are 2 Font classes in chromium code:

app/gfx/Font.h
third_party/WebKit/WebCore/platform/graphics/Font.h

Can you please tell me what is the purpose of each one (specifically on Linux)?

Thank you.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths

[Dirk Pranke]

On Mon, Jan 18, 2010 at 7:16 PM, Peter Kasting  wrote:
> On Mon, Jan 18, 2010 at 4:54 PM, Dirk Pranke  wrote:
>>
>> So, you then get the following algorithm:
>>
>> 1) if there is a ':' in the URI, you split the URI into scheme and
>> scheme-specific part.
>>
>> 2) If there is a scheme:
>>
>>  2.1) If the scheme is a recognized/supported one, dispatch the URL
>> as you would normally.
>>
>>  2.2) If scheme matches [a-zA-Z] and you are on Windows, treat as an
>> absolute local file URL
>>
>>  2.3) Else, treat this as a syntax error in the URI
>>
>> 3) If there is no scheme:
>>
>>  3.1) If the URI starts with a "/", treat it as a full path relative
>> to the current context (e.g., current scheme, host and port. If your
>> current context is a local filesystem, then treat it as a file://
>> scheme
>>
>>  3.2) If the URI starts with a "\", you're on Windows, and the
>> context is a local file system point, repeat as above, prepending with
>> the current drive
>>
>>  3.3) If the URI doesn't start with a "/" or a "\", then, optionally,
>> check to see if the URI resolves to a valid hostname. This catches the
>> "chrome.exe www.google.com" use case
>>
>>  3.4) If the URI doesn't resolve to a valid hostname, then interpret
>> it as a relative URL
>
> I'd pretty strongly like to not specify steps like these.  They duplicate
> code we already have for interpreting user input, except with less fidelity.
>  We have quite sophisticated heuristics for how to figure out the correct
> scheme, parse drive letters, UNC paths, etc.  We don't need to write another
> set.
> I also don't really care about trying to fix up "www.google.com"; if it
> falls out of the existing code, fine, but I wouldn't bother spending time on
> it.  I'm definitely opposed to doing anything like "try DNS resolution on X
> and fall back to Y" since it makes the results unpredictable based on your
> network.  What if the user specifies a filename that's also an intranet
> host?  What if the user says "www.google.com" but the network is currently
> down -- does the browser show a "couldn't open local file www.google.com"
> error?  etc.
> It's enough to simply say "run the input through fixup, supplying the CWD as
> the relative file path base".  We have code that can basically take it from
> there.

This sounds fine, although I'd be curious to see where the logic in
fixup differs from the above. I certainly agree that we don't want an
additional code path.

I would perhaps amend "resolve to a valid hostname" to "looks like a
hostname", although I don't know what heuristics we use for that (if
any other than passing it to name resolution).

> PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths

[Peter Kasting]

On Mon, Jan 18, 2010 at 4:54 PM, Dirk Pranke  wrote:

> So, you then get the following algorithm:
>
> 1) if there is a ':' in the URI, you split the URI into scheme and
> scheme-specific part.
>
> 2) If there is a scheme:
>
>  2.1) If the scheme is a recognized/supported one, dispatch the URL
> as you would normally.
>
>  2.2) If scheme matches [a-zA-Z] and you are on Windows, treat as an
> absolute local file URL
>
>  2.3) Else, treat this as a syntax error in the URI
>
> 3) If there is no scheme:
>
>  3.1) If the URI starts with a "/", treat it as a full path relative
> to the current context (e.g., current scheme, host and port. If your
> current context is a local filesystem, then treat it as a file://
> scheme
>
>  3.2) If the URI starts with a "\", you're on Windows, and the
> context is a local file system point, repeat as above, prepending with
> the current drive
>
>  3.3) If the URI doesn't start with a "/" or a "\", then, optionally,
> check to see if the URI resolves to a valid hostname. This catches the
> "chrome.exe www.google.com" use case
>
>  3.4) If the URI doesn't resolve to a valid hostname, then interpret
> it as a relative URL


I'd pretty strongly like to not specify steps like these.  They duplicate
code we already have for interpreting user input, except with less fidelity.
 We have quite sophisticated heuristics for how to figure out the correct
scheme, parse drive letters, UNC paths, etc.  We don't need to write another
set.

I also don't really care about trying to fix up "www.google.com"; if it
falls out of the existing code, fine, but I wouldn't bother spending time on
it.  I'm definitely opposed to doing anything like "try DNS resolution on X
and fall back to Y" since it makes the results unpredictable based on your
network.  What if the user specifies a filename that's also an intranet
host?  What if the user says "www.google.com" but the network is currently
down -- does the browser show a "couldn't open local file www.google.com"
error?  etc.

It's enough to simply say "run the input through fixup, supplying the CWD as
the relative file path base".  We have code that can basically take it from
there.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Webkit Mac10.5 (dbg)(3), revision 36505

[buildbot]

Automatically closing tree for "test_shell_tests" on "Webkit Mac10.5 (dbg)(3)"

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20%28dbg%29%283%29/builds/9273

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Mac10.5%20%28dbg%29%283%29

--=>  Automatically closing tree for "test_shell_tests" on "Webkit Mac10.5 
(dbg)(3)"  <=--

Revision: 36505
Blame list: rse...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Re: opening local files with chrome from command line, relative paths

[Dirk Pranke]

I'm not sure if we reached a conclusion on this, but I don't like a
couple of aspects of the Firefox logic (assuming I understood it
correctly).

The way I would look at it, the browser always has a "current context"
that indicates the current base to use for relative URIs. In the case
where you are launching the browser for the command line, the current
base = $CWD (and, implicitly, file://).

So, you then get the following algorithm:

1) if there is a ':' in the URI, you split the URI into scheme and
scheme-specific part.

2) If there is a scheme:

  2.1) If the scheme is a recognized/supported one, dispatch the URL
as you would normally.

  2.2) If scheme matches [a-zA-Z] and you are on Windows, treat as an
absolute local file URL

  2.3) Else, treat this as a syntax error in the URI

3) If there is no scheme:

  3.1) If the URI starts with a "/", treat it as a full path relative
to the current context (e.g., current scheme, host and port. If your
current context is a local filesystem, then treat it as a file://
scheme

  3.2) If the URI starts with a "\", you're on Windows, and the
context is a local file system point, repeat as above, prepending with
the current drive

  3.3) If the URI doesn't start with a "/" or a "\", then, optionally,
check to see if the URI resolves to a valid hostname. This catches the
"chrome.exe www.google.com" use case

  3.4) If the URI doesn't resolve to a valid hostname, then interpret
it as a relative URL

I think this is mostly the same as the FF algorithm, except for 3.3. I
agree that trying the "local then remote" logic is probably going to
lead to weird and/or unintended consequences. I could be convinced to
omit 3.3, but I don't see any real risks here. The worst case is that
you'd have to specify "./www.google.com" to open a relative local file
called www.google.com, but that's a pretty obscure corner case.

I wouldn't add the -url switch, since it is actually misleadingly
named (relative URLs are URLs).

-- Dirk

On Mon, Jan 11, 2010 at 2:23 PM, Benjamin Smedberg  wrote:
> For what it's worth, the way Firefox solves this is:
>
> * Check if the file is an absolute file path
> ** on Windows, X:\... or \\...
> ** on Posix, /...
> * Otherwise, it's a URL relative to the current working directory
> ** So index.html resolves using the URL machinery to
> file:///c:/cwd/index.html
> ** while http://www.google.com resolves to itself
>
> This doesn't deal with the case firefox.exe www.google.com (which would try
> to resolve as a file), but we decided not to care about this case. We do
> have the explicit firefox.exe -url www.google.com which will perform URI
> fixup to guess the correct URL.
>
> --BDS
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] WebKitApi (test_shell) and DevTools, JS debugging

[Peter Kasting]

On Mon, Jan 18, 2010 at 9:16 AM, vridosh  wrote:

> As far as I
> understand, that's why Debugger tab was not available in test_shell in
> early Chromium builds.


Probably the real reason is because test_shell isn't meant to be a reference
implementation of everything and we never bothered to spend any time on it.

So, the main question is - is it possible at all to make DevTools JS
> debugger in test_shell to work correctly?
>

AFAIK test_shell is obsolete and is going to die when we implement
DumpRenderTree atop the WebKit API.  Darin or Dimitri or someone can correct
me if I'm wrong.

I would definitely not depend on or look at test_shell for any serious
project.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] License implications on Chromium's design

[Dan Kegel]

On Mon, Jan 18, 2010 at 3:22 PM, Jerome Leclanche  wrote:
> My question
> bears on a different level: is the UI layout (not code) somewhat restricted
> in any way? I'm no lawyer, nor do I know much about interface licensing.

IANAL, but if you're not copying any images, and are
just imitating the look-and-feel, I'm not sure what
infringement there could be.  See
http://en.wikipedia.org/wiki/Look_and_feel#Lawsuits_over
- Dan

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Chromium XP, revision 36498

[buildbot]

Automatically closing tree for "archived build" on "Chromium XP"

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/9740

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP

--=>  Automatically closing tree for "archived build" on "Chromium XP"  <=--

Revision: 36497, 36498
Blame list: fin...@chromium.org,rse...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] WebKitApi (test_shell) and DevTools, JS debugging

[vridosh]

Hi,

I'm going to start my project based on WebKit API and planning to use
test_shell as a reference implementation. I also want to use DevTools
to allow end-user to debug HTML and especially JavaScript.

Could you please tell how viable is the JS debugger in test_shell/
WebKit API?

As far as I understand, in case of breakpoint V8 debugger stops the
script execution on the whole process. That problem could be easy
reproduced while running Chrome in single-process mode (AFAIR, this
mode is obsolete for modern Chromium browser) - trying to pause script
execution pauses all JS code, including DevTools JS code too, which
causes "deadlock" - script couldn't be resumed anymore. As far as I
understand, that's why Debugger tab was not available in test_shell in
early Chromium builds. But when I tried to use current test_shell
build, I was able to pause JS execution on breakpoint and then resume
JS again. From the other hand, while staying on JS breakpoint not all
parts of DevTools debugger works well - f.e. I couldn't execute JS in
console. Also, as I got, pausing JS in any custom place (I mean, left
button just above watch expressions and call stack) not implemented
yet it all.

So, the main question is - is it possible at all to make DevTools JS
debugger in test_shell to work correctly?

I'd appreciate any suggestions.

Regards,
Vadim Ridosh
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] License implications on Chromium's design

[Sam Kerner]

On Mon, Jan 18, 2010 at 6:07 PM, Jerome Leclanche  wrote:
> Hi people
> I'm currently writing an IM client in C++ with Qt. I'm basing the entire UI
> strongly upon the Chromium philosophy - tabs on top, no menus, one global
> url bar, a new-tab page, so on.
> Before opening up the code base, I want to know what the implications are,
> license-wise. Ideally, the project would be released under BSD or MIT.

Are you using chromium code, or just creating a UI that looks like
chromium's UI?

Sam

> Spare some advice :-)
>
> J. Leclanche / Adys
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] License implications on Chromium's design

[Jerome Leclanche]

I'm not using any chromium code, just replicating the idea of the UI in a
different framework for a different kind of application.

Nico, thanks, but I already know Chromium is licensed under BSD. My question
bears on a different level: is the UI layout (not code) somewhat restricted
in any way? I'm no lawyer, nor do I know much about interface licensing.
J. Leclanche / Adys


On Tue, Jan 19, 2010 at 1:18 AM, Sam Kerner  wrote:

> On Mon, Jan 18, 2010 at 6:07 PM, Jerome Leclanche 
> wrote:
> > Hi people
> > I'm currently writing an IM client in C++ with Qt. I'm basing the entire
> UI
> > strongly upon the Chromium philosophy - tabs on top, no menus, one global
> > url bar, a new-tab page, so on.
> > Before opening up the code base, I want to know what the implications
> are,
> > license-wise. Ideally, the project would be released under BSD or MIT.
>
> Are you using chromium code, or just creating a UI that looks like
> chromium's UI?
>
> Sam
>
> > Spare some advice :-)
> >
> > J. Leclanche / Adys
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> >http://groups.google.com/group/chromium-dev
> >
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] License implications on Chromium's design

[Finnur Thorarinsson]

Furthermore, the people on this list are developers who are not qualified to
hand out legal advice.

On Mon, Jan 18, 2010 at 15:13, Nico Weber  wrote:

> http://lmgtfy.com/?q=chromium+license
>
> First hit.
>
> On Mon, Jan 18, 2010 at 3:07 PM, Jerome Leclanche 
> wrote:
> > Hi people
> > I'm currently writing an IM client in C++ with Qt. I'm basing the entire
> UI
> > strongly upon the Chromium philosophy - tabs on top, no menus, one global
> > url bar, a new-tab page, so on.
> > Before opening up the code base, I want to know what the implications
> are,
> > license-wise. Ideally, the project would be released under BSD or MIT.
> > Spare some advice :-)
> >
> > J. Leclanche / Adys
> >
> > --
> > Chromium Developers mailing list: chromium-dev@googlegroups.com
> > View archives, change email options, or unsubscribe:
> >http://groups.google.com/group/chromium-dev
> >
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] License implications on Chromium's design

[Nico Weber]

http://lmgtfy.com/?q=chromium+license

First hit.

On Mon, Jan 18, 2010 at 3:07 PM, Jerome Leclanche  wrote:
> Hi people
> I'm currently writing an IM client in C++ with Qt. I'm basing the entire UI
> strongly upon the Chromium philosophy - tabs on top, no menus, one global
> url bar, a new-tab page, so on.
> Before opening up the code base, I want to know what the implications are,
> license-wise. Ideally, the project would be released under BSD or MIT.
> Spare some advice :-)
>
> J. Leclanche / Adys
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] License implications on Chromium's design

[Jerome Leclanche]

Hi people

I'm currently writing an IM client in C++ with Qt. I'm basing the entire UI
strongly upon the Chromium philosophy - tabs on top, no menus, one global
url bar, a new-tab page, so on.
Before opening up the code base, I want to know what the implications are,
license-wise. Ideally, the project would be released under BSD or MIT.

Spare some advice :-)


J. Leclanche / Adys
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev