FLTK 1.4 Released With Wayland & HiDPI Display Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Nth_man
    replied
    Originally posted by anda_skoa View Post

    [...] If you save that as, e.g. main.cpp, you can then compile and link it like this
    Code:
    g++ -o main main.cpp -I $QTDIR/include -L /dvl/Qt -L $QTDIR/lib -lQt6Core
    assuming QTDIR is set to the correct prefix.
    If it may help, in my test I used:
    Code:
    ​g++  -o main  main.cpp  -I /usr/include/x86_64-linux-gnu/qt5  -L /usr/lib/x86_64-linux-gnu/qt5  -l Qt5Core  -fPIC
    ​

    Leave a comment:


  • rmfx
    replied
    This toolkit is great, it's just a shame that they do not implement a clean, simple and modern default theme (aka flat style, slightly rounded corner shapes with antialiasing),
    and revamp their ugly website so that people are not turned off before even checking its api.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by kpedersen View Post
    Compilation hasn't worked nicely.
    I clearly has, otherwise the build would not have progressed to the linking stage.

    Well, I guess since you have no experience with C/C++ that could also be confusing to you.

    Building a program which consists of multiple files is usually done in steps.

    Each source file (also referred to as a translation unit) is compiled into an object file.
    These are then linked together to form the library or executable.

    Some build system suppress verbose output by default but when they don't do that you can see the compiler being invoked for each translation unit.

    Often looks like this
    Code:
    c++ -c -o myclass.o myclass.cpp
    For a Qt program this is no different. The macros that might be used in myclass.h or myclass.cpp have been resolved by the compiler pre-processor.

    If myclass.h contained the Q_OBJECT macro you will additionally see the invocation of the code generator
    Code:
    moc -o myclass_moc.cpp myclass.h
    and, following that, the compilation of that with the normal compiler
    Code:
    c++ -c -o myclass_moc.o myclass_moc.cpp
    Again no pre-processor involved other than the one the compiler has built-in.

    The resulting files are then linked together
    Code:
    c++ -o myprogram myclass.o myclass_moc.o ....
    In the Stack Overflow question this command generated an error.
    The build would not have reached this command if any of the compilation commands had failed.

    Since this is all new to you it might be easier to start with a single file example

    Code:
    #include <QtCore/QCoreApplication>
    #include <QtCore/QTimer>
    
    int main(int argc, char **argv)
    {
        QCoreApplication app(argc, argv);
    
        QTimer::singleShot(1000, [&app]() { app.quit(); });
    
        return app.exec();
    }
    ​
    If you save that as, e.g. main.cpp, you can then compile and link it like this
    Code:
    g++ -o main main.cpp -I $QTDIR/include -L /dvl/Qt -L $QTDIR/lib -lQt6Core
    assuming QTDIR is set to the correct prefix.

    At no stage does this require moc to run, the macros in both QCoreApplication and QTimer headers are resolved by the compiler's built-in pre-processor just like it would resolve the ones defined by other libraries like FLTK.

    Don't worry, once you have more C/C++ experience than basic tutorials this will not be a mystery to you either.
    Last edited by anda_skoa; 21 November 2024, 01:40 PM.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by Modu View Post
    After I read your posts, I concluded that Vala is standard C code. Brilliant!
    Something must have changed significantly since I've tried Vala couple of years ago.

    Back then its syntax would not have been valid for a C compiler and you needed valac to generate C code.

    valac back then was something you could consider an additional pre-processor or transpiler.

    At which version did they remove the need for this?

    Leave a comment:


  • Nth_man
    replied
    Several myths that some people still say... were debunked years ago: https://woboq.com/blog/moc-myths.html
    Last edited by Nth_man; 21 November 2024, 10:53 AM.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by anda_skoa View Post

    Great demonstration that the compilation has worked nicely without the involvement of moc.
    Compilation hasn't worked nicely. The code required to link wasn't even generated in the first place. You have taken another step backwards and now don't even have the code.

    So by your incorrect logic, the works of Shakespeare is standard C++

    Code:
    $ cat shakespere.txt | grep "MOC IS A BROKEN CONCEPT" > main.cpp
    $ c++ main.cpp
    (linker error, missing main entry point... but it compiled!)
    Either way, good luck with whatever you class as standard C++. I do feel a little sorry for the poor guy that needs to clean up the mess after you.

    Originally posted by Modu View Post

    After I read your posts, I concluded that Vala is standard C code. Brilliant!
    Haha, indeed. The guy is clearly confused.
    Last edited by kpedersen; 21 November 2024, 08:30 AM.

    Leave a comment:


  • Modu
    replied
    Originally posted by anda_skoa View Post
    It is, no matter how often you mistakenly claim the opposite.


    Yes, they use a code generate for convenience and productivity.


    Of course it will.
    When the pre-processor has removed something it is no longer part of the input that is passed to the C++ tokenizer.

    This is neither magic nor rocket science.
    If you open a text editor and do a search&replace with the replace being empty, then the result is the same document without the word you searched for.


    The whole point of using C pre-processor macros as syntactic sugar is to ensure that the marked-up code is still valid C++.

    Anyone who has built a Qt program and looked at the build output will have seen that each C++ source file is passed unaltered to the C++ compiler.

    The MOC steps are additional, if needed at all (when a class declaration contains the Q_OBJECT or Q_GADGET macro)


    Great demonstration that the compilation has worked nicely without the involvement of moc.

    The error is about missing symbols at the linking stage, because the person had used a macro to declare function in a header but forgot to provide the implementation.
    Easiest way for that is to let moc generate those implementations but as with any other code generator there is always the option to write the code manually.

    The build process wouldn't have gotten to linking if the compiler had not been able to build the various translation units first.

    Anyway, as I said earlier there is no shame in falling for this misunderstanding.
    Many people who come from languages without pre-processor don't have prior experience with the this type of automatic text replacement.

    I guess you are coming from a JavaScript/TypeScript situation which requires a separate tool to transform the actual source into something the target interpreter can understand.

    In C and C++ there is a built-in step that is essentially a search&replace.
    The most common use is the "#include" statement which gets replaced by the content of the file that follows.

    Qt uses this mechanism to provide input for a code generation tool while at the same time keeping the code consumable by a C++ parser.

    Some of these macros get replaced with nothing, i.e. effectively removed. For example "emit" or "slots"
    Some get replaced with a C++ key word. For example "signals" gets replaced with "public"

    Some are more complex and expand into declarations of functions or types. For example "Q_OBJECT".

    The C pre-processor is quite versatile in this regard.
    C code usually sees more use than C++ code but even the latter regularly makes use of "#include", "#ifdef", "#define".

    Many C/C++ APIS ship related "#define" statements as part of their headers.
    On a Linux system you can easily look for those by searching for "#define" in /usr/include

    Edit: unsurprisingly FLTK uses the same mechanism.

    For example "FL_OVERRIDE" gets either replaced with C++ keyboard "override" (if the C++ compiler is new enought) or replaced with nothing.

    FL/forms.H has several defines that expand into function definitions, e.g.
    Code:
    #define forms_constructor(type,name) \
    inline type* name(uchar t,int x,int y,int w,int h,const char* l) { \
    return (type*)(fl_add_new(t, new type(x,y,w,h,l)));}

    These things are so common that I doubt there are C/C++ developers who have not used them, let alone seen.
    Many, if not most, will even have written them.
    After I read your posts, I concluded that Vala is standard C code. Brilliant!

    Leave a comment:


  • Vistaus
    replied
    Originally posted by Raka555 View Post

    The FL in FLTK stands for fast and light, things GTK and Qt are not ...
    Yeah, as an end-user I love Qt and wouldn't ever touch GTK with a ten-foot pole, but I wouldn't call Qt "fast and light" by any means. The closest Qt that is "FL" is TQt from the Trinity Project, but otherwise, not so much. But even then, FLTK is a little bit faster and especially a lot smaller in size. (Plus the look-and-feel is more human-like.) So I can see a market for FLTK, especially when size matters or when the app is meant to run fluid on low-end or old devices.

    But as an end-user, I do prefer Qt and TQt myself. However, FLTK is great in its own way and I would gladly use it if I had an app that used it.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by kpedersen View Post
    Nope. Its not standard C++.
    It is, no matter how often you mistakenly claim the opposite.

    Originally posted by kpedersen View Post
    People don't just convolute their build systems with MOC for the fun of it haha.
    Yes, they use a code generate for convenience and productivity.

    Originally posted by kpedersen View Post
    You can #define many words in C++ to "nothing". Doesn't mean it will compile.
    Of course it will.
    When the pre-processor has removed something it is no longer part of the input that is passed to the C++ tokenizer.

    This is neither magic nor rocket science.
    If you open a text editor and do a search&replace with the replace being empty, then the result is the same document without the word you searched for.

    Originally posted by kpedersen View Post
    Likewise, if you don't pass your code through MOC first, the software will not compile.
    The whole point of using C pre-processor macros as syntactic sugar is to ensure that the marked-up code is still valid C++.

    Anyone who has built a Qt program and looked at the build output will have seen that each C++ source file is passed unaltered to the C++ compiler.

    The MOC steps are additional, if needed at all (when a class declaration contains the Q_OBJECT or Q_GADGET macro)

    Originally posted by kpedersen View Post
    Yeah, you get these kinds of errors obviously. Very easy to verify:

    I made a prototype of a project with PyQt and made it work there, now I'm trying to convert it to C++ and am having some problems. If I don't put the Q_OBJECT macro in, it compiles and works, but ...
    Great demonstration that the compilation has worked nicely without the involvement of moc.

    The error is about missing symbols at the linking stage, because the person had used a macro to declare function in a header but forgot to provide the implementation.
    Easiest way for that is to let moc generate those implementations but as with any other code generator there is always the option to write the code manually.

    The build process wouldn't have gotten to linking if the compiler had not been able to build the various translation units first.

    Anyway, as I said earlier there is no shame in falling for this misunderstanding.
    Many people who come from languages without pre-processor don't have prior experience with the this type of automatic text replacement.

    I guess you are coming from a JavaScript/TypeScript situation which requires a separate tool to transform the actual source into something the target interpreter can understand.

    In C and C++ there is a built-in step that is essentially a search&replace.
    The most common use is the "#include" statement which gets replaced by the content of the file that follows.

    Qt uses this mechanism to provide input for a code generation tool while at the same time keeping the code consumable by a C++ parser.

    Some of these macros get replaced with nothing, i.e. effectively removed. For example "emit" or "slots"
    Some get replaced with a C++ key word. For example "signals" gets replaced with "public"

    Some are more complex and expand into declarations of functions or types. For example "Q_OBJECT".

    The C pre-processor is quite versatile in this regard.
    C code usually sees more use than C++ code but even the latter regularly makes use of "#include", "#ifdef", "#define".

    Many C/C++ APIS ship related "#define" statements as part of their headers.
    On a Linux system you can easily look for those by searching for "#define" in /usr/include

    Edit: unsurprisingly FLTK uses the same mechanism.

    For example "FL_OVERRIDE" gets either replaced with C++ keyboard "override" (if the C++ compiler is new enought) or replaced with nothing.

    FL/forms.H has several defines that expand into function definitions, e.g.
    Code:
    #define forms_constructor(type,name) \
    inline type* name(uchar t,int x,int y,int w,int h,const char* l) { \
    return (type*)(fl_add_new(t, new type(x,y,w,h,l)));}

    These things are so common that I doubt there are C/C++ developers who have not used them, let alone seen.
    Many, if not most, will even have written them.

    Last edited by anda_skoa; 21 November 2024, 06:02 AM.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by anda_skoa View Post
    It is.
    And a common misunderstanding to think it is not
    Nope. Its not standard C++. People don't just convolute their build systems with MOC for the fun of it haha. Perhaps you need to be a little harder on yourself if you can't quite grasp the concept (though I am sure you can, you are just trying to turn this into a silly debate and waste everyone's time aren't you?).

    Originally posted by anda_skoa View Post
    "slots", or its all-upper-case variant "Q_SLOTS", is a C pre-processor "#define" that gets replaced with nothing.
    Essentially removed by the compiler's pre-processing stage before the C++ parse sees the input stream.
    You can #define many words in C++ to "nothing". Doesn't mean it will compile.

    Likewise, if you don't pass your code through MOC first, the software will not compile. You can try to argue around it as much as you can but Qt's reliance on MOC is well known as a disadvantage.

    Unless you are saying that non-compiling code is "standard C++"? I think you are confused.

    Code:
    int main
      std::cout hello world"
      return 0
    }
    "Completely standard C++.. I just didn't include the additional syntax to make it actually compile"


    Originally posted by anda_skoa View Post
    Anyone who has access to a C++ compiler, e.g. g++, can easily verify that.
    Yeah, you get these kinds of errors obviously. Very easy to verify:

    I made a prototype of a project with PyQt and made it work there, now I'm trying to convert it to C++ and am having some problems. If I don't put the Q_OBJECT macro in, it compiles and works, but ...


    As per the obvious answer here:

    This kind of errors usually happen when you add the Q_OBJECT macro and forget to rerun moc. If you use qmake, just run make qmake after you added the macro.​
    Simples! (until of course, MOC rots and you now need to personally maintain a specific version of an entire build system for your project)

    Originally posted by anda_skoa View Post
    No, MOC is a code generate that reads the same header files the C++ compiler reads and then generates additional C++ code for some of the macros.
    Most preprocessors generate additional code. Even the standard C Pre-Processor. Are you trying to argue that that additional C++ code generated by MOC is "optional"? You are very incorrect.

    Originally posted by anda_skoa View Post
    First year compsci students have often only background in "modern" languages and not yet experienced C or C++ and are not aware how the pre-processor and its marcos work.
    MOC and other non-standard pre-processing tools were a crap idea decades ago too. Nothing has changed in that regard really. Whether they were a first year compsci student in class of 2000 or class of 2024, they can still identify non-standard C++.
    Last edited by kpedersen; 20 November 2024, 07:19 PM.

    Leave a comment:

Working...
X