220 8891 article Path: news.gmane.org!not-for-mail From: Ville Voutilainen Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Comments on 2d api for c++ N3888.pdf Date: Tue, 28 Jan 2014 16:53:47 +0200 Lines: 53 Approved: news@gmane.org Message-ID: References: <9105f9b2-e15d-4bf8-a4a1-65ebc3657eb0@isocpp.org> <9B43C5E6-DDDE-4373-AFDA-948526CD8734@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1390920842 25845 80.91.229.3 (28 Jan 2014 14:54:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jan 2014 14:54:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC5JHI7A7ALRB7MIT6LQKGQEGEGZWWA@isocpp.org Tue Jan 28 15:54:10 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-fa0-f71.google.com ([209.85.161.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W8A2x-0000rB-2C for gclcip-std-proposals@m.gmane.org; Tue, 28 Jan 2014 15:53:51 +0100 Original-Received: by mail-fa0-f71.google.com with SMTP id v1sf1176719fav.2 for ; Tue, 28 Jan 2014 06:53:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=Ikjo29sOjBVCWHWKUh8stT/fml0QeouIsRV7o0b8adQ=; b=UHeEtbH6hSx5EoWHdaKgKgi1L9Vz+/G1Gcio/JBpk3ppsppzaI0Lf3a7NYGwIXRktl EouNtRR1CvFjGxen9Ymf0K0dm73Ev5IbSZscSgairdtr6ItRBxE4pbrT8TcIL5sQSDqg c5MV3S/0xmx1ipX6AJYObEBKhXdGCEcHDeTU99MYBrYi0ZtVVs7FC7yW0kD+9827hYmJ oM0EPMIYdApdT+knJnw7Y6IQsH/yFbA7jUfWBLqBk318MM5dLb2uSX2kPsAJnM4bSCXc eVlHoPmL6v4cDZCBfL0NcnHRkmVYk+I5BkI7sOQTW9NBQK/dv32dx/Vu1ZZZdLJvQkD4 EpFQ== X-Gm-Message-State: ALoCoQksa/h9faxDTtlrdRspyGcj8ksyPw9Jw3YmdxsN+HWuPetQnavUY8wxmLq1x4Av0CBH6JkT X-Received: by 10.180.189.18 with SMTP id ge18mr17139832wic.1.1390920830507; Tue, 28 Jan 2014 06:53:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.85.105 with SMTP id g9ls1188991wiz.1.canary; Tue, 28 Jan 2014 06:53:49 -0800 (PST) X-Received: by 10.204.53.75 with SMTP id l11mr2554631bkg.35.1390920828904; Tue, 28 Jan 2014 06:53:48 -0800 (PST) Original-Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [2607:f8b0:400d:c01::22f]) by mx.google.com with ESMTPS id tn6si18625093bkb.244.2014.01.28.06.53.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 06:53:48 -0800 (PST) Received-SPF: pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::22f as permitted sender) client-ip=2607:f8b0:400d:c01::22f; Original-Received: by mail-qc0-f175.google.com with SMTP id x13so663414qcv.34 for ; Tue, 28 Jan 2014 06:53:47 -0800 (PST) X-Received: by 10.229.213.194 with SMTP id gx2mr3081621qcb.16.1390920827360; Tue, 28 Jan 2014 06:53:47 -0800 (PST) Original-Received: by 10.224.49.65 with HTTP; Tue, 28 Jan 2014 06:53:47 -0800 (PST) In-Reply-To: X-Original-Sender: ville.voutilainen@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ville.voutilainen@gmail.com designates 2607:f8b0:400d:c01::22f as permitted sender) smtp.mail=ville.voutilainen@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8891 Archived-At: On 28 January 2014 16:44, Matthew Woehlke wrote: > Sacrificing quality of API for ease of porting an existing implementation > seems like a dubious trade-off IMHO. If it is generally felt that Qt It's a trade-off to get an implementable starting point that can then be worked towards a higher-quality API. The point is having an implementation available from day one. > represents a good API design "except for all those Qt classes", then IMHO > the right thing to do is do a mass-rename of Qt classes to STL classes and > propose the result as the API. The question is whether QPainter as an API _starting point_ is better than Cairo. >>> 8) Interoperability with the underlying platform is essential (again with >>> a standard way to convert types that represents images, brushes, >>> colors, fonts etc... from the native type to the std:: ones). > Really? Why? In order to access platform-specific facilities that are not supported by the portable API. Yes, that access is platform-specific and results in non-portable code. However, it can be essential for interoperating with platform-specific facilities, which sometimes are necessary. > I've written a number of Qt and/or OpenGL applications, and can't think of > any case in which I've needed to deal directly with e.g. X objects. I can. I have written Qt applications that needed to use eg. XDamage to get a live thumbnail of running applications. And for a window list, that meant dealing with X window handles, too. > Per above, this is actively *harmful* to writing portable code and IMHO > should be strongly discouraged. Even on a single platform, it precludes (or > at least, makes much more difficult) engine agnosticism. Yes, it's harmful to writing portable code, but it is in contrast more harmful to say that this API of ours allows no interoperability with platform-specific facilities. The users who need such "escape hatches" to interoperate with platform-specific facilities cannot use this portable API at all. The native handles in the standard thread library are there for a reason. That reason applies similarly to a standard drawing library. -- --- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. .