Implementing a QLongLongSpinBox and a QULongLongSpinBox



  • Hi guys,

    A couple of years ago I needed to implement a SpinBox that would handle long long int and unsigned long long int. So I inherited from QAbstractSpinBox and reimplemented the right methods and stores the manipulated values. Back then I already knew it sounded like a patch-up job. I wanted to use d pointer and private classes, even though I didn't really know how to do it.

    After two other years of development with Qt, I'm now comfortable with the basic mechanisms and I think I'm ready to implement it correctly, i.e. within Qt source code. Here are the benefits of this:

    • learn how Qt works internally (getting my hands dirty)
    • modestly improve SpinBox possibilities and offer it to other users
    • learn how to contribute to Qt source code

    But before getting down the heart of the matter, I also know that the widgets part is kind of frozen. it's quite stable, and there are higher priorities for new features. So here is my first question: are these SpinBoxes interesting enough to be integrated or will they be rejected anyway?
    According to the answers, I'll have more questions whether code-oriented or process-oriented.



  • hi @ValentinMichelet,
    I was not personally there, but as far as I have heard, one of the bigger topics during the Qt-contributor meeting, part of the Qt-WorldSummit this year, was the future of QWidget.

    And from what I've heared, it was said, that it should get an increased focus again. QML was the focus of R&D in the last years. Now that it has caught up, in most areas, and surpassed Widgets in some areas. QWidgets shall get some more love.

    So you'r contribution is most probably appreciated :-)


  • Lifetime Qt Champion

    Hi,

    They are not frozen, and a new team of maintainers has been announced earlier this year.

    So go ahead and try it, even if they get rejected for some reasons, you'll have an answer from the developers (the forum is not the best place to ask for that since it's more user oriented).

    In any case, you'll have all the other benefits you cited (learning, contributing etc.).



  • Thanks @J-Hilk and @SGaist for you answers, this is a great news!
    FYI, I'm finishing the implementation of QLongLongSpinBox, and everything seems to work so far.

    I'm currently reading http://wiki.qt.io/Git_Introduction and http://wiki.qt.io/Gerrit_Introduction

    So next steps are:

    • checkout git repository on my computer
    • develop QLongLongSpinBox on a branch
    • commit code
    • use gerrit to submit my branch in order to be reviewed
    • discuss code with reviewers

    Is that it?

    Also, I'm not sure if I have to create qlonglongspinbox.cpp and qlonglongspinbox.h files or if I can add the classes inside qspinbox.cpp and qspinbox.h files. But I guess I'll take a decision on my own, submit it and then the code review is here to answer this kind of questions, right?



  • @ValentinMichelet +1 for your desire to contribute Qt code!
    In addition to your pretty good list of items to do, please don't forget to add some good unit tests, specially for edge cases...


  • Lifetime Qt Champion

    Since all other spin boxes are in in qspingbox.h/cpp, I'd start by putting your new widgets there.



  • @Pablo-J-Rogina Sure thing, I will definitely add robust unit tests.

    @SGaist That's what I did, moreover it's easier to add code in existing files rather than create new files.



  • @ValentinMichelet

    Hi, and thanks for considering your addition to Qt!

    I think you are on the right track process-wise. I just want to make you think about the implementation.

    For now we have QSpinBox and QDoubleSpinBox, right? What would be the difference between QSpinBox and QLongLongSpinBox? And do we need a QULongLongSpinBox?

    These question arises as IMHO a lot of code between these would be the same. On the one side, you would double the number of spin boxes which makes it harder for the user, on the other hand the libraries grow also for people that don't need the long long spin boxes. (and I consider cases where you enter a number > 2E9 as rare, but I may be wrong?)

    So how about changing QSpinBox to take qint64 values? Therefore the changes should be minimal, the code doesn't increase that much and the end-user just takes the spin box and is fine.

    BUT: as this is binary incompatible it can not be done in Qt5. The good news is, you can do it for Qt 6.0.0 which should appear within the next two years.

    So I recommend you to start a discussion on the development mailing list first: http://lists.qt-project.org/mailman/listinfo/development to see what other Qt developers think.

    Happy coding!



  • @aha_1980 Thanks for your detailed answer to this thread!

    First, I'm working on a software where users need to instantiate such large integers, that's the main motivation behind my contribution. I cannot estimate whether it'll be a rare use, I only know that we need it. And the fact is we don't have many options:

    • Inherit from QAbstractSpinBox and reimplement dirtily the needed methods, duplicating existing code from private parts of Qt that we don't have access to, or patch up code to make it works (not a really satisfying solution)
    • Modify Qt source code and distribute it with the program (can be tedious to maintain tho)
    • Modify Qt source code and integrate the changes (providing everyone with a clean new widget/feature)

    That being said, I am perfectly aware of the code duplication for I studied the QSpinBox code when implementing the QLongLongSpinBox. Hence I came to (quite) the same conclusion: using a qlonglong in place of the actual int for member variables. The main drawback of this would be the memory cost, I guess, so I was thinking of some kind of optimizations but I will have to consult people that know more about it.

    That's where your mailing list comes in handy! So thanks again, I'm definitely going to ask questions there!


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.