Re: [Interest] Change QCheckBox to QPushButton in a QTableView

[André Somers]

Op 07/12/2017 om 00:21 schreef Jason H:
> I have a model, a few columns of which are supposed to be QPushButtons. 
> I've got it working with checkboxes just fine, and I can get the QPushButtons 
> to display while editing. 
> But I want to display the checkable QPushButton reflecting it's checked state 
> to be displayed all the time, not just when editing.
>
> I looked at the stars delegate example, but that's got some rudimentary 
> painting. 
> I found the ProgressBar example in QAbstractItemDelegate, but that didn't worl
>
> void ButtonDelegate::paint(QPainter *painter, const QStyleOptionViewItem 
> , const QModelIndex ) const {
>   if (index.column() == 0) {
>   QStyleOptionButton button;
>   button.text = _text;
>   QApplication::style()->drawControl(QStyle::CE_PushButton, 
> , painter);
>   } else
>   QStyledItemDelegate::paint(painter, option, index);
> }
>
> QSize ButtonDelegate::sizeHint(const QStyleOptionViewItem , const 
> QModelIndex ) const {
>   return QSize(50,10);
> }
>
> But all I got out of it was a black pixel in the first cell. 

You're going to have to do a proper initialization of the
QStyleOptionButton. At the very least, set the rect it is supposed to be
drawn in. You can copy that information from the QStyleOptionViewItem.
You will need to set the checked state from there as well.

André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] move methods in QList

[André Somers]

std::list cannot be compared to QList, and likely neither data structure
is what you are looking for. QList should, IMO, not be used for new code
if it can be avoided, and is certainly not suitable for using with
anying Big. With big as in: bigger than size of a pointer. And
linked-lists like std::list should not be anyones choice of data
structure unless they have very specific requirements that make such
structures outperform other data structures.

André


Op 10/10/2017 om 08:45 schreef Hamish Moffatt:
> I'm interested in storing a big structure in QList, and I would like
> to move it to the list, but unlike std::list QList does not seem to
> have push_back(T&&), insert(..., T&&) etc.
>
> Should I use std::list instead? Or use a QList of pointers (eg
> QSharedPointer) to my structure? Or construct a default item and move
> my new one over it, as in
>
> Big itemToAppend;
> QList list;
> list.append(Big());
> list.last() = std::move(itemToAppend);
>
> Are there any plans to add the move methods to QList etc?
>
>
> Hamish
>
> ___
> 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] Set QTableWidgetItem checkbox when clicking anywhere on QTableWidget's row

[André Somers]

Op 06/07/2017 om 17:47 schreef Murphy, Sean:
>>> And then with the event filter approach, what would I actually be filtering
>> on? 
>   
>> It's similar to the above, only it solves the same problem at a
>> different location in your code. Instead of modifying a delegate, you'd
>> intercept the mouse click and, again, handle the state change yourself.
>> Indeed the widgetApp isn't going to tell you if you're over the checkbox
>> in the item view as the checkbox there is not a widget but rendered by
>> the delegate directly, but you don't need that info either. All you need
>> to know if the mouse is over a row, and which row. QAbstractItemView can
>> tell you that just fine...
>>
>> In both cases, you simply handle the mouse event yourself, and use
>> setData yourself to toggle the state of the checkbox when there is a
>> click *somewhere* on the row. That's what you were after, right?
> That is what I was after, yes. Just to be clear, in the event filter method, 
> the 
> event filter would intercept the click before it gets to the checkbox 
> correct? 
> And then I would be able to explicitly set the checkbox's state in my handler 
> and avoid the double-toggle that I was experiencing previously? 
That's right. And note, that there is no real checkbox. There is a
rendering of one by the delegate that was set for the given cell. At
least: no widget.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Set QTableWidgetItem checkbox when clicking anywhere on QTableWidget's row

[André Somers]

Hi,


Op 06/07/2017 om 16:07 schreef Murphy, Sean:
> Thanks for the response Andre
>
>> I'd probably handle this via either a custom delegate or by using an
>> event filter.
> Can you go into a little more detail on these two approaches? 
Ok, a little...
>
> As far as the custom delegate approach, I'm assuming that if I follow the 
> Spin Box Delegate Example 
> (http://doc.qt.io/qt-5/qtwidgets-itemviews-spinboxdelegate-example.html) and 
> just replace the spin box with a checkbox that would get me there?
It'd keep it simpler than that. Just create a QStyledItemDelegate
subclass, and reimplement editorEvent to handle the mouse events yourself.

>
> And then with the event filter approach, what would I actually be filtering 
> on? I'm assuming you're suggesting to filter all clicks on the QTableWidget 
> and then trying to detect if it's over a checkbox via cursor position, and 
> then handle the click different based on that? My main sticking point with 
> that is that a checkable QTableWidgetItem doesn't seem to be an actual 
> QWidget, so I'm something like qApp->widgetAt(QCursor::pos()) isn't going to 
> tell me whether I'm over the checkbox, it's going to tell me I'm over the 
> QTableWidget, right? So I'm not seeing how I tell whether the mouse was over 
> the check box's pixels or not. Let me know if you meant something else for 
> this approach.
It's similar to the above, only it solves the same problem at a
different location in your code. Instead of modifying a delegate, you'd
intercept the mouse click and, again, handle the state change yourself.
Indeed the widgetApp isn't going to tell you if you're over the checkbox
in the item view as the checkbox there is not a widget but rendered by
the delegate directly, but you don't need that info either. All you need
to know if the mouse is over a row, and which row. QAbstractItemView can
tell you that just fine...

In both cases, you simply handle the mouse event yourself, and use
setData yourself to toggle the state of the checkbox when there is a
click *somewhere* on the row. That's what you were after, right?

>> P.S. Oh, and get rid of the QTableWidget. Use QTableView instead.
> What does that do for me in this case? 
Nothing to solve this particular issue. Its just a pet-peeve of mine.
> My table is very simple, it's basically a read-only table EXCEPT for allowing 
> the user to check/uncheck items. Maybe I'm wrong in my ideas, but I tend to 
> view QTableWidget as working pretty nicely for very simple tables like this 
> but with it you get less control than QTableView. I feel like when I've used 
> QTableView for situations like this that it takes more code just to get up 
> and running when compared to creating the QTableWidget. I'm totally willing 
> to change my views on QTableView vs. QTableWidget if you think I'm wrong!
If you must use an item based API, I'd take QStandardItemModel (very
wrong name, but ok...) with a standard item view. It provides a much
better decoupling of the UI aspects and the data aspects of the
application. No need to modify your UI code if you decide your data
should come from a different data source in the future, and no need to
change your data setup if you decide you want a dropdown instead of
table... Also, it makes it easier to introduce things like
QSortFilterProxyModel into the stack later on.

I think the introduction of the *Widget variants of the views was a
mistake that tought Qt users wrong habbits.

André


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Set QTableWidgetItem checkbox when clicking anywhere on QTableWidget's row

[André Somers]

Hi,

I'd probably handle this via either a custom delegate or by using an
event filter.

André

P.S. Oh, and get rid of the QTableWidget. Use QTableView instead.

Op 05/07/2017 om 20:16 schreef Murphy, Sean:
> I've got a QTableWidget that presents data in two columns. The first column 
> is made up of QTableWidgetItems that have the Qt::ItemIsUserCheckable flag 
> enabled. The items in the second column are not checkable. What I'd like to 
> do is allow the user to click anywhere in a given row to toggle that row's 
> checkbox state, so they don't have to only click on the checkbox in column 0 
> itself.
>
> I've created my own slot, connected the QTableWidget::cellClicked(int row, 
> int column) signal to my slot, and take care of programmatically toggling 
> that row's checkbox. This almost works. It is fine EXCEPT when the user 
> actually clicks on a checkbox. In that case the checkbox takes care of 
> toggling itself first, and then my slot comes along and toggles it back to 
> its original state and the checkbox ultimate remains in its original state.
>
> Is there any way for me to detect that a click actually happened on an item's 
> checkbox so that I can just let the checkable QTableWidgetItem do its thing, 
> and skip executing my custom slot? I'm not seeing anything in the 
> documentation that allows me to differentiate the checkbox's text from the 
> checkbox itself (let alone the white space that is inside the 
> QTableWidgetItem's cell - the cell's internal margin). 
>
> The only thing I can think of at the moment is that I bump my table up to 
> three columns, splitting my current column 0 into columns 0 and 1 where:
>  - column 0 contains checkable QTableWidgetItems that have no text
>  - column 1 contains non-checkable QTableWidgetItems that have the text that 
> I current have on my items in my current column 0
>  - column 2 doesn't change from my current column 1
>
> Then in my slot, I'd just ignore clicks that happen in column 0, and toggle 
> the checkbox if the click happened in columns 1 or 2. I think this would 
> leave a small window of pixels that are inside the column 0 cell, but outside 
> the checkbox where a user could click and nothing would happen...
>
> Is there a solution to this that I'm missing?
>
I'd install an event filter on the

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QueuedConnection, QByteArray, reserve, capacity

[André Somers]

Op 01/06/2017 om 23:37 schreef Thiago Macieira:
> On Thursday, 1 June 2017 11:21:14 PDT Yuri Alexandrov wrote:
>> Would be great if such external behavior switch is implemented, something
>> like QByteArray a;
>>
>> a.setAllocationPolicy( .. ), or whatever other proper method name.
> That means every QByteArray would need to store this policy somewhere. That's 
> too much overhead for the 99% case, IMHO.
>
One could make it a policy class like the allocators you can supply in
the std containers, but we're not using that pattern anywhere else in Qt
that I am aware of. That way, the 99% would not pay for it because the
default policy would do and (not) store exactly what is done now. An
exteded policy could allow tweaking this behavior, for instance by never
releasing more than what was explicitly reserved or never automatically
releasing at all.

Downside would be that a QByteArray would not be the same
type as a QByteArray, so assignments and other
operations would not just work between them. Might not be worth the
trouble.

André



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Eclipse plug-in status - QtCreator on KDE Neon

[André Somers]

Op 16/05/2017 om 02:19 schreef Roland Hughes:
> Hello,
>
> Not that I like Eclipse in the least, but, currently have KDE Neon
> 5.8.6 installed and creator from the YABU repos needs different
> (older) version of one or more libraries. Have read that forcing of
> older version of said library causes some serious issues elsewhere in
> the desktop. It will be a while before Neon has a pure Debian back
> end, sooo (yes, stick with it because it is waay faster
> than KUbuntu and more stable.)
>
Why don't you just build QtCreator for source then? You can then compile
it against the Qt version you have on your system. Sounds like way less
hassle than trying to fiddle with getting other IDEs to run.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Licensing PITA

[André Somers]

Op 04/05/2017 om 20:02 schreef Bob Hood:
> I have a legitimate Qt license (just renewed, in fact).  I am trying
> to create a commercial, static build of 5.7.1, and the build output
> keeps coming up with:
>
> Licensee
> License ID..
> Product license.Preview Edition
> Expiry Date.
>
> I have the license contents in the %USERPROFILE% folder under the name
> ".qt-license", as all the documents indicate, but it either will not
> see it, or it is not happy with the contents (copied verbatim from the
> account).
>
> Is there some kind of "debug" option I can provide that will tell me
> why it's blinded to my license?
This sounds like exactly the kind of issue you'd contact your commercial
support for?

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QVectors vs QLists

[André Somers]

Hi,


Op 03/05/2017 om 20:15 schreef Jason H:
>
>> Sent: Wednesday, May 03, 2017 at 1:53 PM
>> From: "Konstantin Shegunov" 
>> To: "Jason H" 
>> Cc: "Qt Project" 
>> Subject: Re: [Interest] QVectors vs QLists
>>
>> I'll throw my 2 cents in, in addition to Sergio's comment on
>> iterator-based traversing.
>>
>> 1) If you don't absolutely need key ordering, I'd suggest a hash table
>> (e.g. QHash) due to the amortized time lookup/insertion. If you use a
>> numerical key for the QMap, I'd definitely consider switching to a
>> hash to offset the cost of the tree rotations, which is also
>> especially useful (I believe) if the value type is copy-heavy.
>>
>> 2) Prefer QVector over QList but not fanatically. If your data's
>> movable (declared as such) and the size of `void *` (e.g. keeping
>> implicitly shared classes' instances) then QList should fare just
>> fine.
>
> Thanks both of you, I am putting effort in to use the classes wisely. Aside 
> fro this keys() thing, I think I'm on point, I only use QMap where I need 
> fast min/max/ordered key lookup, else I'm using QVector. My calls to keys() 
> are few, but they happen on large datasets. 
>
> It sounds like I should just use QLists for keys() until Qt6.
>
Also consider if you need the COW features of the Qt containers, or if
you could do without. If you don't need them, you can probably gain a
speedup if you use the std containers instead. So, perhaps rely on
std::vector instead of QVector, std::unordered_map instead of QHash and
std::map instead of QMap.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] building a light weight tree model

[André Somers]

Hi,


Op 03/05/2017 om 00:18 schreef Frank Rueter | OHUfx:
> Thanks for the tip.
> I don't know C++ so that's not an option, but I can Cythonise and
> compile later.
>
> Actually, I started with a command line app that just printed out a
> report. In my analysis I need to visit every file and directory and
> collect data such as size, file extensions, matches to a user filter etc.
Do you really? Are you sure you need your tree fully expanded? Note that
QFileSystemModel (QFSM) does its population in a lazy way: it does not
iterate over parts of the file system that have not been requested yet
from the model (and it does not monitor for changes in these parts
either). Are you sure you need each and every file and dir's data right
away? Can your user even view that much information?

> Hence it felt natural to collect QStandardItems as I went, rather than
> us QFileSystemModel and then cycle through all items after the fact.
Perhaps you should explain your requirements a bit better. What are you
going to do with the data? What do you need on top of what QFSM already
supplies? You mentioned being able to navigate into zip files? Anything
else?

> I will have a look at doing that though, since you  seem to be in
> agreement that it will be faster.
>
> >>QStandardItemModel is not the API you are looking for
> Can you clarify please? I thought it was one of the simplest models
> and hence I gravitated towards that.
> Should I use QAbstractItemModel instead (unless I end up using
> QFileSystemModel)?
QStandardItemModel is all but the simplest model. It is a very heavy and
complicated one. Its item-based API provides many fields by default, and
also sports virtual methods. You won't need many of these, yet you will
pay the price for them for every cell in your entire model. It is far
more efficient to create a compact data structure that contains just the
data you really need in your case, and expose that via a
QAbstractItemModel (QAIM) derived model directly.

Also on a conceptual level, I think the class is wrong for most usecases
- including yours. It models a collection of independent individual
cells, like a spread sheet where each cell can recursively contain a
child spread sheet again (as is the structure of QAIM). But your data
does not look like that. You are dealing with a forest structure: a
collection of trees of items, containing directories (branches) and
files (leafs). Sure, these items have attributes that you may want to
present in aditional columns in your model, but in essense, the data is
just about files and directories (which also can be thought of as files,
only files containing a list of other files). So, you want your API to
match _that_ concept. You want your API to deal with files, not with a
row of items that really may contain anything.

InsHMO, the naming of this class was a mistake. It should never have
been called "Standard", as that suggests it is the default choice, while
in fact it should almost never be that. And the introdcution of
QListWidget, QTableWidget and QTreeWidget was an even bigger mistake.

André

>
> Cheers,
> frank
>
> On 3/05/17 7:52 AM, André Somers wrote:
>>
>> Hi
>>
>>
>> Op 02/05/2017 om 09:15 schreef Frank Rueter | OHUfx:
>>> I need a few custom views for my data, including representing
>>> collections of files with a certain extension as virtual zip files,
>>> i.e. items that don't actually exist on disk.
>> So, use a proxy model or a model that wraps the original one.
>>> I assumed using QFileSystemModel would not be the most efficient way
>>> to use i this case (based on various comments I read in the past).
>> Eh... If you want to know if your code is efficient, you should not
>> start from assumptions. You should start with measurements and some
>> concrete goals.
>>
>> Other than that, I fully agree with Chris: if you want this to work
>> fast, use C++ and avoid QStandardItemModel, especially for "huge"
>> models. QStandardItemModel is not the API you are looking for (ever,
>> IMHO, with a possible exception for small toy projects).
>>
>> André
>>
>>>
>>>
>>> On 2/05/17 6:25 PM, Ch'Gans wrote:
>>>>
>>>>
>>>> On 2 May 2017 at 17:55, Frank Rueter | OHUfx <fr...@ohufx.com
>>>> <mailto:fr...@ohufx.com>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Here is a snippet of test code to mimic a light weight tree model.
>>>> All it is trying to do is mimic the parenting according to the
>>>> directory structure on disk using QStandardItems in a
>>>> QStandardModel.
>>>> It works, but it took me way longer to figure out than I

Re: [Interest] building a light weight tree model

[André Somers]

Hi


Op 02/05/2017 om 09:15 schreef Frank Rueter | OHUfx:
> I need a few custom views for my data, including representing
> collections of files with a certain extension as virtual zip files,
> i.e. items that don't actually exist on disk.
So, use a proxy model or a model that wraps the original one.
> I assumed using QFileSystemModel would not be the most efficient way
> to use i this case (based on various comments I read in the past).
Eh... If you want to know if your code is efficient, you should not
start from assumptions. You should start with measurements and some
concrete goals.

Other than that, I fully agree with Chris: if you want this to work
fast, use C++ and avoid QStandardItemModel, especially for "huge"
models. QStandardItemModel is not the API you are looking for (ever,
IMHO, with a possible exception for small toy projects).

André

>
>
> On 2/05/17 6:25 PM, Ch'Gans wrote:
>>
>>
>> On 2 May 2017 at 17:55, Frank Rueter | OHUfx > > wrote:
>>
>> Hi all,
>>
>> Here is a snippet of test code to mimic a light weight tree model.
>> All it is trying to do is mimic the parenting according to the
>> directory structure on disk using QStandardItems in a QStandardModel.
>> It works, but it took me way longer to figure out than I
>> expected, and I have a feeling some of you may have good advise
>> on how to make it more efficient.
>> https://pastebin.com/vRkzDPtt
>>
>>
>> What's your definition of "more efficient", what are the problems,
>> what make you think it's not efficient?
>>
>> If you want efficiency, then don't use python and don't use
>> QStandardModel, if you want expediency then use QFileSystemModel.
>>
>> My 2 cents.
>> Chris
>>
>>  
>>
>>
>>
>> I am not using QFileSystemModel as I wanted to keep things as
>> efficient as possible and also need to add some custom items to
>> the model.
>> Also, for the Python programmers: in my actual code I am using
>> scandir.walk() instead of os.walk() for speed.
>>
>> Any input would be greatly appreciated as I will need to run this
>> over disks that have massive amounts of files.
>>
>> Cheers,
>> frank
>>
>>
>> -- 
>>
>> ohufxLogo 50x50    
>>  *vfx compositing  | *workflow
>> customisation and consulting * *
>>  **
>>   
>>  
>>
>> Your gateway to over 1,000 free tools... right inside of Nuke
>> 
>>
>>
>> ___
>> 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

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QMessageBox - Accept/Reject

[André Somers]

> Op 28 apr. 2017 om 20:34 heeft Konstantin Shegunov  het 
> volgende geschreven:
> 
> Hi,
> Employ like this:
> 
> dlg.exec();
> if (dlg.clickedButton() == btn)
>qDebug() << "Yes was clicked";
> 
> However, why not make use of the standard buttons, which already
> include "Yes"/"No"?
Better yet, use a verb that expresses what will happen. Save is also standard, 
but otherwise you should set a text explicitly. Just Yes an No as buttons make 
for a horrible user experience. 

André

> ___
> 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] Align text to top of Text

[André Somers]

Sent from my phone, please excuse my brevity

> On 28 Mar 2017, at 21:14, Shantanu Tushar  wrote:
> 
> Hi Jason,
> 
> Thanks for the quick reply! Have you used the negative topPadding technique 
> in practice? If yes did you use a fixed value or could you calculate it using 
> QFontMetrics?

I have done something similar. I wrapped Text in a surrounding item and aliased 
basically all properties. Then I positioned the Text item inside this 
surrounding TightText item. Now that I think about it, padding might have 
worked too. 

You should calculate the offset. Note that Text allows (parts of) characters to 
be outside of the items box, as long as you don't enable clipping. I used a 
fixed letter to calculate how high the 'normal' characters are and adjusted the 
position accordingly. 

André
> 
> Cheers,
> 
>> On Wed, Mar 29, 2017 at 12:36 AM, Jason Allen  
>> wrote:
>> You are positioning the text and the topmost left edge correctly, but also 
>> consider that depending on a font or character typed, not all characters 
>> take up the full available height.
>> 
>> Characters like ` ' | / \ and " are sometimes above the height of latin 
>> letters, as are capital-case letters with accents like É vs E, Ñ vs N, or U 
>> vs Ü. See below, using your exact code with additional characters. Note that 
>> `, Ü, and Ñ are indeed flush with/touching the topmost edge:
>> 
>> If it's a static label that you're positioning and KNOW won't contain 
>> accents or above-letter-height character, use negative topPadding to nudge 
>> it higher.
>> 
>> If it's dynamic text that may contain an above-letter-height character, 
>> consider leaving it be as-is, or it might clip on the top edge.
>> 
>> I hope this helps!
>> Best regards,
>> Jason
>> 
>> 
>> 
>> Jason Allen  
>> m: 703-868-5306
>> w: www.jasoncaryallen.com
>>
>> 
>>> On Tue, Mar 28, 2017 at 2:51 PM, Shantanu Tushar  wrote:
>>> Hi,
>>> 
>>> I'm trying to align some text in a Text so that it exactly touches the left 
>>> and top edges of the Text item. With the following-
>>> 
>>> Rectangle {
>>> anchors { fill: parent; margins: 5 }
>>> border { width: 1; color: "red" }
>>> 
>>> Text {
>>> anchors.fill: parent
>>> 
>>> topPadding: 0
>>> verticalAlignment: Qt.AlignTop
>>> text: "HELLO WORLD"
>>> }
>>> }
>>> 
>>> I am able to get the following result-
>>> 
>>> 
>>> 
>>> As you can see there is still space between the text and the topmost edge 
>>> of the Text. How do I eliminate this space?
>>> 
>>> Cheers,​
>>> 
>>> -- 
>>> Shantanu Tushar(UTC +0530)
>>> shantanu.io
>>> 
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>> 
>> 
> 
> 
> 
> -- 
> Shantanu Tushar(UTC +0530)
> shantanu.io
> ___
> 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] Requesting QObject::bind() method

[André Somers]

Op 22/03/2017 om 07:49 schreef Thiago Macieira:
> Em terça-feira, 21 de março de 2017, às 22:58:38 PDT, Thiago Macieira 
> escreveu:
>> Em terça-feira, 21 de março de 2017, às 19:38:19 PDT, Prashanth Udupa
>>
>> escreveu:
>>> QSlider *slider = ...
>>> QLabel *label = 
>>> QObject::bind(slider, "value", label, "text”);
>> This is a bad example because "text" is a string and would require a
>> conversion. But let's say we're connecting a slider to a QProgressBar. You
>> can just write:
>>
>> QObject::connect(slider, :valueChanged,
>>  , ::setValue);
> And your other example:
>
>> QSlider *slider = 
>> QLabel *label = 
>> QObject::bind(slider, "value", label, "text", [](const QVariant ) { return
>> v.toInt()*2; });
> Would be:
>
> QObject::connect(slider, ::valueChanged, , [label](int value) { 
>   label->setText(QString::number(value * 2)); 
>   });
>
> But let me put it this way: will not accept new text-based API for signal, 
> slots and properties in QObject. You can do that externally, as you've done 
> it, but I won't take it in QtCore.
>
> So we need the compile-time checking. What can we use to identify the 
> property 
> changing? A read-only property that changes has two C++ identifiers: the 
> getter 
> and the notify signal. And what can we use to identify the receiving 
> property? 
> The getter and the setter.
>
> So this new functionality would be:
>
>   QObject::bind(sender, ::signalName, receiver, ::setter);
>
> This is exactly connect() we already have.
>
That's not quite true. First of all, you are not referencing the getter
in the example above. Then, a ::bind would also initialize the receivers
value to the current value. Qt::connect does not do that. Also, a ::bind
suggests that the connection is exclusive at the receiving end and
setting a new bind will break the old one; a connection explicitly is not.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Forum or mailing list?

[André Somers]

Hi,


Op 21/02/2017 om 06:41 schreef Patrick Stinson:

Qt’ers,

I’m curious, what type of inquiries should go on the Qt-hosted forum, and which 
to this mailing list?

It’s a little hard to tell the difference from the outset.

It's more a matter of what medium you prefer. Some prefer mailing lists, 
some forums. To each their own.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Handling signal-slot connections on demand (sanity check request)

[André Somers]

Hi,


Op 28/01/2017 om 01:33 schreef Forrest Leeson:

Assume an application that creates a focusable dialog with 9 buttons.
Clicking buttons 1-8 causes the creation of new windows — type 1
through type 8, each type supporting a slot, S, that can be connected
to the signal of button 9.

Clicking button 9 should trigger slot S only of the window that was
most recently active. Which is to say the connection can't usefully be
set up when the window is created.

A solution would seem to be to add a look-at-me signal to all the
window types, which they would emit to the dialog upon receiving
focus; the receiver would then [ disconnect(Button9,0,0,0) ] and then
connect Button 9 to the signalling window's slot S by way of
QObject::sender() with a side order of qobject_cast...at which point I
am realize I am stupid and ignorant and have misplaced all my B
vitamins and choline supplements and my coffee is cold and foul.
The documentation warns against using Sender this way, but chides
rather than forbids. Look-at-me signals not arriving in order would be
a dealbreaker, but unless I'm misreading, establishing the connection
with Qt::DirectConnection will fix that. And I guess checking for 0
against the result of the cast will avoid crashing.

So: is this approach even minimally sane, and even if so is there a
(better) way to do it?
Why do you maintain a connection to each of the windows at all? It seem 
to me that it would be much easier keeping track of which of your 
windows 1..8 is active (monitor for the occurance of 
QEvent::WindowActivate in your application via an event filter), and 
then on triggering button 9 simply call the indicated method S on that 
window.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Finally about extends my app function ability

[André Somers]

I can´t found an explanation of the differences of
/reinterpret_cast/ and /dynamic_cast/, because I can´t found
information about /reinterpret_cast/ in Qt Documentation (5.5.0 Qt
version).


You will probably find that Qt doesn't have much to say about them 
because they are part of the C++ language.


http://en.cppreference.com/w/cpp/language/dynamic_cast
http://en.cppreference.com/w/cpp/language/reinterpret_cast

...and, since you're looking at casting, you should probably know 
about const_cast and static_cast as well:


http://en.cppreference.com/w/cpp/language/const_cast
http://en.cppreference.com/w/cpp/language/static_cast

Also have a look then at the cast operator that Qt _does_ provide: 
qobject_cast: http://doc.qt.io/qt-5/qobject.html#qobject_cast


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtDesigner needs redesign.

[André Somers]

Hi,

While I agree that the current plugin system is not convenient, I don't 
get why you would spend a week with QDialogBox-debugging instead of 
building your own Qt Designer in debug mode and run that in a debugger 
against plugins also build in debug mode?


André


Op 04/01/2017 om 15:32 schreef Serge K via Interest:
Среда, 4 января 2017, 14:39 +03:00 от Jean-Michaël Celerier 
>:




On Wed, Jan 4, 2017 at 11:58 AM, Viktor Engelmann
> wrote:


Custom components in Qt are just QWidget derivates and they
can be taken
from a designer plugin. This requires some extra code for
making them
findable (+give them an icon and name etc.) and plugins are
technically
shared libraries. This explains very clearly why recompiling a
custom
component requires a restart if we want a perfect preview like
in .net,
but I still think that there is a lot of room for improvement.


Something that would, I think, boost the usage of the designer is
to skip the "recompilation" part
and just have something that scans your code and interprets the
C++ instead of compiling it, with
something like
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus .

You would just add some metadata to your Widget with
Q_CLASSINFO("DesignerName", "My widget"),
the code looks for classes with this specific key, "compiles" it
and adds it to the designer.


And how implementation ot this differs from clean rebuild? Plugin is a 
shared library with some specific macros - these macros already are 
related to Designer and nothing else. And pluign contains specific C++ 
code to be supported by Designer. Even entire additional class with 
set of mandatory methods needed for each plugin main class. And plugin 
can depend from other files including resources and so on. Which one 
another "compiler" should process this all? Isn't that a 
"micros..t-like-way" to build monstrous and expensive tools? OH, NO!


Exactly plugin auto reloading feature needed for Designer. It is much 
more simpler and powerful that add just another one macro and create 
another one compiler. But... this cannot help with other annoying 
issue when developing plugins. Even Designer custom plugins need to be 
debugged. Now in "designer mode" even qDebug() doesn't work. Nothing 
to say about interactive debugger. It doesn't work for plugins loaded 
to Designer. The only way to debug is - include QMessageBox() and hope 
the QtCreator won't crash. Yes... it crashes if Designer plugin 
contains errors. It crashes immediately if you just call QMessageBox() 
in paintEvent() of custom plugin. I developed custom extended plugin 
based on QSlider. It allows load SVG animated images for groove and 
knob and has some other useful features (they cannot be implemented 
using stylesheets). First time when running in application it looked 
very different from when it was run in Designer. Yes - application and 
designed worked on different platforms. I killed lot of time (about 
week) to understand why they are different and how I must fix this. 
Without ANY debugging options while plugin runs in Designer. I had to 
explore source code of several Qt internal classes to understand how 
this works. But with normal debugging feature I would find solution 
within minutes.



___
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] Generic Table's row to 2 columns property/value tree

[André Somers]

Hi,


Op 28/12/2016 om 00:24 schreef Ch'Gans:

Hi there,

In my application i'm dealing a lot with displaying a list of property
value based on user's selection, the selection can be made either from
a table view (a row) or a graphicsview item (both selections are
synchronised).
My application is laid out with dock widgets on the left (several
list/table views, per 'topic' that display a selection of most
relevant columns from a table model), a graphicsview as a central
widget where graphical items are highlighted/selected, and another
dockwidget on the right which is context/selection dependent.
The left widget can be considered a 'navigation' panel, and the right
widget a 'object detail'.

I'm looking for a nice and somehow generic solution to transform a row
of data from a table model (the user's selection) into a list of
property/value pair (with possibility of nested sub-property a bit
like Qt designer property browser).

Actually I have tried to use the property browser from Qt Solution in
the past, but found it a bit complicated as it requires lot of boiler
plate (I might have fail to use it properly).

Does anyone knows any sort of tricks or pattern to achieve this, or
maybe have a list of gotcha or do/don't? Or maybe knows a ready made
component (GPL accepted).

I haven't yet tried to code anything yet, I'm still in the 'thinking
about' phase (i definitely need a re-usable component). I might even
give another go at the Property Browser Qt solution.
Any kind of comment, hint, tip would be much appreciated.

Many years ago I wrote a similar application, that used an extended 
version of an open source solution I found online. It is still online, 
you can find it here:

https://app.assembla.com/spaces/saint/git/source/master/common/propertyeditor

Note that it does not support nested properties, but it may serve as a 
nice start. The basic idea is that it generates an item in the editor 
for every Qt property in the object you set on it. You can use some 
specially formatted dynamic properties to set some meta data that 
influences what ends up in the editor and in what way.


André


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Gradient Text

[André Somers]

Hi,

You could use a ShaderItem to do this. 

André

Sent from my phone, please excuse my brevity

> On 23 Dec 2016, at 05:41, Jason H  wrote:
> 
> I'm trying to do a sexy Tumbler, and I want the text to be a gradient color, 
> not solid.
> 
> Given:
> - 50%
> 1
> 2 - 100%
> 3
> - 50%
> I want 2, the bottom of 1, and the top of 3 to be 100%, but the top of 1 and 
> bottom of 3 to be 50%, but with a smooth transition over the characters. The 
> current tumbler examples cheat and just set it on the whole character.
> 
> How can I do this?
> ___
> 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] Recommended way to draw formatted text with QPainter

[André Somers]

Hi,


Op 17/12/2016 om 22:42 schreef Joshua Grauman:

Hello all,

I have a bunch of small fragments of formatted text (small paragraphs 
with multiple colors and fonts, using  tags). I need to paint 
them with QPainter at different locations (multiple rectangles of 
text) onto my widget. I've seen recommendations to put them in a 
QLabel and then call QLabel::render(), or to use QTextDocument and 
drawContents(). Are there any other ways to do it? Which is 
recommended for best results/fastest drawing? Thanks!

QStaticText is designed for exactly that purpose.

André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QLineEdit::editingFinshied()

[André Somers]

Op 29/11/2016 om 15:53 schreef Duane:

On 29/11/2016 9:16 AM, Duane wrote:

On 29/11/2016 8:54 AM, Robert Buchinger wrote:


Putting a breakpoint in the code was causing the focusOut to fire when 
the slot was hit due to a return press.  But when I triggered the slot 
by forcing a loss of focus, it of course didn't fire again.  Doh.


Sorry about the noise.
Yes, debuggers are useless when looking at focus issues (and related 
other UI interaction's). At least in an interactive mode.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] License regarding question

[André Somers]

Op 29/11/2016 om 12:01 schreef Konstantin Tokarev:


29.11.2016, 13:51, "André Somers" <an...@familiesomers.nl>:

Op 29/11/2016 om 11:42 schreef Alexander Dyagilev:

  Hello,

  We use Qt under LGPL license.

  We have found some problem in it (bug working with HTTPS on limited
  connection speed) and fixed it. We have recompiled Qt then.

  What do we must to do next to obey the license terms?

  Publish the changes somewhere?

We ended up shipping the actual patches we made in the installer,
putting them in a separate directory together and referencing them from
the licences section in our about box. We kept around the Qt sources for
the Qt we shipped with the product in the office in case anyone would
ever ask for them (nobody ever did, of course).

Looks like a violation of LGPL. Section 6 requires you to provide
_complete_ source code or written offer to do so.
We did offer, in the license text in the about screen. We didn't ship 
the complete Qt sources with the product though, but we kept them them 
around in case anyone would ever ask. Same for some other libs we used 
and patched by the way. In my non-lawyer opinion, that is not an LGPL 
violation.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] License regarding question

[André Somers]

Op 29/11/2016 om 11:42 schreef Alexander Dyagilev:

Hello,

We use Qt under LGPL license.

We have found some problem in it (bug working with HTTPS on limited 
connection speed) and fixed it. We have recompiled Qt then.


What do we must to do next to obey the license terms?

Publish the changes somewhere?


We ended up shipping the actual patches we made in the installer, 
putting them in a separate directory together and referencing them from 
the licences section in our about box. We kept around the Qt sources for 
the Qt we shipped with the product in the office in case anyone would 
ever ask for them (nobody ever did, of course).


AINAL.

Then: please upstream your fixes to Qt by going through the contribution 
steps.


André



___
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 containers deprecated with 5.0?

[André Somers]

Op 28/11/2016 om 11:27 schreef Michael Sué:

Hi André,


There is nothing wrong with using Qt containers either (with the exception of 
QList, which you will want to stear clear of as much as you can), as as
noted, you can (and should) use the std algorithms on them just fine.

What's wrong with QList (as compared to other implementations of a list)?

What makes you think that QList implements a list (like other 
implementions at least)?


Anyway: see the blog or one of the recorded talks from Qt conferences on 
this topic. You will want to get into the habbit of raising a red flag 
whenever you do a code review and find a QList, and start typing QVector 
instead of QList whenevery you write code yourself.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt containers deprecated with 5.0?

[André Somers]

Hi,


Op 27/11/2016 om 18:32 schreef Bob Hood:
This is probably common knowledge, but I came across the following 
paragraph sited in a stackoverflow answer[1] from a page regarding Qt 
algorithms[2]:


"Historically, Qt used to provide functions which were direct 
equivalents of many STL algorithmic functions. Starting with Qt 5.0, 
you are instead encouraged to use directly the implementations 
available in the STL; most of the Qt ones have been deprecated 
(although they are still available to keep the old code compiling)."


The responder then summarizes:

"So using STL when programming with Qt 5 is officially encouraged, 
should it become a necessity."


The original poster was asking about tuples, but the responder sites 
Qt algorithms.  My question is:  Were Qt containers also deprecated 
along with Qt algorithms starting with Qt 5.0?  Or put another way, 
should new code based on the Qt5 series avoid using Qt-specific 
containers now?


As an addition to the answers already received earlier: there is nothing 
wrong with using std containers in a Qt application, and std containers 
are even used inside Qt nowadays. They are not on the API surface 
though, and that's where it starts to hurt a bit. If you end up needing 
Qt API that takes/returns containers regulary but use std containers in 
the surrounding code, you will be doing lots of quite useless 
conversions/copies. That results in ugly and slow performance.


There is nothing wrong with using Qt containers either (with the 
exception of QList, which you will want to stear clear of as much as you 
can), as as noted, you can (and should) use the std algorithms on them 
just fine.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] New QML component

[André Somers]

Op 17/10/2016 om 18:35 schreef Ian Geiser:

Hey all, I just wanted to see where people post new Qt components so others can 
find them and know about them.   I have read about qpm, but I am not sure how 
popular that is yet.  There used to be freshmeat.net, but that is now dead it 
seems.  Any suggestions?  Thanks!


If they would be useful for the broad Qt community, why not contribute 
them to Qt proper?


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt 5.6.2 release date

[André Somers]

Op 11/10/2016 om 13:03 schreef Jargo Kõster:

Hello,

does anyone know when bill be Qt 5.6.2 released...latest updated plan 
was 27th September 2016?


Thanks

It has been released today: 
http://blog.qt.io/blog/2016/10/12/qt-5-6-2-released/


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[André Somers]

Op 20/09/2016 om 22:09 schreef Alejandro Exojo:

On Monday 19 September 2016 18:35:43 Etienne Sandré-Chardonnal wrote:

Yes, but for instance you can't move-pass an object between signals and
slots across a queued connection, unless I'm wrong. You have to make your
object implicitely shared. This causes lots of copies when passing a
std::vector, for instance.

The Qt style on designing signals, is to use those for indicating that
something happened, but not passing the something in the signal. For example,
you get a signal that new data is available (e.g. a datagram), but you don't
get the datagram passed as signal argument.
You don't? Well, you can certainly get a pointer to it (which is cheap, 
of course)...

See QNetworkAccessManager::finished(QNetworkReply *reply); [signal]

I would say that it is quite normal to signal the finishing of some 
operation _and_ directly pass along the results of that operation. If 
that is a std::vector, then indeed it would result in copying (so I'd go 
looking for a different design there, perhaps use a QVector instead).


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What don't you like about Qt?

[André Somers]

Op 19/09/2016 om 22:49 schreef Thiago Macieira:

On segunda-feira, 19 de setembro de 2016 18:35:43 PDT Etienne Sandré-
Chardonnal wrote:

Yes, but for instance you can't move-pass an object between signals and
slots across a queued connection, unless I'm wrong. You have to make your
object implicitely shared. This causes lots of copies when passing a
std::vector, for instance.

Correct. You may have more than one slot connected to the same signal, so move
semantics don't make sense to signal-slot connections: if we moved to the first
destination, then the second would receive a moved-from object.

In theory, one could perhaps make a second connect to a signal with move 
semantics fail, or you could just allow a user to cut himself there, 
just like C++ itself does. At least, I am not aware of any mechanism in 
C++ itself that would protect against doing a move on the same object 
twice. So why should Qt?


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QGaphicsItem deletion

[André Somers]

On woensdag 15 juni 2016 19:00:34 CEST Igor Mironchik wrote:
> Hello.
> 
> On 15.06.2016 16:59, Konstantin Shegunov wrote:
> > Hello,
> > 
> > 
> > On Wed, Jun 15, 2016 at 4:15 PM, Igor Mironchik
> > 
> > > wrote:
> > Parent of the handles is the same as Line's. But Line own objects
> > of handles with QScopedPointer.
> > 
> > This doesn't sound right. If the handles are not children to the line,
> > then the line doesn't own them. Leaving semantics aside, it sounds
> > you're trying to "hijack" the ownership from the parent by using these
> > scoped pointers.
> 
> Exactly. I need to Line be as parent of handles but they should be
> parented to the scene (read form in my app) because I need
> boundingRect() to return exactly bounding rectangle of the line without
> handles. An I need handles to be removed with the Line if Line deleted.
> 
> I know that I can implement my own method in Line like
> boundingRectOfLine() and make handles children of Line. May be it would
> be a better solution, but at this time I have such code and it work...
> 
> > So my question is it possible that handle will be deleted before
> > Line, so QScopedPointer will try to free already deleted pointer?
> > 
> > From your description I'd guess this is exactly what's happening.
> 
> Here you aren't right. In d_tor() of QGraphicsScene I see:
> 
> while (!d->topLevelItems.isEmpty())
>  delete d->topLevelItems.first();
> 
> where topLevelItems are in creating order...
> 
> and in QGraphicsItem d_tor()
> 
> while (!d_ptr->children.isEmpty())
>  delete d_ptr->children.first();
> 
> So when Line deleted it places before handles in children list, and
> before Line deleted handles already deleted and removed from children list.
> 
Fine. So in the current implementation, it may actually work. But be aware 
that there is no guarantee whatsoever that it will always work or will keep 
working in the future. I would not depend on an implementation detail like 
that. 

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Depth-first filtering for QAbstractProxyModel

[André Somers]

Op 08/09/2016 om 15:25 schreef Thompson, Adam B.:


André,

I’ve only been working with Qt for the last couple of years or so and 
haven’t had any formal training, so anything I’m doing is based on my 
interpretation of their documentation or examples. The contents of the 
model itself aren’t very complex, there just happens to be the 
potential to hold a large number of nodes the user needs to sift 
through to take actions (open plots, text editors, etc.). That said, I 
don’t have enough experience to agree or disagree with your assessment.


I’ve tried a caching scheme, but it doesn’t seem to matter much. It’s 
certainly possible my caching isn’t working properly, so I’m not 
ruling that out as an issue. A custom storage back-end and 
QAbstractItemModel subclass would be doable, it would just take some 
time to change things around from how they are right now. That still 
seems to be going against their own suggestions in their documentation 
since the filtering would be done on the model itself instead of a proxy.


I really want to do this the right way so it scales well with the 
amount of data it stores. The problem is having the time/funding to 
implement it since we have other higher priority tasks and the tree is 
currently functional, just not performant with larger models.


Thanks,

Adam



There is really nothing in this message to reply to any more. I do not 
read a follow-up question, nor additional information about the issue 
itself. I gather you know enough now to solve your issue then?


Note that there are more model classes that support doing the filtering 
on the source: QSqlTableModel allows doing exactly this, letting the 
database engine do the filtering (and sorting, for that matter). For 
some cases it makes sense to use a proxy to provide filtering, sorting 
and/or mapping, for other cases it makes sense if the data model itself 
provides API to do that directly, and in some cases the model could help 
a proxy by providing the needed data or API to do its task efficiently. 
I do not think there is a general rule in the Qt documentation telling 
you to _only_ do sorting or filtering using proxy models and nothing but 
proxy models.



André

*From:*Interest 
[mailto:interest-bounces+thompsonab=ornl@qt-project.org] *On 
Behalf Of *André Somers

*Sent:* Thursday, September 8, 2016 3:32 AM
*To:* interest@qt-project.org
*Subject:* Re: [Interest] Depth-first filtering for QAbstractProxyModel

Op 07/09/2016 om 18:03 schreef Thompson, Adam B.:

André,

I’m just using a QStandardItemModel as the source model and a
subclass of QSortFilterProxyModel for the QTreeView mdoel. It
seemed simple enough to use QStandardItemModel for the model
instead of a custom data structure exposed via a
QAbstractItemModel subclass since I don’t need anything too
complex in terms of storage, etc.

Seeing what you write afterwards, I think I disagree with that 
assessment. But, that could also be my bias against the QSIM class and 
the Q*Widget view classes. I think these are fine for toy applications 
or very small models, but not for trees with thousands of nodes and 
fast depth-first filtering capabilities.


My understanding is I should be using some subclass of
QAbstractProxyModel to modify the presentation of the underlying
(source) model instead of having special logic in the model
itself. At least, that’s based on my interpretation of the Qt
documentation.

Well, that's one way. But I think I would consider ditching QSIM and 
creating your own data store with a QAIM-derived model on top. You can 
design that store to the requirements you actually have, such as quick 
depth-first filtering. That is certainly going to be much faster than 
relying on a generic solution.


If you're not prepared to go down that route, I think I'd let the 
proxy or the source model build up some kind of index to speed up 
filtering. That would be easier to maintain if the model is fairly 
static rather than changing all the time, but that's information you 
don't give. You could do something like this if the data in the tree 
is not or only seldom is going to change:


Build up a single vector of items in your model with the piece of data 
you need to search on. That list is going to be in the order of the 
tree, depth first. Now, let each node in your tree keep the indices of 
the first and last item of the subtree for that node, so the index for 
the text of the node itself and the index of the last descendent of 
the node. You will see that every node contains a sub-range of the 
range of its parent node. Now when you search, you do a linear search 
over the list to find all matching items, ending up with a set of 
indices into that list. The visible nodes in your tree are now those 
where there are indices that fall into the range you stored when 
building up your index, which is a cheap, non-recursive test, 
especially since you do not need to check the whole list

Re: [Interest] Depth-first filtering for QAbstractProxyModel

[André Somers]

Op 07/09/2016 om 18:03 schreef Thompson, Adam B.:


André,

I’m just using a QStandardItemModel as the source model and a subclass 
of QSortFilterProxyModel for the QTreeView mdoel. It seemed simple 
enough to use QStandardItemModel for the model instead of a custom 
data structure exposed via a QAbstractItemModel subclass since I don’t 
need anything too complex in terms of storage, etc.


Seeing what you write afterwards, I think I disagree with that 
assessment. But, that could also be my bias against the QSIM class and 
the Q*Widget view classes. I think these are fine for toy applications 
or very small models, but not for trees with thousands of nodes and fast 
depth-first filtering capabilities.


My understanding is I should be using some subclass of 
QAbstractProxyModel to modify the presentation of the underlying 
(source) model instead of having special logic in the model itself. At 
least, that’s based on my interpretation of the Qt documentation.


Well, that's one way. But I think I would consider ditching QSIM and 
creating your own data store with a QAIM-derived model on top. You can 
design that store to the requirements you actually have, such as quick 
depth-first filtering. That is certainly going to be much faster than 
relying on a generic solution.


If you're not prepared to go down that route, I think I'd let the proxy 
or the source model build up some kind of index to speed up filtering. 
That would be easier to maintain if the model is fairly static rather 
than changing all the time, but that's information you don't give. You 
could do something like this if the data in the tree is not or only 
seldom is going to change:


Build up a single vector of items in your model with the piece of data 
you need to search on. That list is going to be in the order of the 
tree, depth first. Now, let each node in your tree keep the indices of 
the first and last item of the subtree for that node, so the index for 
the text of the node itself and the index of the last descendent of the 
node. You will see that every node contains a sub-range of the range of 
its parent node. Now when you search, you do a linear search over the 
list to find all matching items, ending up with a set of indices into 
that list. The visible nodes in your tree are now those where there are 
indices that fall into the range you stored when building up your index, 
which is a cheap, non-recursive test, especially since you do not need 
to check the whole list of indices for every node and the gathering of 
matching indices can be parallelized. Downside is: an insert is going to 
be very expensive as you'd basicaly would need to adjust all nodes that 
follow in the depth-first order. In your case, you could store the 
indices into the model itself.



André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Depth-first filtering for QAbstractProxyModel

[André Somers]

Op 06/09/2016 om 21:20 schreef Thompson, Adam B.:


All,

I co-develop an application that uses a QTreeView to display the 
hierarchical contents of external files. The contents of the tree can 
become quite a chore to sift through, so I added a means of filtering 
via a QSortFilterProxyModel. This works as expected, but the user may 
want to specify a pattern that matches a node deep in the model’s 
structure but not any of the node’s ancestors. As such, the 
breadth-first filtering mechanism provided in QSortFilterProxyModel 
isn’t appropriate for our needs.


I modified filterAcceptsRow to work in a depth-first manner to verify 
my desired filtering effect would work, which it does. However, as 
expected, it yields a huge performance penalty since it performs a 
depth-first search for each row in the model. This is because the 
(recursive) depth-first logic is called for the same nodes many times. 
I added a crude caching scheme which really doesn’t properly mitigate 
the performance issue.


My question: can anyone provide some tips on how to properly subclass 
QAbstractProxyModel so I can provide some custom depth-first filtering 
capabilities? (Sorting isn’t really necessary at the moment, really 
just filtering.)



Perhaps it is possible to do this in a more efficient way using the 
underlying data structure instead? That is: make it possible to query 
each node in your underlying structure directly instead of using the 
model API to iterate down the tree each time? How big is your model in 
terms of depth and number of nodes?


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QListView: drag custom item

[André Somers]

Op 16/08/2016 om 09:26 schreef Frank Rueter | OHUfx:

Hi,

I am trying to get drag to work between two QListViews using a 
custom item.
I can't find the info I need online other than this document 
 which helped a 
little bit but now I'm stuck.


Drag from one QListView to another works fine when I use a 
QStandardItem to hold my data, but when I use a custom item I run into 
trouble, because the receiving model/view creates a QStandardItem when 
the incoming custom items are dropped.


Ideally I could tell the receiving model to use my custom item as the 
default item and otherwise just do it's thing, but I suppose it won't 
be that easy?!
I have played around with the receiving model's dropMimeData() and 
insertRows() methods but can't work out how to read the incoming data 
to then insert a custom item into the receiving model manually.
In QAbstractItemModel.dropMimeData() I tried reading 
mimeData.data('application/x-qabstractitemmodeldatalist'), but that 
returns a byte stream that I don't know how to handle.


Do I have to re-implement the sender's drag data as well to send the 
custom item in the first place?


It seems that everything works out of the box except the creation of 
the QStandardItem upon drop, rather than my custom item, so I am 
hoping I don't have to re-invent the (drag) wheel just to get 
that one part right?!


Any advise would be greatly appreciated.

Thanks,
frank



What kind of models are you using behind these views? Custom models or 
QStandardItemModel instances? To me, it sounds like the latter?


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] best qt class to use to detect line/polygon/region collision

[André Somers]

Verstuurd vanaf mijn iPhone

> Op 9 aug. 2016 om 22:16 heeft André Somers <an...@familiesomers.nl> het 
> volgende geschreven:
> 
> 
> 
> Verstuurd vanaf mijn iPhone
> 
>> Op 9 aug. 2016 om 20:43 heeft maitai <mai...@virtual-winds.org> het volgende 
>> geschreven:
>> 
>> Thanks Viktor but my problem is not to detect whether 2 lines are crossing, 
>> it is to avoid looping on 50k lines for nothing ;) My worst case is when no 
>> cross is found and I looked at each and every line for just nothing.
>> 
> 
> Then look into spacial data structures to organize your data. In this case, a 
> quad tree structure comes to mind, where you put a pointer to the element 
> (line, polygon) into every bucket it crosses. That uses memory and takes time 
> to set up, but you get very fast lookups in return. QGraphicsView already 
> organizes its contents into a spacial structure btw. 
> 
> André

Ps. Note that your choice of data structure depends heavily on your use case. 
Is your set of data stable or does it change a lot? What is the distribution 
over the space? Is the space bounded or not? What is the distribution of sizes 
of objects in relation with the size of your space? Is memory use an issue? 
Etc. A quad tree may work, but would not be the optimal solution for every 
scenario. 

André 
>> Checking a line is crossing another is really fast and I am not using 
>> QLineF::intersects() for that, because I don't need the crossing point and I 
>> save some cycles not computing it.
>> 
>> I think Henry's idea is a good one, and it actually save some ms, but not 
>> much because I have already a mechanism with cells and boundingRects. It all 
>> depends if the lines are more on the left (or right, or up, or down) 
>> depending on what criteria is chosen to build the QMap (x1, x2, y1 ou y2). A 
>> double QMap (or more) seems more expensive than checking a cross on the 
>> remaining set, but I will give it a try. I can spend some cpu time 
>> organizing the set of lines, provided it saves something later when checking 
>> a million random lines for a cross against the set of fixed lines. 
>> 
>> Still working on that.
>> 
>> Philippe Lelong
>> 
>> Le 09-08-2016 15:37, Viktor Engelmann a écrit :
>> 
>>>  
>>> 
>>> Sweepline algorithms are what you are looking for.
>>> 
>>> For 2 single lines, check this
>>> http://algorithman.de/Mathe/GeomSchnitt.pdf
>>> It contains an explicit formula :-) for detecting whether 2 lines intersect.
>>> It is in german, but contains mostly formulas - so it might be 
>>> understandable.
>>> 
>>> Kind regards
>>> 
>>> Viktor
>>> 
>>>  
>>> 
>>> 
>>>> On 09.08.2016 07:22, maitai wrote:
>>>> Thanks Ch'Gans for replying. 
>>>> 
>>>> The lines do not have a width. I thought about QGraphicsScene which I use 
>>>> already but it does seems to be too much for that (plus memory consumption 
>>>> is an issue as well). 
>>>> 
>>>> To give a bit mode details: The list of lines does not change during 
>>>> calculation, it changes only when the user moves the view, but remain as 
>>>> it is during calculation. I don't need the crossing point, and I don't 
>>>> need the number of lines that crosses. If it crosses once I break. No 
>>>> bezier curves or fancy things, just lines. Most of these lines form a 
>>>> closed polygon that I can detect and manipulate as such, but some other 
>>>> are just single lines (or non-closed polygons) not connected to anything 
>>>> else. 
>>>> 
>>>> The number of lines in the list can vary from 0 to around 50k, it depends. 
>>>> I already divide the set of lines in subsets (square cells) and before I 
>>>> go iterate on the list of lines in a cell, I check that the line is 
>>>> crossing (or is inside) the cell. I have then improved a bit by using a 
>>>> QPainterPath to determine the boundingRect of the lines within a cell 
>>>> which I use instead of the cell borders. A bit better, but not that much. 
>>>> The size of cells is also difficult to tune (more cells with less lines, 
>>>> or the opposite?). 
>>>> 
>>>> Since my first mail I have also tried to give some thickness to the line 
>>>> and use QPainterPath::intersects(). The result is much slower than simply 
>>>> iterating on the list of lines, at least 1000 times slower (and cpu is 
>>>> going craz

Re: [Interest] best qt class to use to detect line/polygon/region collision

[André Somers]

Verstuurd vanaf mijn iPhone

> Op 9 aug. 2016 om 20:43 heeft maitai  het volgende 
> geschreven:
> 
> Thanks Viktor but my problem is not to detect whether 2 lines are crossing, 
> it is to avoid looping on 50k lines for nothing ;) My worst case is when no 
> cross is found and I looked at each and every line for just nothing.
> 

Then look into spacial data structures to organize your data. In this case, a 
quad tree structure comes to mind, where you put a pointer to the element 
(line, polygon) into every bucket it crosses. That uses memory and takes time 
to set up, but you get very fast lookups in return. QGraphicsView already 
organizes its contents into a spacial structure btw. 

André
> Checking a line is crossing another is really fast and I am not using 
> QLineF::intersects() for that, because I don't need the crossing point and I 
> save some cycles not computing it.
> 
> I think Henry's idea is a good one, and it actually save some ms, but not 
> much because I have already a mechanism with cells and boundingRects. It all 
> depends if the lines are more on the left (or right, or up, or down) 
> depending on what criteria is chosen to build the QMap (x1, x2, y1 ou y2). A 
> double QMap (or more) seems more expensive than checking a cross on the 
> remaining set, but I will give it a try. I can spend some cpu time organizing 
> the set of lines, provided it saves something later when checking a million 
> random lines for a cross against the set of fixed lines. 
> 
> Still working on that.
> 
> Philippe Lelong
> 
> Le 09-08-2016 15:37, Viktor Engelmann a écrit :
> 
>>  
>> 
>> Sweepline algorithms are what you are looking for.
>> 
>> For 2 single lines, check this
>> http://algorithman.de/Mathe/GeomSchnitt.pdf
>> It contains an explicit formula :-) for detecting whether 2 lines intersect.
>> It is in german, but contains mostly formulas - so it might be 
>> understandable.
>> 
>> Kind regards
>> 
>> Viktor
>> 
>>  
>> 
>> 
>>> On 09.08.2016 07:22, maitai wrote:
>>> Thanks Ch'Gans for replying. 
>>> 
>>> The lines do not have a width. I thought about QGraphicsScene which I use 
>>> already but it does seems to be too much for that (plus memory consumption 
>>> is an issue as well). 
>>> 
>>> To give a bit mode details: The list of lines does not change during 
>>> calculation, it changes only when the user moves the view, but remain as it 
>>> is during calculation. I don't need the crossing point, and I don't need 
>>> the number of lines that crosses. If it crosses once I break. No bezier 
>>> curves or fancy things, just lines. Most of these lines form a closed 
>>> polygon that I can detect and manipulate as such, but some other are just 
>>> single lines (or non-closed polygons) not connected to anything else. 
>>> 
>>> The number of lines in the list can vary from 0 to around 50k, it depends. 
>>> I already divide the set of lines in subsets (square cells) and before I go 
>>> iterate on the list of lines in a cell, I check that the line is crossing 
>>> (or is inside) the cell. I have then improved a bit by using a QPainterPath 
>>> to determine the boundingRect of the lines within a cell which I use 
>>> instead of the cell borders. A bit better, but not that much. The size of 
>>> cells is also difficult to tune (more cells with less lines, or the 
>>> opposite?). 
>>> 
>>> Since my first mail I have also tried to give some thickness to the line 
>>> and use QPainterPath::intersects(). The result is much slower than simply 
>>> iterating on the list of lines, at least 1000 times slower (and cpu is 
>>> going crazy). I was also considering using QRegion but I suppose the result 
>>> will be similar. 
>>> 
>>> I will have a look at CGAL Minkowski 2D algorithms, and will also try the 
>>> elegant solution with a QMap provided by Henry in the other reply. 
>>> 
>>> Thanks to you both, 
>>> Philippe 
>>> 
>>> 
>>> Le 09-08-2016 03:07, Ch'Gans a écrit : 
 On 9 August 2016 at 04:05, maitai  wrote: 
> Hello all, 
> 
> I have a list of lines (QLineF) in 2D space. Some might represent a 
> closed 
> polygon, some others are just a line or represent a non closed polygon. 
> Classical problem: I need to detect if another given line is crossing one 
> of 
> the lines in the list. I don't need the crossing point, just to know if 
> it 
> crosses or not.
 
 Do your lines have a width? or are they "ideal" lines (0 thickness)? 
 If you need to deal with outline/shape stroking, then you might 
 consider using QGraphicsScene. 
 This might look a bit too much at first, but maybe in the long run 
 this can save you lot of time depending on you spatial query use 
 cases. 
 Just check http://doc.qt.io/qt-5/qtwidgets-graphicsview-chip-example.html 
 if you never tried before. 
 
 Fore more "advanced" geometry approach, you could have a look at cgal 
 (eg: 2D 

Re: [Interest] QFileSystemModel

[André Somers]

Use a proxy model instead, such as CheckableProxyModel. Google for it, the 
example app works in a QFileSystemModel. You do *not* want to iterate deep into 
a tree model such as QFSM just for keeping track of checked states...

André

Verstuurd vanaf mijn iPhone

> Op 7 aug. 2016 om 11:21 heeft Igor Mironchik  het 
> volgende geschreven:
> 
> Hi,
> 
> I derived from QFileSystemModel to have check boxes on files and directories. 
> It works.
> 
> I want to recursively check all files and all directories within checked one, 
> but rowCount() for checked directory returns 0 if this directory wasn't 
> expanded in tree view.
> 
> I played with canFetchMore() and fetchMore(). It doesn't help.
> 
> How can I solve this problem?
> 
> ___
> 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] Relationship between a QEventLoop and QCoreApplication::exec().

[André Somers]

Verstuurd vanaf mijn iPhone

> Op 7 aug. 2016 om 09:12 heeft Frederic Marchal 
>  het volgende geschreven:
> 
> On Thursday 04 August 2016 11:20:58 Thiago Macieira wrote:
> > On quinta-feira, 4 de agosto de 2016 10:32:26 PDT John Weeks wrote:
> > > > On Aug 4, 2016, at 10:04 AM, Thiago Macieira 
> > > > wrote:
> > > >
> > > > Starting an event loop from inside another event loop.
> > > >
> > > > exec() → some slot or event handler → exec()
> > >
> > > It would also seem to cover any use of QDialog::exec() in the main thread,
> > > and QDialog can be used only in the main thread.
> >
> > Correct. Don't use exec(). Call show() it and return to the existing
> > mainloop.
>  
> That's very restrictive!
>  
> It is common (at least to me) to call QFileDialog::getOpenFileName() when the 
> user clicks on the "Open" menu and then use the returned file name to carry 
> on the open action. QFileDialog::getOpenFileName() does call QDialog::exec(). 
> According to you, it must be avoided like the plague… It means it renders 
> similar QFileDialog static methods useless.
>  
> Yet, I don't see where the problem is. QDialog::exec() displays a modal 
> dialog. It is not possible to click again on the menu or button that 
> displayed the dialog in the first place. It effectively breaks recursive 
> looping, right?
>  
Wrong. There are many sources of events, and only the ones related to user 
input are blocked this way. 

André

> Frederic
>  
> ___
> 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] Design Issue with QAbstractItemModel & QTreeView

[André Somers]

You might look to QFilwSystemModel for inspiration. 

André

Verstuurd vanaf mijn iPhone

> Op 4 aug. 2016 om 18:48 heeft Sébastien Le Ray  het 
> volgende geschreven:
> 
> Hi list,
> 
> I'm currently designing an application which presents its data in a tree. I 
> have a QAbstractItemModel making a bridge between these data and the view, so 
> far so good.
> 
> However I'm stuck when it comes to react to underlying data structure 
> changes, specifically when rows are added and removed. Model has to react 
> before and after the row is added, however, the only information it gets is 
> "row added" signal. Worse, adding a row can add the row and some subitems 
> (some objects creates mandatory children).
> 
> What is the proper way to deal with this? Should I have some kind of proxy 
> between the data and the mode?
> 
> Regards
> 
> ___
> 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] DelegateModel: Dynamic Delegate Model groups

[André Somers]

I'd just write my proxy model in C++ and be done with it.

André


Op 26/07/2016 om 15:46 schreef Jason H:

I want to have groups corresponding to the equivalent of 'SELECT DISTINCT x' 
query. Then I want each item assigned to a group of it's value of x. For 
example:
'SELECT DISTINCT x' -> ['a', 'b', 'c']
'SELECT x,y' -> [ ['a', '1'], ['a','2'], ['b','3'], ['c', '4'], ['c','11'] ]

Then I have 3 groups: a has 2, b has 1, c as 2, then I want to set filerOnGroup 
to one of the groups. Is there a way to do this?



___
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] Correct way of exposing enum list to QtQuick

[André Somers]

Op 21/07/2016 om 17:17 schreef Tomasz Olszak:

Hi,

I encountered something that bothers me for a few days. I would be 
thankful if someone can point nice workaround for such case:


class MyClass {
 Q_OBJECT
 Q_PROPERTY(MyEnum myEnumProperty ...)
 Q_PROPERTY(QVariantList availableValuesOfMyEnum ...)
public:
enum MyEnum {
  MyEnumValue1,
  MyEnumValue1
}
Q_ENUM(MyEnum)
}

From Qt Quick everything works ok except indexOf:

objectOfMyClass.availaleValuesOfMyEnum.indexOf(objectOfMyClass.myEnumProperty) 
gives -1


And it is reasonable because availaleValuesOfMyEnum is list of 
QVariant not list of MyEnum.


If I change type of myEnumProperty to QVariant, indexOf works ok, but 
javascript switch doesn't (QVariant is not int). Additionally 
myEnumProperty is printed nicely in logs from Qt Quick(not raw integer 
value).


Question:
Does anyone has better idea how to expose list of enums to QtQuick so 
that searching for enum in such list will work out of the box?


Cheers,
Tomek

You could consider sharing the values as strings instead. With Q_ENUM, 
it is easy to turn the enums into strings. And you can search for a 
string I think.


André




___
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] Is it a LGPLv3 infringement to copy paste qFuzzyCompare implementation

[André Somers]

Op 22/07/2016 om 11:41 schreef Ch'Gans:

On 22 July 2016 at 20:25, Jean-Michaël Celerier
 wrote:

I was pointed out that there's a potential LGPLv3 license

infringement, although I understand where the FUD is coming from, I
think that it is OK to read LGPLv3 source code to get inspired as long
as you don't blindly copy/paste code (In my case i checked out quite a
few articles and forum threads before choosing the Qt way as the best
way to do it for my application).

There is no infrigement, you can even use directly qFuzzyCompare in your
proprietary code :
 From the LGPLv3.0

The object code form of an Application may incorporate material from a
header file that is part of the Library. You may convey such object code
under terms of your choice, provided that, if the incorporated material is
not limited to numerical parameters, data structure layouts and accessors,
or small macros, inline functions and templates (ten or fewer lines in
length), you do both of the following:

a) Give prominent notice with each copy of the object code that the Library
is used in it and that the Library and its use are covered by this License.
b) Accompany the object code with a copy of the GNU GPL and this license
document.

Interesting excerpt indeed. So you can use small inlines and templates
of a LGPLv3 header file "under terms of your choice"! What a surprise!
This is quite liberal for a so-called "viral" license.
I'm using "viral" here because this is quite often the term used to
spread FUD, I have personally always liked GNU licenses and have great
respect toward all the people behind them.

Thanks a lot for pointing that out.

Please be careful there. It is about *object code*, not source code! The 
idea of this section is to deal with the reality of compilers and 
linkers: stuff from headers ends up in your own object files. So, the 
license allows that to happen. It is *not* a licence to copy sources 
into your own sources and compiling that.


And yes: studying source code from GPL like-licenced projects is 
explicitly encouraged.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[André Somers]

Op 07/07/2016 om 23:52 schreef Rob Allan:
I'm part of a team that is looking at migrating an existing Windows 
C++ app to Qt. The first decision is whether to use Widgets or Qt 
Quick. Since Qt Quick is newer, shinier, faster, etc, that seems like 
the obvious choice. However, for reasons that I won't go into here, 
the vast majority of forms in our app are built dynamically in code. 
This kind of approach seems easy enough with Widgets, but looks like 
it could be difficult, or even infeasible, with Qt Quick. That's 
because the preferred way of creating Qt Quick layouts is using QML, 
and while there is an object model backing that, my impression is that 
this object model is not designed to support heavy-duty creation and 
manipulation of layout elements. For example, while QQuickItem is 
documented, none of its derived classes are, and I believe their 
interfaces may be private - so the only way to manipulate items is 
using a generic "setProperty" syntax. And while there are a few 
articles around that talk about accessing the Qt Quick model from C++, 
such as this one 
[http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c], 
they tend to use snippets of QML to get the job done in a rather hacky 
way, and make various comments about the perils and pitfalls of trying 
to manipulate the model from code.


I can't help comparing this with two other popular layout frameworks: 
WPF/XAML, and Android/AXML. In both of these worlds, the markup 
language and the "code-behind" class hierarchy of UI elements are 
absolutely equivalent 1st class citizens. Anything you can do in XAML, 
you can also do in the C# code-behind, whether it be creating 
controls, changing their properties, altering layouts, etc. Likewise 
in Android/AXML, I can (if I choose) create FrameLayouts, 
RelativeLayouts, TextViews, etc in code, and arrange them and 
manipulate them any way I like, as an alternative to creating an AXML 
designer layout.


It seems very unfortunate that Qt Quick doesn't take this approach, 
and that the "code-behind" experience is so limited.


Am I missing something here? Assuming I'm not, are there any plans to 
make the Qt Quick class model more "open", with full documentation and 
public interfaces for all relevant properties and methods?


No, you are not missing anything here. You are right that there is 
currently no exposed C++ interface for QML that allows you to define 
your UIs like you can from QML. I understand the reasoning for not (yet) 
providing it, but it is indeed an often-requested thing and I would 
apreciate one appearing. AFAIK, the main reason for not having an 
exposed C++ backend is the stability that would enforce. Having only a 
QML backend frees the developers from having a stable C++ backend with 
binary compatibility guarantees. That is quite a burden to have for a 
young technology like QML en Qt Quick.


But of course there are still several supported options available. 
Xavier already mentioned one, but did you consider just generating the 
actual QML on the fly and loading that? That would allow totally dynamic 
forms.


Still, you may want to consider sticking with Qt Widgets. There is 
nothing wrong with that approach. I don't know the needs of your 
application, but most applications consisting of lots of dialogs with 
buttons, line edits, drop-downs, lists, etc. Qt Widgets is just a very 
good fit. It is very mature, stable and has the C++ interface you're 
looking for. Where it does *not* shine is if you want performant 
animations of your UI like you have mobile devices. If that's not what 
you're after, then Qt Widgets may just be a better fit for you.


HTH,

André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Fw: Translations in QML

[André Somers]

Op 05/07/2016 om 07:34 schreef Beemaneni, Bala:






*From:* Beemaneni, Bala
*Sent:* Tuesday, July 5, 2016 11:03 AM
*To:* developm...@qt-project.org
*Subject:* Translations in QML

Hi Guyz,

I am using Translations in Qml with linguist ,lupdate and lrelease.It 
 works fine. But my requirement is , when i have a 
string say "Hello" in different QML files say 100 places , i do not 
want to update the respective language string for that in each 
file.Hence the update should be done in one place so that it reflects 
everywhere.Currently i do not have much idea how to achieve this? Can 
anyone suggest the best approach ...



You don't want to do that in the general case, as the same word may need 
to be translated differently depending on context. Linguist will suggest 
a previous translation that you can accept with a single keystroke, but 
it is up to the translater to verify it makes sense in the current context.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Delegate is not visible in the QTableView

[André Somers]

Op 12/07/2016 om 10:08 schreef Jha Sonakumar:


I have created a class |customDelegate| (inherits |QItemDelegate|) in 
my Qt application and I created |setEditor()| function.But the 
delegate is not visible in the |QTableView|, until I click on the row.


The |customDelegate| class has a |QPushButton| and a |QLable|.

How to fix the issue?​


Why do you expect the editor to be visible if you are not editing the item?

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

[André Somers]

Op 06/07/2016 om 21:17 schreef André Pönitz:

On Wed, Jul 06, 2016 at 08:34:44AM +0200, André Somers wrote:

Note that even if you define your GUI in QML, you can still do
everything else in C++. The QML doesn't have to be much more than what
you already have as .ui files now, and they are not C++ either are
they?

I keep hearing "If done well, QML is no worse that .ui", but why would
that matter to me? Most of my widgets are done in code, refactoring
typically "just works", and it's typically less(!) lines than doing the
same thing in QML.

I did not mention better or worse. It's different, and it is what you 
need to use to make full use of the GPU. If that is not needed for your 
usecase, widgets may suit your needs better. Great! There is nothing 
wrong with widgets if you ask me, and I think that there is still plenty 
of room for development there even if the official status is "done". But 
it is never going to be as performant graphically as Quick 2 is. As long 
as you ('all) are aware of its limitations, it's still a great and 
mature technology.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

[André Somers]

Op 06/07/2016 om 02:56 schreef Scott Aron Bloom:


-Original Message-
From: Interest [mailto:interest-bounces+scott=towel42@qt-project.org] On 
Behalf Of Thiago Macieira
Sent: Tuesday, July 5, 2016 5:42 PM
To: interest@qt-project.org
Subject: Re: [Interest] Utilizing the GPU, how to start?

On terça-feira, 5 de julho de 2016 11:45:41 PDT Jason Kretzer wrote:

How does one get Qt widgets to take advantage of a GPU?  If this
question seem naïve, it is because it is.

With my application, I am displaying different types of media —
mp4 (using QMedia Player)
Html (folders containing a "mini-site” using QWebView) Images (using a
Qlabel)

This Qt 5.5, Windows7/10, running on a low end compute stick.  The CPU
seems to take the brunt of the performance.  Just wondering how to
offload some of that?

Stop using QtWidgets, including QtWebView and QLabel, and transition to Qt 
Quick instead. Qt Quick uses the GPU, QtWidgets do not.
==

That’s a pretty horrible answer... There are MANY of us, who prefer for all 
sorts of reasons, to use C++ as our primary development language.

Is there no outlook for QtWidgets to start using the GPU?

No, there is not. Not realisticly. First of all, widgets are "done", so 
not much development is going on there. But more important is that the 
way widgets are rendered simply doesn't suit the way modern GPU's work. 
It is the main reason Quick (2) was created in the first place: render 
the contents in such a way that it can utilize the GPU the way its meant 
to be used. That can't be retrofitted to the widgets world.


Note that even if you define your GUI in QML, you can still do 
everything else in C++. The QML doesn't have to be much more than what 
you already have as .ui files now, and they are not C++ either are they? 
Difference is of course that they get compiled into C++, where QML is not.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt LGPLv3 and Qt LGPL Exception

[André Somers]

Op 28/06/2016 om 11:09 schreef Jean-Michaël Celerier:


On Tue, Jun 28, 2016 at 10:39 AM, Benjamin TERRIER 
> wrote:


The technical reason is that when including Qt headers in proprietary
software, your final binary contains compiled forms of Qt code (e.g
inline function or template classes).


From the LGPLv3 :


3. Object Code Incorporating Material from Library Header Files.

The object code form of an Application may incorporate material from a 
header file that is part of the Library. *You may convey such object 
code under terms of your choice*, provided that, if the incorporated 
material is not limited to**numerical parameters, data structure 
layouts and accessors, or small macros, inline functions and templates 
(ten or fewer lines in length), you do both of the following:


So... How exactly do you use any of the Qt containers using the LGPL3 
libraries? Are they implemented in 10 or less lines of template code?


It think the question is valid, and reading the question, you can see 
that he read that passage.


André


  * a) Give prominent notice with each copy of the object code that
the Library is used in it and that the Library and its use are
covered by this License.
  * b) Accompany the object code with a copy of the GNU GPL and this
license document.



Best
Jean-Michaël Celerier


___
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] Detecting if the application is already running from another user account

[André Somers]

Op 03/06/2016 om 15:26 schreef Nye:



On Fri, Jun 3, 2016 at 4:23 PM, André Somers <an...@familiesomers.nl 
<mailto:an...@familiesomers.nl>> wrote:


Windows tends to mess with you here, applying the same kinds of
tricks they introduced for the registry long ago to the file
system now too.


What tricks do you mean? Perhaps I'm not up to date with the win API, 
but I don't remember something really special about the registry.
Basically windows telling you you can read and/or write somewhere, when 
in fact windows is redirecting those reads and/or writes to somewhere 
else specific for your user behind your back.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Detecting if the application is already running from another user account

[André Somers]

Op 03/06/2016 om 15:08 schreef Thiago Macieira:

On sexta-feira, 3 de junho de 2016 11:40:31 BRT Etienne Sandré-Chardonnal
wrote:

Hi,

I would like to detect if my application is already running from another
user account and warn the user.

Create a file in a public place (like /tmp) that indicates it's running. You
can use a QLockFile, provided the other side always uses tryLock() and never
lock().

Be careful with that. Windows tends to mess with you here, applying the 
same kinds of tricks they introduced for the registry long ago to the 
file system now too.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] About Qt StyleSheet

[André Somers]

Hi,

What I _think_ happens is that you currently are using a style that does 
not support style sheets. Only build in styles do, up to a point. If you 
then apply a style sheet, Qt probably switches to a fall-back style that 
_does_ support style sheets, but that has an effect on other widgets as 
well as you noticed.


I'd steer clear of using style sheets if you can. They generally end up 
being more trouble than the're worth even though it seems like a simple 
technique to use at first.


André

Note: I did not check any of this in either docs or source code.


Op 31/05/2016 om 10:55 schreef Berkay Elbir:

Hello All,

I have a problem about Qt Stylesheets. I use this code piece, this is 
a QLabel inside a QDialog.


ui.newGroupNameLabel->setStyleSheet("QLabel { color : black; }");

I also tried giving it a name usingQObject::setObjectName() and use an 
ID Selector to refer to it. But it still occurs.


It affects whole project. I mean that affecting other widgets. All the 
expand symbols change to plus sign. This QLabel is unrelated to this 
widget(below).

Did anyone face with this problem?


Inline image 1


Inline image 2

Thanks in advance,

Berkay



___
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] Preferred way to create custom look-and-feel GUI

[André Somers]

Op 08/05/2016 om 16:40 schreef Jan Müller:

Hello,

I was wondering, what is the preferred way to create a GUI with a 
custom look-and-feel appearance, similar as e.g. QtCreator.


I have a modestly large application, using a QWidgets approach and I 
use 'designer' to create the ui/layout.


The application has several modes/screens, which are accessible at the 
moment through a tabview widget.


At the core of the application there is a QGLWidget, drawing lots of 
data coming from the C++ core.


I would like to make the application appear a bit more modern, e.g. 
with custom look-and-feel buttons/spin-boxes etc.


I recently discovered QML. Does it make sense to migrate to a QML 
based approach? I'm thinking of creating the mainwindow together with 
buttons to switch between the modes in QML. And instantiate my (c++ 
implemented) OpenGL widget in QML (and make it derive from QQuickItem).


Or should I stick with the QWidgets approach and use a stylesheet to 
implement more 'fancy' looking things such as gradients and custom 
look-and-feel components?


What does QtCreator use to implement the GUI? For example the 
navigation bar at the left with the "Welcome", "Edit", "Design", etc. 
buttons. I tried to look into the sources of QtCreator, but got a bit 
lost.



There are multiple approaches possible. It depends a bit what you want 
to achieve. I think QML is very promising, but the components are still 
not very mature. That is only illustrated once more by yet another break 
in there with QtQuickControls 2.0. Still, cool things are possible. 
Showing OpenGL in QtQuick is certainly possible.


However, you can also consider a more conservative approach. If widgets 
are serving you well and you just want a different look, you can also 
implement your own style. I would recommend that over using style 
sheets. Doing this will not give you fancy animations, but it will give 
you all the widgets goodness and stability that 
QML/Quick/Components/Controls/WhatEverItIsCalledToday so far is lacking.


André



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[André Somers]

Op 05/05/2016 om 13:20 schreef Nye:
On Thu, May 5, 2016 at 4:22 AM, Nikos Chantziaras > wrote:


On 05/05/16 01:44, Nye wrote:

No one said it does. Perhaps I'm misunderstanding, are you
searching for
a silver bullet for memory management?


I already found it. Question is how to make Qt work with it :-)


You most certainly have not. I'm tired of repeating this, but here I 
go again: C++ IS NOT JAVA!



 > That's not good enough. I need to delete objects way before
their
parent is deleted.

So delete them. As I said, parent is notified of the child's
deletion.


If I delete them, the parent may already have deleted them. So I'd
have a double-delete.


We are running in a circle here. If the parent may delete the children 
before you've lost all the references to them, then use QPointer.


 > When 'parent' gets deleted before 'dialog', then 'dialog' gets
deleted even though it's on the stack.

And how does the parent gets deleted before the 'dialog' if I
may ask,
unless you're doing deletions from different threads ...?


I don't know. There's long call chains. Someone may delete the
parent. There's no way to know.


The whole premise behind Mr. Sommers' code was that this is in one 
function (one stack frame), so unless you do `delete this` in the 
middle of the function (directly or indirectly) there doesn't seem be 
a way the parent gets deleted.
Well, that's not quite true of course. If you want to show a dialog 
created on the stack, you will have to use it's exec() method. That 
spins an event loop, and that means that a lot can happen in the mean 
time. It can vary from an incoming DBUS messages causing the application 
to terminate to something in response to a signal from that dialog 
itself, to some timer triggering a series of events that lead to the 
destruction of the parent.


So, in that sense, Nikos is right.

I prefer just dealing with that using... new and ::open instead.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] What's the recommended way to put QObjects in smart pointers?

[André Somers]

Op 04/05/2016 om 16:48 schreef Nikos Chantziaras:
I've been removing every trance of 'new' and 'delete' from my code and 
switching to something like:


  auto obj = std::make_unique(ctor args);

(Or std::make_shared, depending on the situation.)

But for QObjects with a parent, that can go horribly wrong. So I have 
to do annoying stuff like:


  auto dialog = new QDialog(parent);
  // work...
  delete dialog;


Assuming the above is one function, you could just do:

auto dialog = QDialog(parent);
//work

//end of scope, dialog gets deleted

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt signal overhead (same thread, direct connection)

[André Somers]

Op 22/04/2016 om 18:47 schreef Ben Lau:



As long as the passed data is an implicit sharing class like 
QByteArray, then it will be fine. Because only a pointer to the 
contained data is passed. Data copying only happen when a function 
write to an implicit sharing class.


That might not be as cheap as you think it is. The refcounting is done 
in a thread-save way, and that costs time. For not smallish contents, it 
may be quite a bit cheaper to just copy the data itself.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] CLion to replace QtCreator?

[André Somers]

Op 06/04/2016 om 15:44 schreef Diego Iastrubni:


This is not trivial to implement in QTextEditor, since it has a single 
QCursor (a deep dependency, which cannot be changed quite easily.  Or 
can it...?


Perhaps it is me, but I think QTextCursor is designed for this purpose? 
You can create many on the same document. And QCursor is a class to deal 
with the mouse pointer, not text cursors.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] CLion to replace QtCreator?

[André Somers]

Op 05/04/2016 om 22:47 schreef Alejandro Exojo:

El Tuesday 05 April 2016, André Somers escribió:

That works, but it is not as flexible as what we see in those gifs. For
instance, you cannot move the cursor left or right or make the same edit
on multiple lines that are not vertically aligned.

That's what you miss for not using FakeVim. ;-)


That might very well be it. :-)

So... the FakeVim can do that trick?

André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] CLion to replace QtCreator?

[André Somers]

Op 05/04/2016 om 12:05 schreef Julius Bullinger:

On Monday, 4. April 2016 18:23, Thiago Macieira wrote:

9. Multiple cursors (see the demo on SublimeText's home page - its epic,
and Atom badly implements it),

Explain. Sounds intriguing.

It's better shown than explained, see e.g. http://i.stack.imgur.com/TMRK3.gif 
and 
https://packagecontrol.io/readmes/img/d346da37ce3d306f23f960f2a103fbc0f4562034.gif
 for examples.

This is the only feature I'm really missing in Qt Creator, and the reason I 
keep Sublime open besides Creator all the time.
There's pretty basic multi-cursor functionality in Creator, but it's not quite 
as polished as Sublime's. Really, you need to try yourself to see how useful it 
is!

I like it, and added a feature request for it: 
https://bugreports.qt.io/browse/QTCREATORBUG-16013


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] CLion to replace QtCreator?

[André Somers]

Op 05/04/2016 om 15:28 schreef NoMercy:

Check out the bug report link in first mail.


So, start contributing to CLion... Why do you need Creator to be 
effectively dumped for that?


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt modules dependency tree

[André Somers]

Op 30/03/2016 om 20:15 schreef Elvis Stansvik:

This really called for one of those ugly GraphViz graphs. Attaching
monstrosity SVG and the ugly script that made it.



Cool! Thanks for sharing, both the result and how you achieved it.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[André Somers]

Op 23/03/2016 om 16:57 schreef Jason H:

Not sure. This is an app for a tablet, I've always packaged assets in qrc, because it 
"just worked". I could try DISTFILES, but I'm unsure how that work on mobile 
platforms.
Please don't. Don't fill your users' devices with assets they are not 
going to use, like video or audio for different languages. It doesn't 
scale. Instead, get the right contents for your application on demand 
when first requested, so you only store on the users device what the 
user actually needs.


André





Sent: Wednesday, March 23, 2016 at 11:41 AM
From: "Gian Maxera" 
To: "Jason H" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Very large QRC file

My absolute rule is Never Never put big files into qrc file.
Can you avoid it too ?


On 23 Mar 2016, at 15:39, Jason H  wrote:

I have a qrc devoted to media: audio and video. It's only about 100 megs total 
of both (2 videos and several languages for each). It results in about a 500MB 
cpp file. It takes 8 gigs to compile, which is what my hardware ram is, so I 
spend a lot of time swapping.

Everytime I compile it takes 10 minutes to compile the assets.qrc, even though 
it doesn't change. Is there a way that I can get the build system to be more 
intelligent about building it?
___
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


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[André Somers]

Op 23/03/2016 om 17:04 schreef Konstantin Tokarev:


23.03.2016, 19:03, "Sean Harmer" :

On Wednesday 23 March 2016 16:57:04 Jason H wrote:
Notice the -no-compress option too this can save runtime CPu costs 
involved with decompressing the data especially for already 
compressed formats such as most video codecs. 

I haven't noticed any difference when using this option with png assets, 
resulting files were byte-identical
That's because qrc is clever enough to not even try compressing pngs. It 
doesn't know about all possible file types though.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Somers]

Op 17/03/2016 om 00:46 schreef Bob Hood:

On 3/16/2016 5:02 PM, Scott Aron Bloom wrote:
I find them both pretty bad L…  I have spent too much time, looking 
at other people’s code trying to figure out “why” it wont connect, 
only to realize someone had snuck in a “private:” second so moc 
didn’t generate the slot information.


I prefer “slotFoo” and “slotBar” as well as “sigFoo” and “sigBar”


It really lets the methods stand out as slots and signals.. It also 
means, don’t think “sender()” can ever valid if you are not in a 
“slotXYZ” function.





I actually prefix my slot method names with "slot_" and signals with 
"signal_" so they are also easily identifiable in the C++ module as 
I'm looking through the code.  More self-documentation.


And I happen to think that these naming 'conventions' are pure nonsense. 
I really don't care much _how_ a method is called. What's the difference 
between having a method called due to a signal emit and having a method 
called directly? None. I want my methods to be called after what they 
_do_, and not how they are called. What if I I find I have a need to 
call the "slot_" method directly from some other code as well? Should I 
be allowed? Of course I should be! Be the name slot_* suggests issues 
there that don't exist, especially if you don't use sender() any more 
(which has been discouraged for many years already anyway).


And as for people being used to seeing blocks of methods behind a 
'public slots:' access specifyer: sure, but it doesn't add much 
information. It only serves to create some kind of artificial grouping 
of your methods in your declaration that is probably not even all that 
sensible. For instance, if I have a class with many properties on it, I 
think it makes sense to keep the methods related to each property 
together, so I have a quick overview over what methods are available for 
what property. You'd see me writing this:


Foo foo() const;
void setFoo(Foo foo);
Q_SIGNAL fooChanged(Foo foo);

Bar bar() const;
void setBar(Bar bar);
Q_SIGNAL barChanged(Bar bar);

I find that much more readable than having to look in some signals 
section to find if there is a notification signal, and then in some 
slots section to see if the setter is perhaps declared as a slot or not.


For me, Q_SLOT or slots: has little value any more, other than making 
the methods callable in dynamic contexts like QML.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Somers]

Op 17/03/2016 om 08:35 schreef Till Oliver Knoll:



Am 16.03.2016 um 22:37 schrieb André Pönitz :

On Wed, Mar 16, 2016 at 02:31:33PM +, Gian Maxera wrote:

I can connect to Foo::bar either way. If I don't intend to ever use
the old-style connect syntax, is there a reason to have "public
slots:" anymore?

One reason that for me it’s fundamental: Readability of your code !!!

It doesn't make the code more readable then a comment

   // This is a slot !!!
   void foo();

Extend your example to a dozen or so slots and you'd quickly agree that

private slots:
   void foo();
   void bar();
   void baz();
   ...

is much more readable, as compared to, say, repeating your comment or writing something like 
"The following 12 methods are slots (but the 13th isn't! And I'm pretty sure that the next Joe 
Programmer will insert his/her "barFooWhichIsNotASlot()"-method randomly between the 
first 12 methods anyway... so whatever!)"

Off course you can try to emphasise your slots with nice ASCII art comments, 
start a fight with your colleagues about the style guide for comments...

Or just write

   private slots:

;)



I find that just the "private:" part tells me all I need to know in 
terms of code documentation. No need for the comment, nor a need for the 
slots part. If you want to make stuff callable for QML or something like 
that it's another story of course.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Are slots even needed these days?

[André Somers]

Op 16/03/2016 om 16:12 schreef Michael Sué:

Hi,


is there a reason to have "public slots:" anymore?

If you build dialogs in Qt Designer,

I do.

you will like the function "connectSlotsByName" - called in the generated ui 
code - to work properly i.e. connect correctly just by the names you give your objects 
and slots.
I don't. Way too much magic by my taste, and it requires naming methods 
after what triggers the method instead of what the method does, which 
IMnsHO is bad practise. So it's near the top of mis-features I would 
like to have removed from Qt, or at least be made optional and explicit 
instead of default and implicit.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MDI Subwindow with border, but no title

[André Somers]

Op 10/03/2016 om 14:25 schreef Murphy, Sean:

Is there a way to remove the title bar from an MDI Subwindow, but retain

the resizable border all the way around? I'm trying to get more screen real
estate for the subwindow contents, and I don't really have any need for
titles. I do however want the user to be able to resize the subwindow.

With
QMdiSubWindow* newSub = mdiArea->addSubWindow(child);
I've tried a couple options:
1.  newSub->setWindowFlags(Qt::CustomizeWindowHint);// hides

buttons, but still leaves larger size

2.  newSub->setWindowFlags(Qt::Window | Qt::FramelessWindowHint);

// hides all window borders so nothing can get resized or moved

Option 1 retains removes the title and minimize/close buttons, but retains

the same height as if those were still there - I'm assuming to present a
separate handle to move the subwindow within the MDI area?

Option 2 removes everything, making it where the user can't move or

resize the sub window.

I'm ok with losing the move handle on the subwindow just to get those

vertical pixels back, I'll figure out some other way to allow the user to move
widgets around.
Try setting a plain QWidget instance as the title bar widget.

How do I replace the title bar widget? Am I looking for a function that does 
this for me, or something else?
Sean

Doh! Sorry, I was confused with using dock widgets. QDockWidget has a 
method to do that.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] MDI Subwindow with border, but no title

[André Somers]

Hi,

Op 09/03/2016 om 17:46 schreef Murphy, Sean:

Is there a way to remove the title bar from an MDI Subwindow, but retain the 
resizable border all the way around? I'm trying to get more screen real estate 
for the subwindow contents, and I don't really have any need for titles. I do 
however want the user to be able to resize the subwindow.

With
   QMdiSubWindow* newSub = mdiArea->addSubWindow(child);
I've tried a couple options:
   1.  newSub->setWindowFlags(Qt::CustomizeWindowHint);// hides buttons, 
but still leaves larger size
   2.  newSub->setWindowFlags(Qt::Window | Qt::FramelessWindowHint);   // hides 
all window borders so nothing can get resized or moved

Option 1 retains removes the title and minimize/close buttons, but retains the 
same height as if those were still there - I'm assuming to present a separate 
handle to move the subwindow within the MDI area?

Option 2 removes everything, making it where the user can't move or resize the 
sub window.

I'm ok with losing the move handle on the subwindow just to get those vertical 
pixels back, I'll figure out some other way to allow the user to move widgets 
around.


Try setting a plain QWidget instance as the title bar widget.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Dynamic translations for mobile apps at runtime?

[André Somers]

Op 08/03/2016 om 23:21 schreef Jason H:

Sounds like there should be a qApp->translations() that we can use to remove 
all currently installed translations? Without it, we have to do what you do.
Just keep the translators you currently have active around, not all of 
them. It is useless to new a QTranslator for languages you are not 
actually using. When switching language, you can remove and then delete 
the already loaded ones after installing the translations for the newly 
selected language.


So, something like this (untested code, typed in email editor):

QString m_currentLanguage;
QVector m_currentTranslations; //note that for any language, you 
may need multiple translation files!

void Backend::selectLanguage( QString language ) {
  if (language == m_currentLanguage)
return;

  QVector oldTranslators = m_currentTranslations;
  m_currentTranslations.clear();

  //repeat for every translation file you need to install, ie for your own app, 
for Qt itself, for libraries...
  translator = new QTranslator(this);
  translator->load( language, commonPath()+"/translations" );
  qApp->installTranslator(translator);
  m_currentTranslations.append(translator);

  //now, get rid of the old translators
  foreach(QTranslator* oldTranslator, oldTranslators) {
qApp->removeTranslator(oldTranslator);
delete oldTranslator;
  }
}



André





Sent: Tuesday, March 08, 2016 at 3:44 PM
From: Gianluca 
To: "Jason H" 
Cc: "interest@qt-project.org" 
Subject: Re: [Interest] Dynamic translations for mobile apps at runtime?

qApp->installTranslator add a new translation into the stack. Does not remove 
the old ones.
So, if the user click 10 times: Italian - English - Italian - English … etc…
you got ten translator into the memory.
That’s because the translation is searched into the order on which the 
translator are installed into the stack.

That’s why I remove everything so there is only one translators at time into 
the memory.

Il giorno 08/mar/2016, alle ore 18:46, Jason H  ha scritto:


I'm wondering why you load all those languages and then remove all but one of 
them? Being a mobile app, I have to be somewhat conscience of memory foot 
print. Do you see anything wrong with:

void Backend::selectLanguage( QString language ) {
translator = new QTranslator(this);
translator->load( language, commonPath()+"/translations" );
qApp->installTranslator(translator);
}

?



Hello Jason,
I got the same issue some times ago … and I found that it’s possible to use the 
translation feature of Qt … that seems static, but it’s not.
And localize.biz it’s a wonderful site that allow you to modify Qt translation 
files directly on web and download the updated one.

The trick to achieve (summarized) is the following:
Somewhere in your code maintain and update from remote an array of Translators:
translators["en"] = new QTranslator(this);
translators["en"]->load( "tr_en", commonPath()+"/translations" );
translators["de"] = new QTranslator(this);
translators["de"]->load( "tr_de", commonPath()+"/translations" );
translators["fr"] = new QTranslator(this);
translators["fr"]->load( "tr_fr", commonPath()+"/translations" );
translators["ru"] = new QTranslator(this);
translators["ru"]->load( "tr_ru", commonPath()+"/translations" );
You can change these entry with new files downloaded at runtime.

Then you implement a method that you call at runtime for changing the 
translator, something like that:

void Backend::selectLanguage( QString language ) {
foreach( QString lang, translators.keys() ) {
if ( lang == language ) {
qApp->installTranslator( translators[lang] );
} else {
qApp->removeTranslator( translators[lang] );
}
}
this->language = language;
emit languageChanged();
}
And then there is the final trick:
You create a “fake” property that is always an empty string but it’s binded to 
languageChanged signal:

Q_PROPERTY( QString es READ getES NOTIFY languageChanged )

And (the most annoying part), append this empty string to all string you want 
to change at runtime like that:

qsTr("NEWSHUB")+backend.es

And close the loop.

What will happen is the following: the translator change at runtime and you 
trigger a languageChanged that trigger an update of all string that got 
backend.es appended that trigger the call of qsTr that take the new translation 
from the new translator.




___
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] reading from and writing to a file with QDataStream

[André Somers]

Op 08/03/2016 om 20:27 schreef Nikita Krupenko:

2016-03-08 19:30 GMT+02:00 Thiago Macieira :

Indeed, but look at how you've combined two or more examples. You have a byte
array, you create a QDataStream on it, write some data, then you used
QDataStream to write that byte array to another byte array. You probably
didn't want that.

It could be useful, if I want to write checksum of the data to the
file. To do this, I can write
some data to the QByteArray wrapped in QDataStream, then calculate
checksum using
qChecksum() (or QCriptographicHash) and then write byte array and
checksum to the file.
Sure, it _could_ be useful, but it is not very likely that this is the 
kind of thing Sina was trying to do... So Thiago is right in saying that 
he _probably_ did not intend to do what he did.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Translating plural with is/are

[André Somers]

Op 08/03/2016 om 20:08 schreef Jason H:



Sent: Tuesday, March 08, 2016 at 1:14 PM
From: "André Somers" <an...@familiesomers.nl>
To: interest@qt-project.org
Subject: Re: [Interest] Translating plural with is/are



Op 08/03/2016 om 18:17 schreef Thiago Macieira:

On terça-feira, 8 de março de 2016 09:06:14 PST Frédéric Marchal wrote:

If for instance I write tr("%n whatever rubbish I type here", "", n)
and the translator decides to translate "%n whatever rubbish I insert
here" with "One message was saved" for singular and "%n messages were
saved" for plural, then, the user will see those last two strings. The
user will never see the original "%n whatever rubbish I insert here"
string from the source code.

When Nokia used Qt, we used to call this translating from "Engineering
English" to "proper English". In some projects, the source strings always
started with "!!", which helped identify what wasn't yet translated in pre-
release builds.


That's actually pretty nice. Also helps to automatically find missing
translations popping up in the GUI using Squish or a similar tool.


That's the kind of insight that should be documented :-)
It's a fantastic idea that isn't obvious at first.

Thanks.
I looked into this exact problem when writing squish tests before, but I 
could not solve this one at the time. I _did_ solve a related issue: 
flagging problematic translations that take more space than is available 
for the widget the text is supposed to appear on. Helped us find lots of 
problems in translations/the ui design where texts were truncated a bit. 
I think something like that got added to squish later on, but we did it 
before that moment.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Translating plural with is/are

[André Somers]

Op 08/03/2016 om 18:17 schreef Thiago Macieira:

On terça-feira, 8 de março de 2016 09:06:14 PST Frédéric Marchal wrote:

If for instance I write tr("%n whatever rubbish I type here", "", n)
and the translator decides to translate "%n whatever rubbish I insert
here" with "One message was saved" for singular and "%n messages were
saved" for plural, then, the user will see those last two strings. The
user will never see the original "%n whatever rubbish I insert here"
string from the source code.

When Nokia used Qt, we used to call this translating from "Engineering
English" to "proper English". In some projects, the source strings always
started with "!!", which helped identify what wasn't yet translated in pre-
release builds.

That's actually pretty nice. Also helps to automatically find missing 
translations popping up in the GUI using Squish or a similar tool.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] reading from and writing to a file with QDataStream

[André Somers]

Op 07/03/2016 om 19:00 schreef william.croc...@analog.com:




 QDataStream out2(); // and module A write those datas to a 
file.

 out2 <<  bai.size();
 out2 <<  bai;




All of the following is IMHO:

I think that if you are going to read the size back as an 'int'
you should insure that an 'int' is written in the first place:

out2 << (int)bai.size();

Sure, you can look and see that the size() of a QByteArray returns
an 'int', but that is only as of today. You should get into the habit
of controlling the types written to QDataStreams.
Actually, for reading and writing binary data files, I think it is wise 
to get into the habbit of using explicitly sized types. That is, write 
out and read back a qint8, a qint32 or a qint64, not an int or a long. 
int and other integer types are not guaranteed to be the same size 
across platforms, so you may get into trouble if you are not explicit 
about how many bytes you want or expect your values to be encoded in.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Translating plural with is/are

[André Somers]

Op 07/03/2016 om 20:25 schreef André Somers:



Op 07/03/2016 om 19:56 schreef Jason H:
If you provide a translation file, the message with %n will be 
translated

according to the language's plural rules. For English, you'll have two
translations for the same source message.

"At least one upper case character is required" (a)
"At least %n upper case characters are required" (b)

QTranslator takes care to apply the correct selection based on the 
number that

you passed.
Ok I'm getting there, but how do I specify this string (a) or that 
string (b)?

What's the qsTr() line look like?
qsTr( ?
It doesn't matter how your string inside the tr or qsTr looks, as long 
as it contains the %n. It is useful for both developers and 
translators if it looks roughly like the string you want out of it but 
that is not strictly needed. You could just make due with 
qsTr("MESSAGE_UPPER_CASE_CHARACTERS %n", n) or something like that 
though I personaly don't like this. It is up to the person filling the 
translation file with translations (including the one for English) to 
make sure that both versions of the definitive string are provided in 
the .ts file.


André
By the way, note that using "one" literally in your translation will 
trigger a warning, as the %n is missing in the translated string. Though 
there are good reasons for it as I understand it, I find that annoying 
but that's how it is.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Translating plural with is/are

[André Somers]

Op 07/03/2016 om 19:56 schreef Jason H:

If you provide a translation file, the message with %n will be translated
according to the language's plural rules. For English, you'll have two
translations for the same source message.

"At least one upper case character is required" (a)
"At least %n upper case characters are required" (b)

QTranslator takes care to apply the correct selection based on the number that
you passed.

Ok I'm getting there, but how do I specify this string (a) or that string (b)?
What's the qsTr() line look like?
qsTr( ?
It doesn't matter how your string inside the tr or qsTr looks, as long 
as it contains the %n. It is useful for both developers and translators 
if it looks roughly like the string you want out of it but that is not 
strictly needed. You could just make due with 
qsTr("MESSAGE_UPPER_CASE_CHARACTERS %n", n) or something like that 
though I personaly don't like this. It is up to the person filling the 
translation file with translations (including the one for English) to 
make sure that both versions of the definitive string are provided in 
the .ts file.


André


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Regarding QtreeWidget

[André Somers]

Op 04/03/2016 om 13:20 schreef william.croc...@analog.com:

On 03/04/2016 03:06 AM, Roshni Lalwani wrote:
I have application in which I am planning to use a QtreeWidget . The 
maxinum
number of elements in the treeWidget can go uptp 500 . COuld you let 
me how will
be performance of using QtreeWidget for 500 elements . Will it lead 
to some

performance degradation



Use a QTreeView with an underlying model and performance of the tree 
widget

will no longer be a concern.


Nonsense.
It all depends on your implementation of the model then, and writing 
good tree models is not trivial. I agree that generally a "real" model 
is much to be prefered, but your statement as-is doesn't make much sense 
to me.


I think the merrits of QTreeWidget (and all the view like Q*Widget 
classes) is debatable, but I don't think performance is the major pain 
point here. I would recommend to consider using QStandardItemModel with 
a QTreeView instead if you like the item-based API that much. Also, 
consider wrapping it up in your own model subclass with a sane API that 
suits your application, instead of filling and accessing your model from 
different places in otherwise unrelated code. This will make it easier 
to swap out the QStandardItemModel based model for a custom model later 
on if needed.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to create QObject-derived class instance from class name

[André Somers]

Op 02/03/2016 om 11:51 schreef Sina Dogru:


>For now there is a design choice which I feel weak myself, to do
factory or to use QMetaType for creating instances.

Depends on the use case I suppose. If you know the types at
compile time, as is usually the case I'd go with the simple
solution to make a factory. I recently, however, had a case where
the deserialization routine couldn't know at compile time the
exact type (i.e. for a library), so I had to put a (gadget) base
class and use the runtime type ids.


Since I'm trying to recover states of the QObject-derived class 
instances from a file, it is not possible to know the types at compile 
time. But is not that factory was also for creating objects that type 
is known at run-time? Or am I missing something? Because I thought 
both factory and metaobject system provide run-time object creation?
You are right. If you know the type you need at compile time, just 
construct the instance directly.
Factories are useful for the creation of objects who's types you do 
_not_ know at compile time. And indeed, as demonstrated above, the 
metaobject system together with the metatype system can also be abused 
to do the same thing.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to create QObject-derived class instance from class name

[André Somers]

Op 01/03/2016 om 17:21 schreef Thiago Macieira:

On terça-feira, 1 de março de 2016 17:06:49 PST André Somers wrote:

The meta *object* system has no registration.

The meta *type* system requires that the registered type be default-
constructible and copyable, but QObject is not copyable. Therefore,
QObject- derived classes cannot be registered with the meta type system.

Am I completely misinterpretting the documentation then?
http://doc.qt.io/qt-5/qmetatype.html#metaObject

If I read that correctly, you can register a
pointer-to-a-QObject-derived-class-instance and use that. So, indeed,
you do not register the type, but the type*. And that has no problems
with being default constructed or copied.

Correct. You can't register a QObject class with the meta type system, but you
can register a pointer to a QObject class. The problem is that
QMetaType::create() will then create a pointer, not the object.
Of course. But... Again, if I read it correctly, you *can* then get the 
QMetaObject from QMetaType, and using that, you can create an actual 
instance.


Just tested this trivial example:

//main.cpp
int main(int argc, char *argv[])
{
qRegisterMetaType<TestClass*>(); //this could be elsewhere of course

QCoreApplication a(argc, argv);

auto tId = QMetaType::type("TestClass*"); //just using the class 
name with an *

auto metaObject = QMetaType::metaObjectForType(tId);
QObject* instance = metaObject->newInstance();

return a.exec();
delete instance;
}

//testclass.h
class TestClass: public QObject
{
Q_OBJECT

public:
Q_INVOKABLE TestClass();
};

Q_DECLARE_METATYPE(TestClass*)

//testclass.cpp
TestClass::TestClass()
{
qDebug() << "TestClass instance created";
}

Which prints out "TestClass instance created" on the console. My 
conclusion is that it works, and that you _can_ create a QObject derived 
instance with just the class name.


Again: I am not claiming that abusing this to skip defining a factory is 
a good idea. Just that it is possible.



André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to create QObject-derived class instance from class name

[André Somers]

Op 01/03/2016 om 16:30 schreef Thiago Macieira:

On terça-feira, 1 de março de 2016 13:59:07 PST André Somers wrote:

I think you did not get the point about QMetaType and QMetaObject. They
_can_ be used together:

I don't think that they can.


1) mark the constructors in the classes you want to be able to construct
from your file as Q_INVOKABLE
2) register the types in the meta object system

The meta *object* system has no registration.

The meta *type* system requires that the registered type be default-
constructible and copyable, but QObject is not copyable. Therefore, QObject-
derived classes cannot be registered with the meta type system.

Am I completely misinterpretting the documentation then?
http://doc.qt.io/qt-5/qmetatype.html#metaObject

If I read that correctly, you can register a 
pointer-to-a-QObject-derived-class-instance and use that. So, indeed, 
you do not register the type, but the type*. And that has no problems 
with being default constructed or copied.


I have not tried this at home, so to speak. Perhaps I should.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] How to create QObject-derived class instance from class name

[André Somers]

Op 01/03/2016 om 13:40 schreef Sina Dogru:

Hello everyone,

Basically, I have a file which I do save some QObject-derived 
instances states. I do save them to be able to use those to recover 
the states of those QObject-derived instances.


I do also save the QMetaObject::className() in the file. And at the 
run-time, I would like to dynamically create QObject-derived instances 
from the file.


After a short research on the qt docs, I have ended to use 
QMetaType::create() but after tried it, it failed because of this was 
not for QObject.. So finally I got the point, QMetaObject is for 
QObjects and QMetaType for the others.. But could not find a propert 
QMetaObject API to create an instance from string..


Also there is stackoverflow question 
 
but the answers are not seems like so elegant.


So I have decided to ask your advices how to create QObject-derived 
class instance dynamically from a string or class name, even with my 
that terrible english, I hope you don't mind it.
I think you did not get the point about QMetaType and QMetaObject. They 
_can_ be used together:


1) mark the constructors in the classes you want to be able to construct 
from your file as Q_INVOKABLE

2) register the types in the meta object system
3) get the meta type from the QMetaType using the class name
4) use the meta type to get the QMetaObject
5) use QMetaObject::construct to construct an instance of the type, 
making sure you pass the correct arguments


However, I think you are probably better off just using a factory pattern.

I hope this helps.

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] moveToThread used in constructor to move "this"

[André Somers]

Op 24/02/2016 om 18:23 schreef Thiago Macieira:

On quarta-feira, 24 de fevereiro de 2016 10:22:18 PST Lorenz Haas wrote:

Foo() : QObject(nullptr) {
   moveToThread(_thread);
   m_thread.start();
}

~Foo() {
   m_thread.quit();
   m_thread.wait();
}

This destructor is either never run or deadlocks.

A QObject can only be destroyed in its thread of affinity. So the above is
running in that m_thread thread, which means it hasn't exited. Waiting for it
to exit will wait forever.


Thanks indeed; I did not spot this issue either.

Would it be possible to circumvent this issue by moving the thread 
object onto its own thread too?


   Foo() : QObject(nullptr) {
  moveToThread(_thread);
  m_thread->moveToThread(m_thread);
  m_thread.start();
   }


Looks like the much debated move-QThread-onto-its-own-thread 
antipattern, but it's not the same obviously.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] moveToThread used in constructor to move "this"

[André Somers]

Op 24/02/2016 om 10:22 schreef Lorenz Haas:

Hi André,


That should work just fine, with the exception of using _thread as a
member.

thanks for your answer. I am, however, not sure what you mean
regarding the m_thread member. For a better understanding here is a
working example I have in mind:

Ah, so you want a per-object thread.
I guess your design is possible. I'm not sure it is a good idea though. 
Depending on what API you expose, you will have to assume that the 
methods called on your class are called from another thread. Or, worse, 
the caller needs to be aware of that. That gets ugly quite fast if the 
things you want to expose are not as trivial as your example below...


André



**
#include 

class Foo : public QObject
{
Q_OBJECT
public:
Foo() : QObject(nullptr) {
   moveToThread(_thread);
   m_thread.start();
}

~Foo() {
   m_thread.quit();
   m_thread.wait();
}

void printFooInformation() const {
   qDebug() << "foo affinity" << thread();
}

void printThreadInformation() const {
   qDebug() << "m_thread affinity" << m_thread.thread();
}

private:
QThread m_thread;
};

int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
qDebug() << "GUI affinity" << a.thread();
Foo *foo = new Foo;
foo->printThreadInformation();
foo->printFooInformation();
return a.exec();
}

#include "main.moc"
**

Of course, every instance of Foo would create a new thread and
therefor multiple instance of Foo would _not_ share the same thread.
Did you mean that? (In my special case this is intended.)

Lorenz


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] moveToThread used in constructor to move "this"

[André Somers]

Op 24/02/2016 om 09:39 schreef Lorenz Haas:

Hi,

keep calm, it is not about moveToThread(this) :)

One canonical way to use QObjects and QThreads is this

void SomeClass::init() {
 // m_thread is a member of SomeClass
 Foo *foo = new Foo; // Foo inherits QObject
 foo->moveToThread(_thread);
}

So in my case I want that an instance of Foo is always moved to a
(single) thread. In order to take this knowledge/requirement - as well
as the boilerplate code - from the caller (here SomeClass::init) I am
curious if this is would be a valid substitution:

Foo::Foo() : QObject(nullptr) {
 // m_thread is now a member of Foo
 moveToThread(_thread);
}

void SomeClass::init() {
 Foo *foo = new Foo;
}


I guess that in the constructor of Foo the base class QObject is
already instantiated and since moveToThread only has implications on
QObject it should be right.
Can any one with deeper QThread insight confirm that using
moveToThread in a constructor like above is safe?

That should work just fine, with the exception of using _thread as a 
member. If you want to use the class as you write it above, then there 
is no way to set that member. You will probably need to use some form of 
a static here, either inside the class itself if you don't need control 
over the actual thread creation itself, or externally, perhaps wrapped 
in some kind of singleton.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QApplication.activeWindow().pos() not returning correct value after sacling on OSX

[André Somers]

Op 18/02/2016 om 05:33 schreef Scott Aron Bloom:


If you know the parent, you can use parent->mapToGlobal( QRect ) to 
find the global rectangle.



You don't need to know the parent if you call mapToGlobal on the widget 
itself, using a rectangle with the right size at origin (0,0).


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Customize QTableView selection color

[André Somers]

Op 05/02/2016 om 23:43 schreef Murphy, Sean:

I’m still struggling with how to customize the selection color for items on a
QTableView

I use a QStyledItemDelegate.
In the paint(painter,option,index) method I create my own QPalette based
on
selection etc and then call the base class paint function.

  QStyleOptionViewItemV4 subop = option;
  QPalette pal = qApp->palette();
  if( selected ) {
 pal.setColor(QPalette::Highlight,Qt::darkGray);
 pal.setColor(QPalette::WindowText,Qt::white);
 pal.setColor(QPalette::HighlightedText,Qt::white);
 pal.setColor(QPalette::Text,Qt::white);
 subop.state |= QStyle::State_Selected;
 subop.palette = pal;
 }

 BaseClass::paint(painter,subop,index); // Note: subop.


(previously posted as
http://lists.qt-project.org/pipermail/interest/2016-January/020760.html). I
currently color the rows with custom colors based on the data being shown

in

each row in my model’s data(const QModelIndex , int role)

when role ==

Qt::BackgroundRole.

For future readers, which will probably be me again 6 months from now, all I 
needed was

to do exactly what I told you to do on the 5th:

to create a QStyledItemDelegate with paint() reimplemented as follows:

"A QStyledItemDelegate doing a similar trick would work as well."


void customStyledItemDelegate::paint(QPainter *painter, const QStyleOptionViewItem 
, const QModelIndex ) const
{
 QStyleOptionViewItem subop(option);

" Just make a copy of the style option,"

 subop.state &= ~(QStyle::State_Selected);

" reset the selection flag in the state variable"

 QStyledItemDelegate::paint(painter, subop, index);

"and pass that on to the base class."

}

Then when an item is selected, it just gets painted the same as the model's 
Background and Foreground roles was already telling it to.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Customize QTableView selection color

[André Somers]

Op 05/02/2016 om 17:39 schreef Murphy, Sean:

If I understand you correctly, you basicaly want the color of the row to be 
whatever it was before it was selected, right?

Can't you just use a QProxyStyle and reset the selected flag from the style 
option before you pass on the render command to the underlying style?  Have the 
selection work, but not be visible. A QStyledItemDelegate doing a similar trick
would work as well. Just make a copy of the style option, reset the selection 
flag in the state variable, and pass that on to the base class.

I'll try that. As I said in the post I made on January 29th, I was completely 
getting lost between who's responsibility it is to customize these things: 
stylesheets, QStyle, QStyledItemDelegate, the model, the view itself, etc. So 
this is helpful to at least get thing narrowed down.


Well, there are several ways to do the same thing... A brief overview.

I'd avoid style sheets. They are slow, and full of nasty little 
suprises. It is easy to get started with, but hard to maintain in the 
long run.
Styles give you more control how stuff looks. They are harder to write, 
but easier to maintain in the long run. And using a proxy style, you can 
also tweak existing styles where needed, making the entry barrier lower.
Models can also suggest some formatting for items. Use sparingly. It 
really should not be the model's task to determine the presentation.
The actual rendering of items in the view is done by delegates. 
Delegates can completely determine how items look and what is displayed, 
but usually they defer to the style for that. They can be very powerfull 
to render non-standard items, modify data before it is rendered, etc. 
The QStyledItemDelegate is the standard delegate that takes things like 
style sheets into account.


So, you have multiple angles of attack here.

André



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Customize QTableView selection color

[André Somers]

Op 05/02/2016 om 16:34 schreef Murphy, Sean:


I’m still struggling with how to customize the selection color for 
items on a QTableView (previously posted as 
http://lists.qt-project.org/pipermail/interest/2016-January/020760.html). 
I currently color the rows with custom colors based on the data being 
shown in each row in my model’s data(const QModelIndex , int 
role) when role == Qt::BackgroundRole.


I’d like for that color to persist when the user selects a row; so 
either I want the selection to only paint the dotted line around the 
entire row without changing the background color to the OS’s default 
selection color, or I’d also be fine if there was no change at allwhen 
the row is selected. The only reason I allow rows to be selected at 
all is apparently that is required to allow the user to start a drag 
on a row when they are attempting to reorder the rows in the table. I 
can’t seem to figure out where this needs to happen.


Correct me if I’m wrong on any of the following:

1.I can’t use a stylesheet because the colors are different on a 
row-by-row basis


2.I don’t think the selection background color is controlled anywhere 
in the model?


3.I really don’t have any need for the user to be able to select 
anything – the table is meant to be a read-only display of data - 
EXCEPT it appears that being able to select items is a requirement for 
the drag-n-drop system?


Any pointers?

Sean


If I understand you correctly, you basicaly want the color of the row to 
be whatever it was before it was selected, right?


Can't you just use a QProxyStyle and reset the selected flag from the 
style option before you pass on the render command to the underlying 
style?  Have the selection work, but not be visible. A 
QStyledItemDelegate doing a similar trick would work as well. Just make 
a copy of the style option, reset the selection flag in the state 
variable, and pass that on to the base class.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] x-platform way to pull app version?

[André Somers]

Easiest is to let your buildsystem generate some cpp code with the version 
numbers in each build. We compiled in version number, git id an time & date 
with a simple script called from qmake on every build. 

André

Verstuurd vanaf mijn iPhone

> Op 1 feb. 2016 om 16:35 heeft "Jason H"  het volgende 
> geschreven:
> 
> Currently, I have a string that I have to manually maintain, is there a way I 
> can call some function and get my application version (that's in the plist or 
> manifest)?
> ___
> 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] QWizard - Circular Page Flow

[André Somers]

I solved a similar requirement once by programmatically calling back until 
reaching the start again. Downside is that the real back doesn't work anymore 
either then. Alternatively, you could make your wizard more dynamic: simply 
insert new instances of pages 1 to 3 as needed, and give them new id's. Then 
you can navigate there. 

André

> Op 29 jan. 2016 om 19:47 heeft Joey Kleingers  
> het volgende geschreven:
> 
> Hello,
> 
> I have a QWizard subclass and four QWizardPage subclasses.  I created an 
> instance of each QWizardPage subclass and added it to the QWizard.
> 
> Instead of using this page flow:
> 
> Page 1 > Page 2 > Page 3 > Page 4
> 
> I would like to instead use this page flow:
> 
> Page 1 > Page 2 > Page 3 > Page 1 > Page 2 > Page 3 > 
> Page 4
> 
> where Page 1, Page 2, and Page 3 make a circular flow until some condition is 
> met to go to Page 4.
> 
> I have tried reimplementing the QWizardPage::nextId() function on Page 
> 3...but when I return Page 1's id from that function, it simply repeats Page 
> 3.  It won't let me go back to Page 1.
> 
> Is there a solution to this problem???  I am using Qt 5.5.1.
> 
> Many thanks,
> Joey
> ___
> 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

[Interest] Qt component repositories (was: Re: QtArg version 2.0.0)

[André Somers]

Op 26/01/2016 om 13:00 schreef Ben Lau:



Moreover, will you consider to publish your library on qpm.io 
 ?




What's the difference between qpm.io and inqlude.org?

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Add margin spacing between QComboBox item icon and text ?

[André Somers]

Op 20/01/2016 om 15:46 schreef william.croc...@analog.com:




I do not remember why I added a styleSheet. Perhaps to make it more 
fat-finger

touch-friendly for Android or iOS. Anyway, I must re-think and re-test.


I always tell my customers to stay away from style sheets. They are 
way more

trouble than what they are worth.



My complaint:

Some things can be done both with a function call on a widget or
by applying a style sheet. This is good.

Other things can only be done using a style sheet.
This is bad because it forces the use a style sheet
and the application of a style sheet will fail quietly
if you make a syntax error. Even if your theory is right on.

I use C++ because I want a strongly typed language which complains during
compilation over a large class of mistakes. The style sheet processor 
never

says a dam thing no matter how much garbage I give it.
Everything you can do with a style sheet can also be done using a 
QStyle, or a QProxyStyle.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[André Somers]

Op 14/01/2016 om 01:08 schreef Stephen Kelly:

Bo Thorsen wrote:

To me QStandardItemModel is a quick hack I sometimes use when I just
want to show a bit on the screen. But those temporary things have a
tendency to stick around, and at some point I always end up rewriting
the stuff with the real thing.

Me too. I only ever use QSIM in test code to provide 'fake data'.

As do I, but I do find it an improvement over using the Widget variants 
of the views...


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] User comments on web pages?

[André Somers]

Op 13/01/2016 om 00:00 schreef Jason H:

For handling multi-languages: you don't. The Qt documentation is in
English, just as the API itself. Why would you support comments in other
languages? If people can read the documentation to begin with, they can
also read comments in English.


Not exactly correct. See top of: https://wiki.qt.io/Qt_Coding_Style
That's a wiki page, and those can indeed be translated. Interested users 
have been doing that since there were wiki pages. Support for that has 
improved thankfully as the translations were making a mess of the 
original wiki. AFAIK, there has not been a full translation of the core 
API documentation.


But of course: one _could_ handle multiple languages. I just doubt it 
would add value. In fact, I think it deminishes value. It is very useful 
for me if a developer from, say, China, makes a relevant comment, even 
if the English is not great. That could even be improved by another user 
with a better command of the language. It is noise for me if that 
comment were to be in one of the Chinese languages and it creates a 
devide in the community once again.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] User comments on web pages?

[André Somers]

Op 12/01/2016 om 15:57 schreef Jason H:

There are a few things I'd like to add to the documentation, but the barrier to 
entry is too high.
I'm wondering if we could allow comments by users (or those with bugreports 
account, or has an an account and is authorized) to be able to comment on the 
online help? I found the PHP comments helpful, when they were not completely 
off-base (let's face it, it's PHP :-))

It would also be cool is QtCreator could fetch these (assuming it ends up 
happening)


This functionality used to exist, but it was scrapped when the move to 
the new website happened. There was lots of valuable contents there, and 
I know I for one was quite pissed off that my contributions there were 
no longer available. So, it is unfortunate, but don't count on this 
happening any time soon.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] User comments on web pages?

[André Somers]

Op 12/01/2016 om 16:17 schreef Gian Maxera:

On 12 Jan 2016, at 15:11, André Somers <an...@familiesomers.nl> wrote:



Op 12/01/2016 om 15:57 schreef Jason H:

There are a few things I'd like to add to the documentation, but the barrier to 
entry is too high.
I'm wondering if we could allow comments by users (or those with bugreports 
account, or has an an account and is authorized) to be able to comment on the 
online help? I found the PHP comments helpful, when they were not completely 
off-base (let's face it, it's PHP :-))

It would also be cool is QtCreator could fetch these (assuming it ends up 
happening)

This functionality used to exist, but it was scrapped when the move to the new 
website happened. There was lots of valuable contents there, and I know I for 
one was quite pissed off that my contributions there were no longer available. 
So, it is unfortunate, but don't count on this happening any time soon.

I use a lot Qt Assistant … so, never knew such comments were on the old website.

I really like the idea to see the comments on Qt Assistant … I hope in the 
future there will be a way to see user’s comments directly into Qt Assistant… 
but it’s not easy. How can you manage multi-languages ?


I filed a feature request for that a couple of years ago too (I also 
prefer the offline documentation), but as the web version got scrapped, 
I believe this request also got closed.


For handling multi-languages: you don't. The Qt documentation is in 
English, just as the API itself. Why would you support comments in other 
languages? If people can read the documentation to begin with, they can 
also read comments in English.



André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating a transparent "hole" in QML Scene Graph

[André Somers]

Op 23/12/2015 om 20:32 schreef Konstantin Tokarev:

Hi all,

I'm running QML on embedded device (IPTV set-top box) which has separate 
hardware layer fo video output, placed under UI layer where QML paints.

Now I'd like create QML item providing transparent "hole", i.e. transparent rect hich 
would not blend with content underneath, but "erasing" it (so that video layer becomes 
unobscured).

In widgets API I could draw transparent rect with QPainter using 
CompositionMode_Clear. Is it possible to achieve the same thing in QML? 
Solution (ab)using private APIs is acceptable for me.


Couldn't you just not have items in your scenegraph in that rect?

Otherwise a solution using a shader to just delete the fragments 
(pixels) in the area of interest comes to mind, but I have no experience 
writing those. ShaderEffect may be of help there.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Unnecessary repaints.

[André Somers]

Op 17/12/2015 om 12:55 schreef Bill Crocker:

Hello:

My very first Qt app is large and a little sloppy in
that the QWidget::update() function is being called
*someplace* where it should not, This is causing
unnecessary repaints.

Is there one place I can put a break to find the calls
which actually cause a repaint (and not the calls
which are made when a repaint is already pending).

Or, can you recommend a better way to diagnose
this problem. (The whole thing needs to be rewritten
now that I am older and wiser, but not just yet.)

I'd try to log calls to update() on the widget, and dump the stacktrack 
for each of those to a file. You can do that (at least on gdb) by 
setting a breakpoint on it with some commands to run on the breakpoint, 
after wich you immediately resume. If you really break, it will be much 
harder to trace as returning to the running application afterwards will 
itself cause a repaint. Run your app for a bit, and inspect the file to 
see how your update got called.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QFileDialog Qt5

[André Somers]

Op 16/12/2015 om 15:02 schreef Duane:

On 16/12/2015 8:53 AM, Thiago Macieira wrote:

On Wednesday 16 December 2015 08:10:44 Duane wrote:

I'm subclassing a QFileDialog.  I need to get a pointer to the filename
box.  I was doing this with findChild() with Qt4 but with
Qt5 this returns null.  Any suggestions?


XY problem. Why do you need to get the pointer to the line edit? What 
are you

trying to do?



Not sure what you mean by XY problem.

http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem

André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QFileDialog Qt5

[André Somers]

Op 16/12/2015 om 14:10 schreef Duane:
I'm subclassing a QFileDialog.  I need to get a pointer to the 
filename box.  I was doing this with findChild()  with Qt4 
but with Qt5 this returns null.  Any suggestions?
Are you sure you are not getting a native file dialog? If so, then 
obviously there are no child widgets...


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Subclassing QTreeWidgetItem together with QObject

[André Somers]

Op 27/11/2015 om 17:15 schreef Igor Mironchik:





Or is there a better way to do what I described?

Thanks in advance,

Can you point out to what the signals/slots do you want to have?

I just need one slot in it to be able to trigger update of displayed
columns for that item/row in the treeview.

Regards,


As André Somers wrote why not to implement custom model for this? ...

You may also be able to just use a lambda function connected to the 
changed signal of your data to do the same.  At the point where you 
build up your tree, you should have access to both the source object and 
the item that represents it in the tree, so you could add a connection 
to a lambda there.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest