Re: KDE file dialog

2016-03-06 Thread Kai Uwe Broulik
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

2016-03-06 Thread Martin Koller
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 Koller  wrote:
> > > 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

2016-03-06 Thread Albert Astals Cid
El Sunday 06 March 2016, a les 08:38:14, Boudhayan Gupta va escriure:
> On 6 March 2016 at 01:26, Martin Koller  wrote:
> > 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

2016-03-06 Thread Thomas Lübking

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

2016-03-06 Thread Martin Graesslin
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

2016-03-06 Thread Thomas Friedrichsmeier
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 Jensen  wrote:
> 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