Re: [Interest] Unique - Hardware bound - ID
Just in case, two things I forgot: Many (if not most) computers have several MAC addresses. The laptop I'm writing this on has six network interfaces, four with a hardware address and of those three with an actual MAC: * Ethernet device (built in, fixed MAC, which I did not bother to change) * WLAN device (also built in, no bother at the moment, but I did change it a few months ago to be able to use a misconfigured WLAN) * virtual Localhost adapter (no HW addr) * virtual Teredo adapter (something longish made of zeroes that claims to be a HW addr) * virtual ethernet device (with a random MAC that changes every boot) * depending on loaded kernel drivers: a Firewire network adapter with a longish non-MAC HW addr The same is true of most other hardware, many computers have more than one hard disk, more than one CPU core, etc. Even more devastating: hardware tends to change. I've been known to connect two additional real ethernet cards to my laptop and then add a couple more vitual adapters - just for experimentation. Unfortunately you can't tell which ones are built in, which ones are plugged in and which ones are purely virtual. So: * store all of them and insist that one or two remain * never assume the computer will look the same after a reboot even if it is the same computer * maybe: offer the user to bind to one specific instance * plan ahead for users who lose some piece of hardware (HD crashes, burnt out ethernet cards, change of PC/laptop, etc.) Soft piece of advice: don't assume that you can solve this problem 100%. Others have tried before and all of them failed one way or another. Keep yourself flexible enough to handle unexpected situations outside the software. Konrad On Wednesday 15 May 2013 13:07:05 you wrote: I believe the mac address will suffice. In addition I will probably some other hardware related data and create a hash from it. I emagined there would be a solution for this problem but it semes its not that easy. signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Unique - Hardware bound - ID
Hi, On Thursday 16 May 2013 01:14:40 you wrote: Some discouragement (from personal experience): - often systems have more then 1 network card and do not guarantee that they will return the same MAC addresses even after simple reboot (Windows XP as an example) not even counting different configurations. - I am not sure what Qt uses to receive MAC address , but assuming it uses native API, the same MAC address will be returned for any system which does not have a network card installed (or have it disabled in current configuration) This call uses the native method to return ALL network interfaces (at least those supported by drivers). So systems with more than one interface will return MULTIPLE MACs. Systems without physical interfaces will return only the virtual interfaces (localhost, teredo, etc.) which usually have no MAC or a fake MAC (which will change between boots). Mentioned above should encourage do not rely solely on MAC address for computer identification. And you should never rely on thos identifying properties to stay absolutely the same throughout the lifetime of that computer - allow for some changes. Konrad signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Particles Emitter, emit signal when particle life is expired?
On May 14, 2013, at 9:58 AM, Mark mark...@gmail.com wrote:
On Sun, May 12, 2013 at 2:08 PM, Mark mark...@gmail.com wrote:
Hi,
I'm browsing through the Emitter API while searching for some way to
get notified when a particle is expired.
What i'm having is one emitter that emits 1 particle every 25ms then
one trailemitter that adds a trail to the particle. Now in the main
emitter (with 1 particle every 25 ms) i want to get notified when the
particle dies - which is 625 ms later. How can i do that?
I can probably play with the Timer element, but then i'd need a timer
for every particle which is quite a pain to do in QML in a dynamic
fashion.. I'm actually hoping there is a signal somewhere (or a
onSomething...) that i haven't found yet but can also be used to get
the same result.
If that doesn't exists then i guess i need to make a dynamic timer
element for QML, right?
The ideal thing - for me - to have here is a signal that fires with
the X and Y position where the particle expired.
Regards,
Mark
Anyone?
Tracking each individual particle is not really in line with the concept of a
particle systems as they are typically set up as fire-and-forget to be as cheap
and fast as possible.
However, there might be way that works for you, granted that you don't have too
many particles live at the same time.
If you use the ItemParticle, you can specify a delegate for it. This delegate
can be a normal Image {} item, and will be a lot slower (probably in the range
100-1000x worse) than plain a ImageParticle, but you can then track it using
the onVisibleChanged signal. When the item is visible, it is alive and when
it is hidden its lifespan has ended.
cheers,
Gunnar
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt Sensors, can it support CPU, GPU and HDD sensors as well?
Hi Matt, On Tuesday 14 May 2013 10:54:46 Mark wrote: While looking through the Qt Sensors docs i find that to be very much focused on mobile device sensors as in phones, tablets and everything in between. Yep, that has indeed between the primary and only use-case for QtSensors so far. However, the ancient old sensors of HDD, GPU and CPU seem nowhere to be found. Can the Qt Sensor package add support for that? Adding new sensors is quite possible, adding a QHeatSensor with an associated sensor backend would certainly be technically feasible. This could even be done outside of the official QtSensors, as all the API for that is public (well, except adding new QML types, but then, you can export the QSensor subclass instance directly to QML as well). Is it even suitable to add support for that? I'm asking because even the abstract base class QSensor [1] is quite focused on mobile devices considering the *orientation properties. Right, I am not sure if these kind of sensors would fit very well. Technically it would certainly be possible. Maybe Lorn Potter, the maintainer, can answer about the vision of QtSensors and what type of sensors it should encompass. Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QTabWidget Vertical writing
I want to have the QTabWidget vertically...Mean they should vertical and Tab1 Tab2 text should also be vertical. How can we achieve this. Any help is highly appreciated. Thanks -- Thanks Regards Sujan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTabWidget Vertical writing
Le 16/05/2013 11:47, Sujan Dasmahapatra a écrit : I want to have the QTabWidget vertically...Mean they should vertical and Tab1 Tab2 text should also be vertical. How can we achieve this. Any help is highly appreciated. Thanks Have a look at QTabWidget::TabPosition and QTabWidget::setTabPosition. Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTabWidget Vertical writing
Can the tabText be vertical with QTabWidget::setTabPosition(). I need the TabText to be vertical. On Thu, May 16, 2013 at 5:54 PM, Yves Bailly yves.bai...@sescoi.fr wrote: Le 16/05/2013 11:47, Sujan Dasmahapatra a écrit : I want to have the QTabWidget vertically...Mean they should vertical and Tab1 Tab2 text should also be vertical. How can we achieve this. Any help is highly appreciated. Thanks Have a look at QTabWidget::TabPosition and QTabWidget::setTabPosition. Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest -- Thanks Regards Sujan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTabWidget Vertical writing
On Thursday 16 May 2013 11:56:59 Sujan Dasmahapatra wrote: Can the tabText be vertical with QTabWidget::setTabPosition(). I need the TabText to be vertical. For QTabWidget::West and QTabWidget::East, the tab's title text is drwan vertically, for North and South it's drawn horizontally. Be aware though that any cornerWidget() (if applicable) will only be shown when the tabPosition is North or South! HTH, René ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] How to know QSharedMemory maximum system allowed size
Hi all, I'm using QSharedMemory to share data between different processes. I found out that there is a limit to the maximum size a shared memory segment can be. On Mac OS for example the QSharedMemory::create returned an error like system-imposed size restrictions. Is there a way programmatically to know which is the maximum size the system allows for the QSharedMemory, in order to adopt proper data splitting policies depending on it? Thank you very much for your help. Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Unique - Hardware bound - ID
On 15 May 2013, at 12:52 PM, Konrad Rosenbaum wrote: Some words of caution: MAC addresses can be changed in software. Depending on your paranoia level you may not want to rely on them - in that case you may want to think about hardware dongles to secure your app. You could maybe try to use the TPM, but its existence is not universal (and also unpopular). http://en.wikipedia.org/wiki/Trusted_Platform_Module ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QTabWidget Vertical writing
Thanks Rene let me try this On Thu, May 16, 2013 at 3:31 PM, R. Reucher rene.reuc...@batcom-it.netwrote: ** On Thursday 16 May 2013 11:56:59 Sujan Dasmahapatra wrote: Can the tabText be vertical with QTabWidget::setTabPosition(). I need the TabText to be vertical. For QTabWidget::West and QTabWidget::East, the tab's title text is drwan vertically, for North and South it's drawn horizontally. Be aware though that any cornerWidget() (if applicable) will only be shown when the tabPosition is North or South! HTH, René ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest -- Thanks Regards Sujan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Particles Emitter, emit signal when particle life is expired?
On Thu, May 16, 2013 at 9:37 AM, Sletta Gunnar gunnar.sle...@digia.com wrote:
On May 14, 2013, at 9:58 AM, Mark mark...@gmail.com wrote:
On Sun, May 12, 2013 at 2:08 PM, Mark mark...@gmail.com wrote:
Hi,
I'm browsing through the Emitter API while searching for some way to
get notified when a particle is expired.
What i'm having is one emitter that emits 1 particle every 25ms then
one trailemitter that adds a trail to the particle. Now in the main
emitter (with 1 particle every 25 ms) i want to get notified when the
particle dies - which is 625 ms later. How can i do that?
I can probably play with the Timer element, but then i'd need a timer
for every particle which is quite a pain to do in QML in a dynamic
fashion.. I'm actually hoping there is a signal somewhere (or a
onSomething...) that i haven't found yet but can also be used to get
the same result.
If that doesn't exists then i guess i need to make a dynamic timer
element for QML, right?
The ideal thing - for me - to have here is a signal that fires with
the X and Y position where the particle expired.
Regards,
Mark
Anyone?
Tracking each individual particle is not really in line with the concept of a
particle systems as they are typically set up as fire-and-forget to be as
cheap and fast as possible.
However, there might be way that works for you, granted that you don't have
too many particles live at the same time.
If you use the ItemParticle, you can specify a delegate for it. This delegate
can be a normal Image {} item, and will be a lot slower (probably in the
range 100-1000x worse) than plain a ImageParticle, but you can then track it
using the onVisibleChanged signal. When the item is visible, it is alive
and when it is hidden its lifespan has ended.
cheers,
Gunnar
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Hi Gunnar,
That sounds like a possible but painful solution..
I actually think i'm going for a different route: making my own custom
timer component from C++.
What i need is this:
1st particle gets emitted and dies 625ms later
2nd particle gets emitted which could be directly after the first one
as in 1 ms later or be one minute later. I simply don't know since
that's depending in the input. For the timer signals this matters. I
sadly can't easily use the Timer() component since that would mean one
separate Timer{} for every particle.
So i guess i have to make my own custom timer component.. If you have
another better idea that isn't as performance impacting as
ItemParticle, please do tell :)
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Corner Widget not visible
I have set a QTabWidget on QMainWindow .ui. And then in main function setting a corner widget a QPushButton as below QPushButton *button = new QPushButton(AddPage,this); button-setGeometry(0,0,120,20); ui-setupUi(this); ui-tabWidget-setCornerWidget(button,Qt::TopRightCorner); button-show(); But My PushButton is not visible. Whats going wrong in this. Any help is appreciated. Thanks -- Thanks Regards Sujan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtQuick Controls: custom styling
Is this expected? Is custom styling not a supported feature? Did some more digging, it looks like I should now be extending from the specific control's style, which works fine. However, there are some styles that do not exist in the qmldir. Is that on purpose for specific styles, or should all the styles exist in the qmldir? (The specific ones I've noticed are ToolBarStyle and ToolButtonStyle). Josh ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtQuick Controls: custom styling
On May 16, 2013, at 11:44 PM, Josh Faust jfa...@suitabletech.com wrote: Is this expected? Is custom styling not a supported feature? Did some more digging, it looks like I should now be extending from the specific control's style, which works fine. However, there are some styles that do not exist in the qmldir. Is that on purpose for specific styles, or should all the styles exist in the qmldir? (The specific ones I've noticed are ToolBarStyle and ToolButtonStyle). Yes. Not everything will be style capable in the first release. But keep in mind that ToolButton is pretty much simply a custom styled Button, so there is not much point in exposing it when you can simply use a custom styled Button instead. The ToolBarStyle and StatusBarStyle is also currently not needed in the public API since you can anyway use a custom QML item in their place. Jens ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QtQuick Controls: custom styling
Yes. Not everything will be style capable in the first release. But keep in mind that ToolButton is pretty much simply a custom styled Button, so there is not much point in exposing it when you can simply use a custom styled Button instead. The ToolBarStyle and StatusBarStyle is also currently not needed in the public API since you can anyway use a custom QML item in their place. Yes, it was ToolButtonStyle that I was missing, I just happened to notice ToolBarStyle at the same time. You're right that there's no reason it can't just be a Button. Thanks! Josh ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Q_PROPERTY notification across processes?
I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5). WHAT I WANT: I would like to instantiate an instance of this class in each of two processes, where changes in one notifies the other (in the other process). This is logically something like local-instance-reflection to a remote instance in a remote process. (I could create a second class-type if needed, but current implementation suggests I could instantiate the same class type on each side.) My current thoughts are to use a socket between the two processes, where the objects agree on a unique identifier that represents that reflected-instance in each process. Then, the implementation would trigger onChange operations in the remote-instance from property-changes in the local-instance. There would be many of these reflecting-pairs. This implementation-plumbing would probably be through some C++ implemented dispatcher, where one would be instantiated in each process, and be responsible for the serialization for state-changes/notifications between the processes (read/write), and routing the notification to the object in the local process. A concern I have is that there will be *many* of these pairs (thousands, possibly tens-of-thousands), and I don't know if the approach would scale-well for lots of notifications. Does this design seem reasonable? Do you have thoughts on an alternative? It seems like the Q_PROPERTY notification through QML would be an interesting mechanism to enable this generic-cross-process event-based-synchronization. I can't use shared memory, as these processes will typically be on different machines. --charley ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Increase width of tab in QTabWidget
how can I incraese width of tab in QTabWidget?. Is it possible. Any suggestion is appreciated. -- Thanks Regards Sujan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Increase width of tab in QTabWidget
You may create your own style. example can be found at: http://harmattan-dev.nokia.com/docs/library/html/qt4/stylesheet-examples.html#customizing-qtabwidget-and-qtabbar You can specify left and right margins or minimum width for example. Regards, Alex On Thu, May 16, 2013 at 7:02 PM, Sujan Dasmahapatra sujan.dasmahapa...@gmail.com wrote: how can I incraese width of tab in QTabWidget?. Is it possible. Any suggestion is appreciated. -- Thanks Regards Sujan ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q_PROPERTY notification across processes?
If these processes will be on different systems, then I doubt that you have any choice. :-) On May 17, 2013 5:27 AM, Charley Bay charleyb...@gmail.com wrote: I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5). WHAT I WANT: I would like to instantiate an instance of this class in each of two processes, where changes in one notifies the other (in the other process). This is logically something like local-instance-reflection to a remote instance in a remote process. (I could create a second class-type if needed, but current implementation suggests I could instantiate the same class type on each side.) My current thoughts are to use a socket between the two processes, where the objects agree on a unique identifier that represents that reflected-instance in each process. Then, the implementation would trigger onChange operations in the remote-instance from property-changes in the local-instance. There would be many of these reflecting-pairs. This implementation-plumbing would probably be through some C++ implemented dispatcher, where one would be instantiated in each process, and be responsible for the serialization for state-changes/notifications between the processes (read/write), and routing the notification to the object in the local process. A concern I have is that there will be *many* of these pairs (thousands, possibly tens-of-thousands), and I don't know if the approach would scale-well for lots of notifications. Does this design seem reasonable? Do you have thoughts on an alternative? It seems like the Q_PROPERTY notification through QML would be an interesting mechanism to enable this generic-cross-process event-based-synchronization. I can't use shared memory, as these processes will typically be on different machines. --charley ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q_PROPERTY notification across processes?
Hi Charley, You didn't say which type of systems this will be running on? What about QtDBus using a direct connection between the applications, instead of the system-wide bus? Even if that doesn't work for you, it has solved many of the same problems, and needed over 20,000 lines of code! Regards, Tony From: interest-bounces+tony=rightsoft.com...@qt-project.org [mailto:interest-bounces+tony=rightsoft.com...@qt-project.org] On Behalf Of Charley Bay Sent: Friday, 17 May 2013 11:27 AM To: Qt Interest Subject: [Interest] Q_PROPERTY notification across processes? I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5). WHAT I WANT: I would like to instantiate an instance of this class in each of two processes, where changes in one notifies the other (in the other process). This is logically something like local-instance-reflection to a remote instance in a remote process. (I could create a second class-type if needed, but current implementation suggests I could instantiate the same class type on each side.) My current thoughts are to use a socket between the two processes, where the objects agree on a unique identifier that represents that reflected-instance in each process. Then, the implementation would trigger onChange operations in the remote-instance from property-changes in the local-instance. There would be many of these reflecting-pairs. This implementation-plumbing would probably be through some C++ implemented dispatcher, where one would be instantiated in each process, and be responsible for the serialization for state-changes/notifications between the processes (read/write), and routing the notification to the object in the local process. A concern I have is that there will be *many* of these pairs (thousands, possibly tens-of-thousands), and I don't know if the approach would scale-well for lots of notifications. Does this design seem reasonable? Do you have thoughts on an alternative? It seems like the Q_PROPERTY notification through QML would be an interesting mechanism to enable this generic-cross-process event-based-synchronization. I can't use shared memory, as these processes will typically be on different machines. --charley ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Q_PROPERTY notification across processes?
Charley said that in most cases his applications will be run on different computers, so D-Bus won't help him since it doesn't work over network. On May 17, 2013 8:01 AM, Tony Rietwyk t...@rightsoft.com.au wrote: Hi Charley, ** ** You didn't say which type of systems this will be running on? ** ** What about QtDBus using a direct connection between the applications, instead of the system-wide bus? ** ** Even if that doesn't work for you, it has solved many of the same problems, and needed over 20,000 lines of code! ** ** Regards, ** ** Tony ** ** ** ** *From:* interest-bounces+tony=rightsoft.com...@qt-project.org [mailto: interest-bounces+tony=rightsoft.com...@qt-project.org] *On Behalf Of *Charley Bay *Sent:* Friday, 17 May 2013 11:27 AM *To:* Qt Interest *Subject:* [Interest] Q_PROPERTY notification across processes? ** ** I have a C++ QObject-derived class that exposes properties for use in QML, works fine (Qt5). ** ** WHAT I WANT: ** ** I would like to instantiate an instance of this class in each of two processes, where changes in one notifies the other (in the other process). This is logically something like local-instance-reflection to a remote instance in a remote process. ** ** (I could create a second class-type if needed, but current implementation suggests I could instantiate the same class type on each side.) ** ** My current thoughts are to use a socket between the two processes, where the objects agree on a unique identifier that represents that reflected-instance in each process. Then, the implementation would trigger onChange operations in the remote-instance from property-changes in the local-instance. There would be many of these reflecting-pairs.** ** ** ** This implementation-plumbing would probably be through some C++ implemented dispatcher, where one would be instantiated in each process, and be responsible for the serialization for state-changes/notifications between the processes (read/write), and routing the notification to the object in the local process. ** ** A concern I have is that there will be *many* of these pairs (thousands, possibly tens-of-thousands), and I don't know if the approach would scale-well for lots of notifications. ** ** Does this design seem reasonable? ** ** Do you have thoughts on an alternative? ** ** It seems like the Q_PROPERTY notification through QML would be an interesting mechanism to enable this generic-cross-process event-based-synchronization. ** ** I can't use shared memory, as these processes will typically be on different machines. ** ** --charley ** ** ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
