Suitable "editable list" widget?
-
@JonB
use QListWidget for example
for adding: listWidget->insertItem(listWidget->count(), item);
for removing: listWIdget->removeItemWidget(listWidget->currentItem())or QListView with a custom model, but this is more work to implement the model correctly
@raven-worx
I know how to doinsert/removeItem()programmatically, that's not the question. The question is the user interface --- presenting a "delete/edit" against each item/row, and a "add new row" at the bottom of the whole list or in a dummy item at the end or whatever.I'm pasting an example into my original post....
-
Hi,
The usual thing to do (and you can find that for example in macOS's interface) is to have a + and - buttons at the bottom or the top of your QTableWidget/View to add/remove element. The - button being only enabled when something is selected.
Do you mean you want the "Select" text on your button or have a hint with
...on the second column ? -
Hi,
The usual thing to do (and you can find that for example in macOS's interface) is to have a + and - buttons at the bottom or the top of your QTableWidget/View to add/remove element. The - button being only enabled when something is selected.
Do you mean you want the "Select" text on your button or have a hint with
...on the second column ?-
OK, the way you approach it is to have just one table-wide button to do something, and rely on a current item being selected by the user. My way (inherited from ASP.NET) is not to have a selection and instead have necessary buttons on each row. I didn't think of yours. If that's more usual, and it sounds simpler, I'll do it that way. Also if I won't need columns for buttons, I could just have a simple
QListWidgetinstead of aQTableViewsince I only have one data item cell, sounds good! -
For the "selection" case. Instead of just typing into the data cell, the user needs something to click to take him to a dialog. I don't much care what that is. I was thinking of a
...button say to the right of each cell. But that will introduce a new column/widget, it won't be so easy to just do asQListWidget, and I don't know ifQTableViewallows columns just for widgets instead of the data. However, your new way I could just add one...button, like one add and one delete, at table-level to use on whatever row is selected, which would solve.
My one reservation is user having to understand that buttons for doing stuff on whatever is selected are at top/bottom. It saves on space, but it doesn't seem so immediately intuitive to me as having the buttons on each row. I don't use mobiles/Apples :) Is that a good way to do it? Anyone have a screenshot of what it looks like on some device? :)
-
-
For an intuitive insertion-at-bottom interface you can have a look at this library using Insert Proxy Model (I'm trying to also get this proxy included in Qt 5.13). You can find example usage here
for the remove/edit buttons you can use KExtraColumnsProxyModel from the KDE library (that module works on all platforms). You just need to return a pixmap as
Qt::DecorationRolefor theextraColumnData()and connect the clicked signal of the view to a slot that deletes the row or changes theflags()of the model to make it editable.Basically:
source model -> KExtraColumnsProxyModel -> InsertProxyModel -> viewor
source model -> KExtraColumnsProxyModel -> view
if you want the insert button as you have the edit and delete ones"La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
~Napoleon BonaparteOn a crusade to banish setIndexWidget() from the holy land of Qt
-
For an intuitive insertion-at-bottom interface you can have a look at this library using Insert Proxy Model (I'm trying to also get this proxy included in Qt 5.13). You can find example usage here
for the remove/edit buttons you can use KExtraColumnsProxyModel from the KDE library (that module works on all platforms). You just need to return a pixmap as
Qt::DecorationRolefor theextraColumnData()and connect the clicked signal of the view to a slot that deletes the row or changes theflags()of the model to make it editable.Basically:
source model -> KExtraColumnsProxyModel -> InsertProxyModel -> viewor
source model -> KExtraColumnsProxyModel -> view
if you want the insert button as you have the edit and delete ones@VRonin
Thank you for your detailed answer. In my case I did say I don't want to have to bring in new libraries, like the KDE one. Remember I'm also Python/PyQt, makes life much harder. I realise that's my choice.I think I can roll my own adequately if I follow @SGaist's interface, and use row selection with a table-level button acting on it. Avoid columns and do the whole thing as a
QListWidgethopefully.Yours is probably closest to what I am used to. (And I have noticed that KDE seems to be what offers the "extra stuff you can do with columns" etc. I am used to compared to Qt's in-builts.) But it breaks my "minimal code" desire, no offence intended!
-
-
OK, the way you approach it is to have just one table-wide button to do something, and rely on a current item being selected by the user. My way (inherited from ASP.NET) is not to have a selection and instead have necessary buttons on each row. I didn't think of yours. If that's more usual, and it sounds simpler, I'll do it that way. Also if I won't need columns for buttons, I could just have a simple
QListWidgetinstead of aQTableViewsince I only have one data item cell, sounds good! -
For the "selection" case. Instead of just typing into the data cell, the user needs something to click to take him to a dialog. I don't much care what that is. I was thinking of a
...button say to the right of each cell. But that will introduce a new column/widget, it won't be so easy to just do asQListWidget, and I don't know ifQTableViewallows columns just for widgets instead of the data. However, your new way I could just add one...button, like one add and one delete, at table-level to use on whatever row is selected, which would solve.
My one reservation is user having to understand that buttons for doing stuff on whatever is selected are at top/bottom. It saves on space, but it doesn't seem so immediately intuitive to me as having the buttons on each row. I don't use mobiles/Apples :) Is that a good way to do it? Anyone have a screenshot of what it looks like on some device? :)
@JonB said in Suitable "editable list" widget?:
My one reservation is user having to understand that buttons for doing stuff on whatever is selected are at top/bottom. It saves on space, but it doesn't seem so immediately intuitive
Well, quite often when working with tables you have context menus for that purpose. Take excel or open office spreadsheets as an example. There are 3 elements that are "duplicates" to make the UI as intuitive as possible for inserting rows above/below selection and deleting the selected row (just an example, but it applies to other operations as well):
- The menu - you get an entry that's enabled/disabled.
- The toolbar - same thing, but you have a button and and an icon (usually it's customizable as well).
- Context menu - right clicking gives you options pertaining to this particular UI element (like the main menu, but shorter).
As a side kick, which I intentionally didn't include in the above list:
- Keyboard shortcut(s) - yet another way to trigger one of the above
So my best advice is to implement all of those (if possible).
Read and abide by the Qt Code of Conduct
-
-
@JonB said in Suitable "editable list" widget?:
My one reservation is user having to understand that buttons for doing stuff on whatever is selected are at top/bottom. It saves on space, but it doesn't seem so immediately intuitive
Well, quite often when working with tables you have context menus for that purpose. Take excel or open office spreadsheets as an example. There are 3 elements that are "duplicates" to make the UI as intuitive as possible for inserting rows above/below selection and deleting the selected row (just an example, but it applies to other operations as well):
- The menu - you get an entry that's enabled/disabled.
- The toolbar - same thing, but you have a button and and an icon (usually it's customizable as well).
- Context menu - right clicking gives you options pertaining to this particular UI element (like the main menu, but shorter).
As a side kick, which I intentionally didn't include in the above list:
- Keyboard shortcut(s) - yet another way to trigger one of the above
So my best advice is to implement all of those (if possible).
-
@kshegunov
So: menu, toolbar, context menu & keyboard shortcut. That will all fit it into the 5 lines of code I expect to have to write to get this going, right?@JonB said in Suitable "editable list" widget?:
That will all fit it into the 5 lines of code I expect to have to write to get this going, right?
Right. But when was the real solution as simple as we thought initially? Does such a unicorn exist?
Seriously though, it boils down to creating one
QActionand just adding it wherever it's supposed to go - menu, context menu, toolbar w/e.Read and abide by the Qt Code of Conduct
-
@JonB said in Suitable "editable list" widget?:
That will all fit it into the 5 lines of code I expect to have to write to get this going, right?
Right. But when was the real solution as simple as we thought initially? Does such a unicorn exist?
Seriously though, it boils down to creating one
QActionand just adding it wherever it's supposed to go - menu, context menu, toolbar w/e.@kshegunov
I was about to plonk down oneQListWidget/QTableWidgetplus a couple ofQPushButtons below it to do add/delete row in theirclicked()signal's slot (right?). Why do I want/what benefit will I gain if I introduce aQAction? Sorry if this is dumb, I may have forgotten.... -
@kshegunov
I was about to plonk down oneQListWidget/QTableWidgetplus a couple ofQPushButtons below it to do add/delete row in theirclicked()signal's slot (right?). Why do I want/what benefit will I gain if I introduce aQAction? Sorry if this is dumb, I may have forgotten....@JonB said in Suitable "editable list" widget?:
Why do I want/what benefit will I gain if I introduce a QAction?
to reuse the functionality in a menubar/toolbar/contextmenu for example
--- SUPPORT REQUESTS VIA CHAT WILL BE IGNORED ---
If you have a question please use the forum so others can benefit from the solution in the future -
@JonB said in Suitable "editable list" widget?:
Why do I want/what benefit will I gain if I introduce a QAction?
to reuse the functionality in a menubar/toolbar/contextmenu for example
@raven-worx
Yep, got it, thought so. So it's up to me: if I never want those (for right or for wrong) and only doclicked, I don't need aQAction.
