Re: [Development] Naming of path/directory-related environment variables in Qt

[Matthew Woehlke]

On 2016-11-11 10:13, Mitch Curtis wrote:
> I'd like to establish some kind of convention for naming
> path/directory-related environment variables in Qt, with the hope
> that it could be set in stone with e.g. one of these newfangled
> QUIPs. [...] So, can we all agree on using "PATH" when naming
> environment variables that refer to paths?

I believe that `FOO_DIR` is typical for variables that name a *single*
directory. For multiple directories, XDG prefers `FOO_DIRS`, but
otherwise `FOO_PATH` seems most common.

Examples:
 PATH (duh)
 LD_LIBRARY_PATH
 PYTHONPATH
 LUA_PATH
 QT_PLUGIN_PATH
 LIBPATH
 COMPILER_PATH
 LIBRARY_PATH
 CPATH
 C_INCLUDE_PATH
 CPLUS_INCLUDE_PATH

 TMPDIR
 KDEDIRS
 XDG_DATA_DIRS
 XDG_RUNTIME_DIR

I think a good rule would be single directories should use _DIR if
anything (some cases e.g. HOME may be exceptions), and list of
directories should use _PATH.

Please don't use `FOO_FOLDER` :-).

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Naming of path/directory-related environment variables in Qt

[Mitch Curtis]

> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Christian Kandeler
> Sent: Friday, 11 November 2016 4:42 PM
> To: development@qt-project.org
> Subject: Re: [Development] Naming of path/directory-related environment
> variables in Qt
> 
> On 11/11/2016 04:13 PM, Mitch Curtis wrote:
> > I'd like to establish some kind of convention for naming path/directory-
> related environment variables in Qt, with the hope that it could be set in
> stone with e.g. one of these newfangled QUIPs.
> >
> > Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual Keyboard,
> where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER
> environment variable:
> >
> > https://codereview.qt-project.org/#/c/174616/
> >
> > I then asked Gordan to change this to
> QT_VIRTUALKEYBOARD_LAYOUTS_DIR, as it seemed we had a few other
> environment variables using this naming scheme.
> >
> > JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to
> Qt Quick Controls 2:
> >
> > https://codereview.qt-project.org/#/c/176512/
> >
> > He found more examples of where we've used "PATH" than where we
> used "DIR", so it seems like a good time to continue with that trend so that
> we don't have any more inconsistencies.
> >
> > My hope is that enough approvers see this email (or QUIP) and its
> conclusion (whatever it may be) and -1 patches that go against the
> convention.
> >
> > So, can we all agree on using "PATH" when naming environment variables
> that refer to paths?
> 
> But note that "path" is more generic than "dir": A "file path" is not
> (necessarily) a directory. So the latter name conveys more information to me
> as a user.

I agree, and that's something I thought of too, but then I thought about PATH 
in Windows and it didn't seem so strange.

> 
> Christian
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Naming of path/directory-related environment variables in Qt

[Edward Welbourne]

Mitch Curtis gave examples and proposed a convention:
> I'd like to establish some kind of convention for naming
> path/directory-related environment variables in Qt, with the hope that
> it could be set in stone with e.g. one of these newfangled QUIPs.
>
> Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual
> Keyboard, where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER
> environment variable:
>
> https://codereview.qt-project.org/#/c/174616/
>
> I then asked Gordan to change this to QT_VIRTUALKEYBOARD_LAYOUTS_DIR,
> as it seemed we had a few other environment variables using this
> naming scheme.
>
> JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to Qt
> Quick Controls 2:
>
> https://codereview.qt-project.org/#/c/176512/
>
> He found more examples of where we've used "PATH" than where we used
> "DIR", so it seems like a good time to continue with that trend so
> that we don't have any more inconsistencies.
>
> My hope is that enough approvers see this email (or QUIP) and its
> conclusion (whatever it may be) and -1 patches that go against the
> convention.
>
> So, can we all agree on using "PATH" when naming environment variables
> that refer to paths?

PATH is also used to indicate a *list* of directory names.  Given its
other meaning (below), however, it might be better to identify such
lists by environment variables ending in DIRS to make clear they're
plural and that each entry is a directory.

When used to identify just one thing on the file system, PATH is
generic: it applies as much to single files as to directories, where DIR
is quite specific about applying only to a directory (or folder, or
whatever else these get called on diverse systems).  There is some value
to being able to distinguish "this variable names a directory" (not
uncommonly: one in which we'll scan for paths of diverse other things)
from "this is where that thing is found" (e.g. a config file or style
sheet).

Is it worth retaining such a distinction between PATH and DIR ?
To what extent do the existing names conform to such a difference ?

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Naming of path/directory-related environment variables in Qt

[Christian Kandeler]

On 11/11/2016 04:13 PM, Mitch Curtis wrote:
> I'd like to establish some kind of convention for naming 
> path/directory-related environment variables in Qt, with the hope that it 
> could be set in stone with e.g. one of these newfangled QUIPs.
> 
> Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual Keyboard, 
> where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER environment 
> variable:
> 
> https://codereview.qt-project.org/#/c/174616/
> 
> I then asked Gordan to change this to QT_VIRTUALKEYBOARD_LAYOUTS_DIR, as it 
> seemed we had a few other environment variables using this naming scheme.
> 
> JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to Qt Quick 
> Controls 2:
> 
> https://codereview.qt-project.org/#/c/176512/
> 
> He found more examples of where we've used "PATH" than where we used "DIR", 
> so it seems like a good time to continue with that trend so that we don't 
> have any more inconsistencies.
> 
> My hope is that enough approvers see this email (or QUIP) and its conclusion 
> (whatever it may be) and -1 patches that go against the convention.
> 
> So, can we all agree on using "PATH" when naming environment variables that 
> refer to paths?

But note that "path" is more generic than "dir": A "file path" is not
(necessarily) a directory. So the latter name conveys more information
to me as a user.


Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Naming of path/directory-related environment variables in Qt

[Mitch Curtis]

I'd like to establish some kind of convention for naming path/directory-related 
environment variables in Qt, with the hope that it could be set in stone with 
e.g. one of these newfangled QUIPs.

Pelagicore (via Gordan) kindly contributed a patch to Qt Virtual Keyboard, 
where they introduced a QT_VIRTUALKEYBOARD_LAYOUTS_FOLDER environment variable:

https://codereview.qt-project.org/#/c/174616/

I then asked Gordan to change this to QT_VIRTUALKEYBOARD_LAYOUTS_DIR, as it 
seemed we had a few other environment variables using this naming scheme.

JP then pushed a patch that adds QT_QUICK_CONTROLS_STYLE_PATH to Qt Quick 
Controls 2:

https://codereview.qt-project.org/#/c/176512/

He found more examples of where we've used "PATH" than where we used "DIR", so 
it seems like a good time to continue with that trend so that we don't have any 
more inconsistencies.

My hope is that enough approvers see this email (or QUIP) and its conclusion 
(whatever it may be) and -1 patches that go against the convention.

So, can we all agree on using "PATH" when naming environment variables that 
refer to paths?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Change file process & improvement proposal

[Edward Welbourne]

On Thu, Nov 10, 2016 at 12:38:41PM +, Jani Heikkinen wrote:
>> Lately it has been quite hard to get change files done for the releases.
and Ossi replied:
> oh, it's that time of the year again. :D

Speaking of which, it's also hard to get API reviews done, even though
they are now much easier (because they get represented properly as
gerrit reviews that show the change properly).  See recent mail: of 17
modules with API reviews, one has a +2 and one a +1 on the latest PS;
one has +1 on the previous; two are new reviews (I may have lost an
earlier review) with no comments; three have comments on earlier PSs;
qtwebengine's team concocted a better review (that's rather out of date)
and have reviewed it; qtserialbus's maintainers note the need for a full
API review; but seven add-on modules have had no comments.  (Three of
these were new in 5.7; the rest have been add-ons since at least 5.6.)

Gerrit's diffs between patch sets work for you here: if you've reviewed
an earlier patch set, you can review the change since in the usual
useful way.  No rebasing has happened.

Please review (changelogs and) changes to your module APIs,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

On 10/11/16 14:21, "Development on behalf of Jędrzej Nowacki" 
 wrote:

On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote:
> the easiest would be going with the normal approval rights, but limit
> the submit button to a "QUIP owners" group which would consist of lars
> (and possibly a _few_ deputies).

Considering expected traffic there it could be only Lars :-)

Let's do it that way for now. We can always nominate additional QUIP owners 
later on if we think it's required.

Cheers,
Lars

 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuickControls for desktop: what's the plan?

[Eike Hein]

On 11/11/2016 05:02 PM, Alberto Mardegan wrote:
> If QStyle is used by QWidgets, which have been used in apps since well
> before QML existed, it's reasonable to expect that its performance is
> more than acceptable for modern desktop machines.

Not necessarily. This isn't about native QStyle painting, it's about
QStyle going through Qt Quick's rendering stack, which involves
additional indirection.


> Maybe we might have to give up on the idea of a single implementation,
> and instead have a different style for each toolkit? At least with Gtk,
> it might be possible to use native Gtk widgets, as we are already using
> the glib mainloop in Linux, and GtkWidgets allow for offscreen drawing...
> That sounds like a lot of work :-)

That's more or less what QGtkStyle does.


> Ciao,
>   Alberto

Cheers,
Eike
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuickControls for desktop: what's the plan?

[Alberto Mardegan]

On 10/11/2016 11:55, Frederik Gladhorn wrote:
> The last gap are Linux styles. The situation with KDE is actually quite 
> interesting, since the platform is QStyle based. We do not believe in QStyle 
> based styles for QQC2 as it stands. They will never have the same performance 
> level of the other styles.

If QStyle is used by QWidgets, which have been used in apps since well
before QML existed, it's reasonable to expect that its performance is
more than acceptable for modern desktop machines.

> Changing QStyle is not exactly trivial either, but 
> maybe we can find a way to make it efficent and share code. Maybe we in the 
> end 
> conclude that it's all too much work and we want to have a QStyle based theme 
> in controls 2, but let's first explore the options. I don't know the code 
> enough to have any kind of opinion at this point and I'd propose people that 
> actually have better insights explore which way makes most sense.

And I've been away from Windows and OS X for so long, that I have no
idea how widgets have evolved there. As I understand, QStyle is for
drawing static elements, but you mentioned that in OSX we now have
widget animations...

Maybe we might have to give up on the idea of a single implementation,
and instead have a different style for each toolkit? At least with Gtk,
it might be possible to use native Gtk widgets, as we are already using
the glib mainloop in Linux, and GtkWidgets allow for offscreen drawing...
That sounds like a lot of work :-)

Ciao,
  Alberto



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development