On 13 Nov 2014, at 01:12, Thiago Macieira <thiago.macie...@intel.com> wrote:
> On Wednesday 12 November 2014 23:10:49 René J.V. Bertin wrote: >> On Wednesday November 12 2014 12:46:02 Thiago Macieira wrote: >>> 1) application self-containing: we don't want to open files we shouldn't, >>> especially on more locked-down platforms like OS X >> >> ?? Why would Qt (apps) not be able to open Qt configuration files? Thank >> goodness OS X hasn't yet become like iOS where indeed it would be >> complicated to have shared, global configuration settings. > > OS X itself is not the problem. The "Mac Store" is. One of the issues people > had in sending Qt4-based applications to the Mac Store was the fact that it > read from and wrote to a global Trolltech.conf file. > > So that is gone. Is this distinction between global and application-specific just a directory-based restriction? Because obviously an application can still load its own config files, right? So a style or theme could load from an application-specific config file, if it exists; and the user would be free to make that file a symlink instead, to centralize the settings. >> I'm a bit surprised to see disk access among the arguments, in a time where >> the first reaction to complaints about that are met with "get an SSD" ... >> We're talking about configuration parameters that are read exactly once >> when the application is starting up; that storage access must be completely >> drowned in the rest of the activity going on at that time. > > The time it takes to open a file and parse it, however small, is higher than > the time it takes to do nothing. The problem is not one specific task that is > done, it's the fact that we have a lot of those tasks and they add up. We do a lot of things that add up. IMO we need to really focus on better efficiency (both memory and time) in general, because running Creator and KDE 5 on a 64-bit Linux machine with 4 GB is already kindof impractical; and if you don’t have an SSD, the startup time isn’t very nice either. QtQuick isn’t helping with that, perhaps because of all the runtime parsing, but certainly because of the sheer number of objects created on several layers. Reading a config file is potentially pretty trivial compared to parsing tens or hundreds of QML files, depending on how the two parsers compare. But now there is a movement to use JSON for settings instead of the INI format, so maybe it will end up being even faster if we go that way. > I don't now if the Creator team intended to be different or not. You'll have > to > take this up with them. If they did not intend to be different, then you've > found bugs and they should be fixed. Creator has a lot of custom UI. To really look like a native Mac app I suppose it should have a native toolbar at the top instead of having bars on 3 sides, no custom colors, etc. And then it would be a matter of argument whether that is an improvement. All 4 edges of the application are valuable real estate, especially in fullscreen mode (Fitts’s Law), not just the top edge. Those of us who work on multiple platforms appreciate that we don’t have to change our habits much when switching between OSes. It’s the kind of application that you spend a lot of time with, so it’s more important that it be efficient for long-time users to spend hours with every day, than to immediately look familiar to a new user. I don’t actually like the experience with Xcode nearly as much as Creator. So Creator is not the example of an application that needs to have a native look and feel, IMO. If you create something very simple and typical (like qtquickcontrols/examples/quick/controls/texteditor), that should look as native as possible. (Of course it’s not quite there yet either.) But there are plenty of other Mac apps that don’t look quite native, or have custom skins on purpose. Chrome, Firefox, Spotify and so on, and even many of Apple’s applications in the past. Creator in the future seems to be going towards themeability (patches for that are already committed on master branch). Given that it has such a “special" appearance, IMO it’s good that the user has the ability to customize it further for personal taste. So far it doesn’t go as far as being able to set all the fonts in the whole application: just the colors, plus a couple of fonts that you’ve already been able to set for a long time. Some fonts still come from the platform theme. >>> Anyway, the majority opinion is that Qt should look like the OS's own >>> look- >>> and-feel. >> >> We're talking about giving choice, not about taking it away, but I'd like to >> see stats on that :) And also on what percentage thinks that user choice is >> even more important. And how many would actually prefer it if their >> application suite would look and feel the same regardless of what platform >> it runs on and use Qt in an attempt to achieve that. > > Oh, there are lots of those. But Qt and especially QtWidgets were meant to > make native look and feel with cross-platform code. Being able to support > your > UX is an aside, not the main goal. If you want to do your own UX, you have Qt > Quick -- just don't use Qt Quick Controls, and have absolute control over > your > UI. But Controls has the goal of looking native by default too. When it doesn’t look native, that’s a bug. But you can also tweak the styles of controls when you want to deviate from the native look. (And having a separate style object for each control adds to the efficiency cost.) IMO the ideal is that developers and users should both have as much choice as possible, even if the means of doing the tweaks is not so accessible (having a preferences dialog with every possible setting would in the limit take too much code and add too much clutter, although it’s not bad when it can be kept simple enough, and when the settings are really worth tweaking, as in Creator). But it shouldn’t cost as much as it does in memory and load time and scrolling/flicking speed. >> Setting a default style is almost feasible on OS X by making the bundle >> executable a shell script that calls the binary with a style choice. Same >> cannot be said about the default font, though. > > Agreed, the -style option should be removed, along with most options that Qt > applications take on the command-line. Those are options for the application > developer to use when writing the application, not meant to be used in > production or, worse, be used by the user. Command-line switches are buried deep enough in Mac application bundles that there is no risk of someone who doesn’t know what he’s doing getting confused by them. So the only question is how much efficiency we could gain by removing them from “release” builds of applications. >> Anyway, don't you think it could at least be possible to set such >> configuration choices per application so they become persistent across >> restarts? > > You have access to QSettings. Use it. It is wasteful for every application in the world to have its own skin, or even color and font settings. And IMO it is also too rigid for the OS to impose them and not allow tweaking, like OS X does, but yeah you can choose another OS. Another thing I dislike is that the Fusion style has hard-coded colors (a QPalette). The Fusion style is the default on Linux if one runs a plain X11 session without any desktop environment. (If you want to minimize memory use, that’s the way to go.) Most people don’t do that, so usually a platform theme will override those colors anyway, but I would like the fusion style to be more configurable because it’s the one I’m seeing in Qt apps most of the time. It could use X resources, but that’s not very portable (not even to Wayland). The reason it’s not configurable is exactly that Trolltech.conf has gone away, right? But there should be an efficient way to get the configurability back. So in this case we are only talking about one style, not every Qt app on every platform, and not on any platform that has App Store restrictions. _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
