Re: KDE file dialog
Hi, > Distributions set up distribution-wide "Sans", "Serif" and "Monospace" > aliases for a reason. The fonts are carefully selected by the distribution > based on a variety of criteria, including glyph coverage We tried to keep font decisions to distributions before Plasma 5 and it always made me cringe how terrible fonts looked in screenshots from other people and was one of the first things I had to change on every fresh install. Now we pick some sane defaults that make it look good and unified across distributions. Cheers, Kai Uwe
Re: Qt5 version of qimageblitz
On Sunday 06 March 2016 12:35:32 Albert Astals Cid wrote: > El Sunday 06 March 2016, a les 08:38:14, Boudhayan Gupta va escriure: > > On 6 March 2016 at 01:26, Martin Kollerwrote: > > > Who is in charge of the old SVN repos ? > > > Who is in charge of qimageblitz ? > > > > I asked around on IRC and it seems QIB is "community maintained" and > > as such doesn't have a maintainer. > > > > You should just be able to file a sysadmin ticket to get it migrated > > from SVN to Git. > > It was my understanding that qimageblitz is actually not something we want to > port to Qt5 and we should just try to use Qt's own stuff for this. AFAIK Qt does not provide the features of qimageblitz, e.g. emboss etc. > If qimageblitz gets ported to Qt5 it should basically be a Tier 0 frameworks > so CC'ing the frameworks devel list. It WAS already ported to Qt5. I did not do any porting, I just created a patch which allows to co-install the Qt4 and the Qt5 built version. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\- against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at
Re: Qt5 version of qimageblitz
El Sunday 06 March 2016, a les 08:38:14, Boudhayan Gupta va escriure: > On 6 March 2016 at 01:26, Martin Kollerwrote: > > Who is in charge of the old SVN repos ? > > Who is in charge of qimageblitz ? > > I asked around on IRC and it seems QIB is "community maintained" and > as such doesn't have a maintainer. > > You should just be able to file a sysadmin ticket to get it migrated > from SVN to Git. It was my understanding that qimageblitz is actually not something we want to port to Qt5 and we should just try to use Qt's own stuff for this. If qimageblitz gets ported to Qt5 it should basically be a Tier 0 frameworks so CC'ing the frameworks devel list. Cheers, Albert > > -- Boudhayan Gupta
Re: KDE file dialog
On Sonntag, 6. März 2016 11:34:32 CEST, Martin Graesslin wrote: I don't know how often we have heard over the last decade that Plasma's look and feel is terribly because of fonts. I'd have assumed that'd be because of the freetype rasterizers being, errr ummm... shit (almost as shit as cleartype ;-) - and be resolved by the CFF rasterizer? Cheers, Thomas
Re: KDE file dialog
On Sunday, March 6, 2016 1:48:13 AM CET Kevin Kofler wrote: > Martin Graesslin wrote: > > No, because everything in the current plugin is Plasma specific. If we > > want to change the font, we will do so! > > Forcing a default font as you have done is a bad idea even on Plasma. It is > not the desktop environment's business to pick a default font. (And yes, I > know GNOME does it too, with a much worse font (really poor glyph coverage). > That's not a reason to do the same.) Distributions set up distribution-wide > "Sans", "Serif" and "Monospace" aliases for a reason. The fonts are > carefully selected by the distribution based on a variety of criteria, > including glyph coverage (OK, Noto is great there; your previous default > Oxygen was not, though!), quality, looks, etc. And most importantly, the > distro-wide aliases ensure consistency across applications using different > toolkits. Desktops deciding they know better break this. I don't know how often we have heard over the last decade that Plasma's look and feel is terribly because of fonts. We addressed that point and selected a good default font. Now that's not correct either. People make up your mind: either you do your job and use good default fonts or you don't complain that we select the font for you. You cannot have both. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Policy regarding QtWebKit and QtScript
Hi, sorry for a somewhat bitter tone, I find it a bit hard to avoid(*): On Sat, 5 Mar 2016 11:37:48 +0100 Allan Sandfeld Jensenwrote: > On Saturday 05 March 2016, Thomas Lübking wrote: > > On Samstag, 5. März 2016 08:09:22 CEST, Thomas Friedrichsmeier > > wrote: > > > QtWebEngine can _only_ be compiled using (free > > > as in beer) MSVC 2013. In particular, MinGW is explicitly _not_ > > > supported. > > > > Out of pure curiosity: got details on this? > > MSVC 2013 hardly supersets the GNU toolchain and the code cannot > > make use of MSVC's "let's try to compile this junk, despite it's > > not nearly valid c++" features, because it generally still needs to > > compile on other systems. > > > Chromium doesn't support it, and generally we try to stick to the > same platforms Chromium support. We haven't actually investigated how > much work it would be to make it work. I think making a credible effort in that direction is really the _least_ thing you can and should do. I do understand your whole idea is to get by with fewer (or no) patches(**). And I understand you are not particularly keen to even think about introducing a significant patch-set, when you have long since committed to QtWebEngine. But that strategy simply carries a cost, and I'm not quite sure that this is well-understood, yet. As things stand, I think you are effectively phasing out MinGW-support, and to be honest, my impression is that you have not been terribly upfront about it, so far. Regards Thomas --- (*) So, some background, in case anyone is interested: My application needs an internal HTML-browser for several purposes. It also interfaces with MinGW-only library / environment. (Why not try to support MSVC for that library, I hear you ask? Because it has literally 8000+ add-on packages, not all of which are cross-platform, not all of which contain compiled code, but thousands of which are distributed as - MinGW-compiled - binaries.) I am lucky on two counts, here: First, I don't need to display any remote HTML, and so I can get by using QtWebKit for now. But the time will come when some of the add-ons start relying on browser features that are not supported by QtWebKit, or some third application/framework, that I'd like to interface with, will hard-depend on QtWebEngine. Second, I am interfacing with a C-only API, and so I can (sort of) get along with MSVC. But there are more subtleties in mixing the two compilers than an incompatible C++-ABI, and these are no-fun at all to debug. As one example, it took me almost an entire day to debug a (deterministic!) crash, when the MinGW-library was trying to free a pointer that I had to allocate myself (with MSVC). Getting lucky, again, I did find a way to hack around this. But there are more, non-derministic issues that appear to be unique to the MSVC-build. (**) On the other hand, at least these patches would not be Qt-specific. Even if they won't be upstreamed, I imagine you could count on a least some community support in maintaining them. pgpop31tLWwA3.pgp Description: OpenPGP digital signature