QtCreator with Kirigami for Subsurface
Hi
My name is Jan Iversen, I am working on the Subsurface project to make
subsurface-mobile have more of the
Features currently only available in our desktop version. This of course means
using more kirigami and QtQuick.2
I would like to use Qt Creator to do big parts of the kirigami qml design,
instead of “guessing” the result, but it doesn’t work.
Currently when I open a qml document, the plugin line:
import org.kde.kirigami 2.2 as Kirigami
Is accepted with no errors
But all Kirigami specific lines like e.g.
Kirigami.ScrollablePage {
Have the error “Unknown component (M00)
I work on a Mac (primarily doing iOS work), and have generated the plugin and
moved org/kde/kirigami to the Qt qml directory,
As well as copied the dylib files to Qt Creator App Frameworks and
plugins/designer
When I start Qt Creator I can see in “About plugins” that it has not found a
designer plugin.
I have also tried to start Qt Creator from the command line with -load
kirigamiplugin, but I get an error message saying it does not exist.
Can you please advice, how I can design the kirigami/qml files using QtCreator.
A big thank for your efforts with kirigami and another thanks for a hopefully
positive answer.
rgds
Jan I.
Ps. I am not subscribed to your ML, so please CC me on responses.
Re: QtCreator with Kirigami for Subsurface
> El 28 may 2018, a las 11:03, Marco Martin escribió:
>
> On Mon, May 28, 2018 at 10:52 AM Marco Martin wrote:
>
> Hi,
> unfortunately Qtcreator tends to be really picky with any 3rd party qml
> module...
> i think you need to have the file plugins.qmltypes somewhere where
> qtcreator understands it (i don't know if is possible for plugins that are
> shipped internally in the project like subsurface does)
> perhaps yoy could try to build and install kirigami with its own cmake as a
> plugin.. and install it right into the qt release that qtcreator is using,
> that should fix at least autocompletion, not sure wether is enough to make
> it available in the designer
Hi
Thanks for your answer. I actually did exactly as you suggest. Ran make, make
and make install in
Kirigami directory. The installs to /usr/local/lib/qml/org/kde/kirigami.2 and I
copied it into the Qt install set.
Your idea with plugin.qmltypes could be the answer, that was not part of
/usr/local/lib/qml/org/kde/kirigami.2
I will experiment a bit and see what I come up with.
rgds
Jan I.
>
> --
> Marco Martin
> On Mon, May 28, 2018 at 10:42 AM wrote:
>
>> Hi
>
>> My name is Jan Iversen, I am working on the Subsurface project to make
> subsurface-mobile have more of the
>> Features currently only available in our desktop version. This of course
> means using more kirigami and QtQuick.2
>
>> I would like to use Qt Creator to do big parts of the kirigami qml
> design, instead of “guessing” the result, but it doesn’t work.
>
>> Currently when I open a qml document, the plugin line:
>
>> import org.kde.kirigami 2.2 as Kirigami
>
>> Is accepted with no errors
>
>> But all Kirigami specific lines like e.g.
>
>> Kirigami.ScrollablePage {
>
>> Have the error “Unknown component (M00)
>
>> I work on a Mac (primarily doing iOS work), and have generated the plugin
> and moved org/kde/kirigami to the Qt qml directory,
>> As well as copied the dylib files to Qt Creator App Frameworks and
> plugins/designer
>
>> When I start Qt Creator I can see in “About plugins” that it has not
> found a designer plugin.
>
>> I have also tried to start Qt Creator from the command line with -load
> kirigamiplugin, but I get an error message saying it does not exist.
>
>> Can you please advice, how I can design the kirigami/qml files using
> QtCreator.
>
>> A big thank for your efforts with kirigami and another thanks for a
> hopefully positive answer.
>> rgds
>> Jan I.
>
>> Ps. I am not subscribed to your ML, so please CC me on responses.
Plasma running on S60 device
Hi, one day I was wondering whether Plasma would run on S60 device. I decided to give it a try and after some hacks to kdelibs and kdebase-workspace: http://www.youtube.com/watch?v=9ni_6qTwj-Y Br, Jani ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma running on S60 device
Current version was made with shortcuts and hacks to get Plasma running and proper installation package does not yet exist. Thus, I wouldn't like to share current code yet. However would like to start "KDE on S60" -project. In addition to KDE running on S60 I would like to see KDE evolving to support touchable UI. Trend seems to be that there will be lots of S60 devices with a proper capacitive touchscreens. By porting KDE to S60 we have a good opportunity to start making KDE touchable and even add features something similar to Microsoft Surface. What should I do to get this project started? Who should I contact? It would really nice if someone could walk me through to get this project up. I guess that S60 port will have webpage of its own http://s60.kde.org like other ports have their own. Eventually this project will be KDE for Symbian but since Symbian Foundation is not yet properly running lets keep it KDE on S60. Finally when we have KDE or parts of it up and running we can start pushing this upstream. I'm sure that not every component is feasible for S60/Symbian but at least Plasma looks very promising. There is no guarantee that that this will ever fly but at least we can try. Few crucial things are missing from S60/Symbian (and I'm sure there are still more) - CMake doesn't support Symbian. We must use QMake for now. - Qt for S60 doesn't support QtDBus. There are few alternatives for this: - Implement QtDBus for S60 (native or use LIW/AIW behind the scenes) - Use S60 LIW/AIW directly - Use upcoming Qt Service Framework if it is feasible - Beg QtSoftware to port QtDBus for S60 My employer Tieto http://www.tieto.com is willing to contribute/sponsor this project. Tieto is among the leading Symbian R&D service providers for OEMs globally with up to 1300 persons in Mobile Devices R&D globally. Br, Jani > On Thursday 04 June 2009, 07:42 Kevin Ottens wrote: > > Excellent, good job! > > Indeed! > > > Anything which could go in upstream KDE? If that can help improve the > > platform I'm all for it. > > Even if we can't push this upstream, it would be really nice if you could > share > the patches. > > Another question: it was kde from trunk (4.3) or 4.2 ? > > Cheers, > > -- > Artur Duque de Souza > OpenBossa Research Labs > INdT - Instituto Nokia de Tecnologia > -- > Blog: http://labs.morpheuz.eng.br/blog/ > GPG: 0xDBEEAAC3 @ wwwkeys.pgp.net > -- > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KMS backlight ABI proposition
On Mon, 20 Feb 2017, Hans de Goede wrote: > On 17-02-17 13:58, Martin Peres wrote: > So 1 and 2 are closely related the problem is that if we expose a > fixed number of steps we need to convert in both directions, and if > userspace tries to increment by doing read, add 1, write and we expose > 1-100 but the hardware has only 4 levels then the read will keep > returning the same value. Note I've fixed bugs like this already so > this is a real problem. As already mentioned in the thread this can be > fixed by caching the last written value on both sides and invalidating > both caches on a new write to one side. I don't think userspace should be doing read-modify-write like this, *unless* the value read is guaranteed to be the same as the last value written. Contrast with the sysfs brightness class interface. RMW should only ever have been done on the "brightness" attribute alone, never using read on "actual_brightness" attribute and write on "brightness". >> The display brightness MUST be a monotonically increasing function of >> the brightness property. > > What does "monotonically increasing" actually mean ? I would prefer > to clearly define that we are talking about perceived brightness here, > for 2 reasons: https://en.wikipedia.org/wiki/Monotonic_function Increase in the property means the same or higher "perceived brightness". > 1) This is what the user actually wants > 2) Some of the x86 firmware interfaces only give us perceived brightness > and no way to get back to any other unit of measire. > >> Brightness property value 1 MUST mean the minimum supported visible >> brightness. >> >> Brightness property value 100 MUST mean the maximum supported >> brightness. >> >> Brightness property value 0 SHOULD mean backlight off or equivalent for >> non-backlight brightness adjustment, typically completely >> black. Brightness property value 0 MUST NOT switch the display or pipe >> off [1]. >> >> If the hardware is not capable of supporting zero brightness, and the >> driver knows this, value 0 MUST be equal to value 1. > > Ok. > >> If the driver does not know whether the hardware is capable of >> supporting zero brightness, the driver SHOULD err on the side of 0 not >> being off rather than 1 meaning off. In this case, value 0 is likely >> different from value 1, and the minimum brightness can only be reached >> via property value 0 [2]. > > I agree, but this needs rewording (I had to read it 3 times). > >> If the brightness gets changed outside of the property interface, >> reading the property value MAY be out of sync with the actual brightness >> [3]. > > This is for when the panel is off ? Otherwise it seems like a bad idea > to me. It means we don't want to go dig through the sysfs class interface to figure out what was written there, and do lossy conversions back to the property (if there's scaling involved). BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
Re: KMS backlight ABI proposition
On Mon, 20 Feb 2017, Daniel Thompson wrote:
>>> === 1) Backlight device interoperability ===
>>>
>>> Since we need to keep backward compatibility of the backlight, we have
>>> to keep the current backlight drivers.
>>>
>>> Here are possible options:
>>>
>>> - Exclusive access: Unregister a backlight device when the drm
>>> brightness property is requested/used;
>>> - Unidirectional access: When writing to the backlight property, update
>>> the backlight device;
>>> - Bi-directional access: Propagate back changes from the backlight
>>> device to the property's value.
>>>
>>> Being bi-directional would be of course the best, but this requires that
>>> both drivers have the same number of steps, otherwise, we may write a
>>> value to the property, but get another one when reading it right after,
>>> due to the non-bijective nature of the transformation.
>
> I don't accept that bi-directional transfer requires the step range to
> be the same. Isn't all that is required is acceptance that both sides
> maintain a copy of the current value in their own number range and that
> if X is written to then Y may change value (i.e. when mapping between
> 0..100 and 0..10 then if 0..100 is at 11 and 0..10 gets 1 written then
> 0..100 is allowed to change to 10).
>
> I'd note also that the mechanisms inside backlight to support
> sysfs_notify would mean *implementing* bi-directional comms isn't too
> bloated even if the two sides used different number ranges.
I question the need and usefulness of bi-directional access, and I
question it being "the best". The end goal is to use the connector
property exclusively, and deprecate the sysfs API. If you choose to use
the connector property, you should steer clear from the sysfs. That's
part of the deal here.
The sysfs will still work as ever, it won't break or regress or go away
anytime soon, but the ABI and contract for the connector property will
be, "if you touch the sysfs while using the connector property, you
might get unexpected results reading back the property".
There *are* going to be subtle bugs with the simultaneous operation, and
I know I don't want to be in the receiving end of those bugs.
Raise your hands, who wants to deal with them? Who thinks it's worth it?
>>> The current ABI proposal has mostly been proposed by Jani Nikula, as a
>>> result of his experience and our discussions.
>>>
>>> It takes the following approach:
>>>
>>> - Fixed number of steps (I think we should change it to expose the same
>>> number of steps)
>
> Fixing a large number of steps over an inflexible (lets say 8 level)
> backlight device creates a new problem. User actions to
> increase/decrease the backlight don't work unless the userspace knows
> the hardware step size...
Many of the ACPI backlight interfaces have a limited number of steps,
such as 8 or 16.
However, at least for i915 native backlight, we might *theoretically*
have, say, 5000 steps. But we might have no clue how many user
perceivable distinct steps there are.
> The 0..100 proposal below will encourage the userspace to implement
> hotkeys that jump by 9 (because 0 is reserved with a special meaning).
> and thus there will be deadspots where the hot key has no effect.
One brainstormed idea was to provide a way to increase/decrease the
brightness by a user perceivable margin or N%, whichever is the bigger
change. I don't think we explored that in depth, or how feasible that is
with the properties. It might not solve everything, but it could solve
one class of problems with expanding a limited hardware range to 0..100.
>>> - Uni-directional: KMS -> backlight
>
> See above.
>
>
>>> - Do not deal yet with 3) and 4): I have ideas, but I have been
>>> procrastinating long-enough to send this email and we already have much
>>> to discuss!
>
> Do any of those ideas involve adding *new* API to provide information to
> userspace to help it correct the curves (e.g. somewhat like ALSA)?
>
> It's not that I object to such an approach but I consider it pointless
> to present fixed range brightness levels if the userspace were to end up
> responsible for curve correction.
One of the ideas we've discussed is having a property to adjust the
curve in kernel. If the driver knows parameters of the backlight, it
could populate the curve with the information it has, but it would allow
the userspace to adjust or replace it. The idea is that the userspace
could then treat the brightness property as linear wrt perceived
brightness. ("Perceived brightness" is kind of vague t
Re: KMS backlight ABI proposition
ote, we should really remember that all brightness is not backlight either.) >> === ABI proposal === >> >> The brightness property MUST have values 0...100 inclusive. >> >> The display brightness MUST be a monotonically increasing function of >> the brightness property. >> >> Brightness property value 1 MUST mean the minimum supported visible >> brightness. >> >> Brightness property value 100 MUST mean the maximum supported >> brightness. >> >> Brightness property value 0 SHOULD mean backlight off or equivalent for >> non-backlight brightness adjustment, typically completely >> black. Brightness property value 0 MUST NOT switch the display or pipe >> off [1]. > > Why special case 0? Couldn't we simply add a second property for the > power? We could for example have a boolean "backlight" property that > userspace can turn "On" or "Off" and a "brightness" property which > controls the backlight brightness. Very few of the backlight class implementations support the bl_power attribute to switch off the backlight. Even if they can be switched off using 0 brightness. Unless we're looking at changing all backlight drivers, the property implementation can only try to use value 0 for backlight off. But we don't know if it's off or minimum or what. Also see below. >> If the hardware is not capable of supporting zero brightness, and the >> driver knows this, value 0 MUST be equal to value 1. >> >> If the driver does not know whether the hardware is capable of >> supporting zero brightness, the driver SHOULD err on the side of 0 not >> being off rather than 1 meaning off. In this case, value 0 is likely >> different from value 1, and the minimum brightness can only be reached >> via property value 0 [2]. > > Yeah, this definition is really complicated. I've been reading it three > times and I'm not sure I fully understand it. =) > > For my understanding, with those e-paper displays, what would be the > difference between brightness 0 and backlight off? Would backlight off > actually turn off the display? So that no "ink" would even be visible? > For panels we typically have enabled and disabled states, where the > disabled state, among other things, also turns off the backlight. So > for panels we do have one more level of abstraction. For e-paper-able > displays we could simply have a full range of brightness values, with > 0 meaning e-paper mode and panel off meaning, well, panel off. > > Alternatively, e-paper mode could be the same as backlight off, since > obviously there is no backlight anymore, in which case there wouldn't be > a need to differentiate the special case for 0. The main goal was to allow for cases where you can't switch off the backlight, or you don't know whether the lowest value is pitch black. As I wrote in [1], we can change the meaning of 0, but we need to take into account it really might mean "off" for some, and "minimum visible" for others. The old sysfs ABI handled this by deferring it all to drivers, and we know the result... this really is an unholy mess. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
Re: KMS backlight ABI proposition
On Wed, 22 Feb 2017, Hans de Goede wrote: > My first thought was that your proposal is reasonable, but on second > thought I foresee trouble here with e.g. the backlight level save / restore > code in systemd still using the sysfs interface, while the desktop > environment has moved on to the property, I believe we really need to > do some sort of bi-directional syncing here ... FWIW I think systemd should have no business changing the backlight. The save/restore should belong in the desktop environments... But I think we could dodge this one by having the initial sysfs value synced back to the property on initialization, but not otherwise. The systemd stuff, IIRC, happens before/after X. >> We can bikeshed the meaning of 0 or -1, I don't mind. The point is, we >> need to define what the drivers should aim for, with the potentially >> limited information they have available, to provide as smooth and >> unified an experience as possible. >> >> One benefit of -1 is that we might get away with adding that as a >> special case later on, if we define 0 properly. And if the drivers know >> they don't support off, they could have range 0..100 instead. > > I really believe that we need to define the ABI as 0 meaning minimal > brightness which keeps the screen readable (which for the epaper > example would be no brightness, but normally would be some minimal > level). We can define anything, but it doesn't mean it makes sense for the drivers or that the drivers can implement it. By your above definition, the right thing for the driver to do in the epaper case is to switch off the backlight at 0, because switching it off completely can save more power than just setting duty cycle to 0. That's the whole point for epaper. And this contradicts with what you say below about backlight on/off being orthogonal. > Yes we do not get this right in some cases, but let at least define > it properly in the ABI. Add a fat disclaimer for all I care that > in some cases the driver is unable to guarantee this, but lets > clearly define what 0 means and then try to get as much drivers > to adhere to that as possible. > > As for -1 meaning turning stuff off, I'm against that, on/off > vs brightness setting really are 2 almost orthogonal controls, > in many cases in hardware they are truely orthogona, with both > an enable pin as well as a pwm input for the brightness level, > and driving the enable low will get the pwm input to effectively > be ignored. I think the crux with the on/off/minimum etc. is to have an ABI that works sensibly also for drivers/hardware that is not able to switch backlight off, or doesn't know whether the minimum is off or not. And we need to have recommendations for drivers on what to do in the imperfect reality. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
