| 00:23.01 | Stragus | clock, publishing your own distro sounds like a lot of work. Anything special you are aiming at? |
| 00:25.33 | Stragus | I also don't want Qt on my boxes, except in a little sandbox somewhere for a project from work. I'm unsure regarding GTK as I googled how to achieve a specific need and the information was lacking |
| 00:26.27 | Stragus | Not that wxwidgets was much better, but I'll have to pick one and figure things out eventually. Unless I just build the GUI out of OpenGL. |
| 00:41.55 | clock | Stragus, I am aming at that it actually works and that its clear for users under which conditions is it supposed to reliably work, how to install it, and how to use it for common tasks people use PC for |
| 00:42.04 | clock | I actually don't make a distro but a PC |
| 00:42.10 | clock | cause distro without PC is useless |
| 00:42.14 | clock | PC without distro is useless |
| 00:42.20 | clock | its the whole thing that is useful |
| 00:42.35 | clock | I am making neither a heater nor a plastic shell. |
| 00:42.38 | clock | I am making an iron |
| 00:42.46 | clock | Which you can actually use to iron clothes |
| 00:43.34 | clock | Stragus, and I am aiming at copying the "bureaucracy" of the distro from human brain |
| 00:44.23 | clock | The brain has at least hundred million years of history of success at managing behaviour |
| 00:44.31 | clock | so its kinda... proven |
| 00:44.47 | clock | And I don't feel like inventing a wheel again when u have a model which has such long history of success |
| 00:45.03 | clock | So one thing is for example that I don't have a database of installed packet |
| 00:45.21 | clock | thats follows from copying the brain design |
| 00:45.33 | clock | It has a nice side effect - it cant get corrupted |
| 00:45.38 | Stragus | So... you are building a distro organized like a brain? :) I'm probably not following the concept |
| 00:45.48 | clock | Its really difficult to corrupt a database which doesn't exist ;-) |
| 00:46.06 | clock | Stragus, yeah exactly |
| 00:46.11 | clock | brain can do things right? |
| 00:46.30 | clock | like complex actions assembled from simpler actions right? |
| 00:46.44 | Stragus | A brain doesn't have much structure or design, it evolves and learns towards greater dopamine rewards |
| 00:47.33 | clock | I feel disrespected when you say " A brain doesn't have much structure or design" |
| 00:48.24 | Stragus | As any neural network, every brain is unique, it's organized in its own chaotic way learning toward a goal |
| 00:48.47 | Stragus | And I'm not sure how the concept can be transfered to a Linux distribution |
| 00:53.44 | clock | Stragus, and do you want to know it? |
| 00:56.02 | Stragus | I'm curious, though perhaps the anology meant something else than what I'm assuming |
| 00:58.24 | clock | OK its copied pretty straightforward from the brain |
| 00:58.41 | clock | just rip the circuit out of the brain and replace with different content |
| 00:59.17 | clock | like say instead of drinking from a mug, writing a letter or eating an apple I put making sure that firefox is functional, making sure that libreoffice is functional, making sure that brl-cad is functionaö |
| 01:00.11 | clock | Stragus, I give you an example how it works |
| 01:00.22 | clock | example: we want to achieve a reliable operation of BRL-CAD |
| 01:00.42 | clock | Will BRL-CAD operate reliably if the RAM of the PC is unreliable? |
| 01:02.04 | Stragus | The RAM needed depends on the operations that have to be performed, and only BRL-CAD knows that |
| 01:03.34 | clock | I feel disrespected when I get an answer which is in my opinion to a different question. I haven't asked whether the RAM needed depends on the operations that have to be performed or whether BRL-CAD knows that the RAM needed depends on the operations that have to be performed, but whether BRL-CAD will operate reliably if the RAM of the PC is unreliable. |
| 01:03.39 | clock | Will BRL-CAD operate reliably if the RAM of the PC is unreliable? |
| 01:05.32 | Stragus | Well no, of course. Pretty much nothing will operate reliably if the RAM is unreliable |
| 01:05.52 | clock | yes exactly - its obvious |
| 01:06.11 | Stragus | So obvious that I thought you were asking something else ;) |
| 01:06.32 | clock | So one of the conditions needed for the BRL-CAD to operate reliably is that the RAM is reliable AT THE MOMENT WHEN THE BRL-CAD runs |
| 01:07.33 | Stragus | One of the conditions needed for a working operating system is also that the RAM is reliable |
| 01:07.41 | clock | that too |
| 01:08.12 | clock | So there must be some kind of system in place - no matter whether automatic or through manual testing by the user - to CONTINOUSLY ensure that the RAM is reliable |
| 01:08.38 | clock | I had one laptop where the RAM was new, good, tested, running few years, then developed defects |
| 01:09.02 | clock | Another requirement for BRL-CAD is I assume a working X Window System |
| 01:09.19 | clock | Again, it doesnt matter whether there is a valid entry for X Windows System in the system package database |
| 01:09.24 | Stragus | As you know, EEC memory is meant to detect (and correct) issues, warning the user when it's getting bad |
| 01:09.31 | clock | What matters is that the X Windows actually works |
| 01:10.16 | clock | You may have a good entry in database but broken X Window System - for example, through library update which causes failure to load of dynamic library, or through corruption of executable upon power loss and file system corruption |
| 01:10.34 | clock | Stragus, yes - ECC memory is one way how to ensure continously that the RAM is good |
| 01:10.39 | clock | another option is periodic testing |
| 01:10.50 | clock | Or there is option in kernel to test memory on every boot |
| 01:11.14 | clock | And please notice BRL-CAD will work reliably even when you don't have any package database on the system |
| 01:11.24 | clock | The package database is absolutely irrelevant for operation of BRL-CAD |
| 01:11.41 | clock | It is the proper operability of the X Window system that is actually relevant |
| 01:11.51 | Stragus | As any other software, it's happy if it finds its dependencies, the package management (if any) doesn't matter |
| 01:12.02 | clock | well find is not enough |
| 01:12.25 | clock | whats necessary that the software actually works |
| 01:12.37 | clock | like... dependency test may test for presence of some header or library to link |
| 01:12.55 | clock | but it may test for maybe 10% of the files in the package and the package itself may be broken |
| 01:13.20 | clock | Stragus, my system, like the brain is robust |
| 01:13.38 | Stragus | Sure. The user then has to fix dependencies, although that's generally the job of package managers |
| 01:13.47 | clock | You silently delete or corrupt an executable, and what the system does, it just recompiles the bad software and replaces it |
| 01:13.50 | clock | its like self-healing |
| 01:14.04 | clock | but the kind oif self-healing you have to shoot really heavily to actually bring it down :) |
| 01:14.16 | Stragus | How does it detect a bad dependency? |
| 01:14.48 | clock | Well it actually tries to run it |
| 01:14.55 | clock | if it doesnt execute, its bad |
| 01:15.45 | clock | so it ensures its good |
| 01:15.46 | Stragus | And let's say it crashes, it was linked to libpng of a different version than assumed due to direct access into PNG structs (which is deprecated) |
| 01:15.48 | clock | compile again |
| 01:15.50 | clock | replace the bad one |
| 01:16.13 | clock | if it crashes, test fails, the bad software gets replaced |
| 01:16.58 | Stragus | What do you replace? The software calling libpng? |
| 01:17.13 | clock | The software that malfunctions |
| 01:17.36 | clock | fails? chug it, replace with a new one! :) |
| 01:17.40 | Stragus | The software could function perfectly and the problem being in any of its dependency due to a version mismatch |
| 01:18.33 | clock | Stragus, its me who decides which versions of software and libs are on the system |
| 01:18.41 | clock | I must not allow this. This would be a bug in my product. |
| 01:19.05 | Stragus | Well... You know, package management is a real pain |
| 01:19.11 | clock | I don't find it |
| 01:19.26 | clock | I don't find it pain |
| 01:19.46 | Stragus | Installing software A demands library X being version > N, but software B was compiled against version N, so software B would also have to be recompiled if you update N |
| 01:20.03 | Stragus | Except that installed software C doesn't actually work at all if X has version > N |
| 01:20.24 | Stragus | And it gets a lot more complicated than that. Distribution package management is a little nightmare |
| 01:20.42 | clock | Stragus, well real life has a ton of "impossible" situations like that |
| 01:20.56 | clock | Human brain has of course methods how to deal with this |
| 01:22.05 | clock | Typical situation is you want to go to cinema (SW A) and shopping (SW B) |
| 01:22.15 | clock | Cinema is in floor N and mall in floor M |
| 01:22.25 | clock | A demands your body be in floor N B demands your body be in floor M |
| 01:22.32 | clock | impossible to satisfy at once |
| 01:24.10 | Stragus | I guess I'm not seeing where the brain comes into play in all this |
| 01:24.40 | clock | Stragus, brain has a universal structure to solve all kinds of dependencies like this |
| 01:24.44 | clock | I just take it over |
| 01:25.09 | clock | Cause I believe its proven, elegant, fast, robust, reliable,... |
| 01:26.00 | Stragus | I really have no idea how that's going to work, but good luck :) |
| 01:26.19 | clock | Stragus, I believe the reason package management is a nightmare people try to program package management in a serial, von-neumann approach which I believe is grossly unsuitable for that |
| 01:26.39 | clock | Stragus, I think u already know very well how it works :) |
| 01:26.45 | clock | Please watch yourself doing any kind of task |
| 01:26.48 | clock | cleaning teeth |
| 01:26.58 | clock | u see how it works... |
| 01:27.16 | Stragus | I understand neural networks, I understand how they work and learn. But I don't understand how you want to apply that concept to package management |
| 01:27.41 | clock | Stragus, I dont put a self-learning neural network inside. I just copy the already learned product |
| 04:50.14 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.225.90) |
| 06:15.32 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.225.90) |
| 06:22.56 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 07:15.02 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 09:09.40 | *** join/#brlcad luca79 (~luca@net-2-34-209-63.cust.vodafonedsl.it) |
| 10:14.44 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 10:58.32 | *** join/#brlcad vladbogo (~vlad@188.25.239.134) |
| 12:30.16 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 12:52.32 | ries | Stragus: our experience is that using Qt allows you to create a UI on different platforms very easely |
| 12:52.44 | ries | A lot of thingâs âjust workâ |
| 12:53.33 | ries | I know compilation is a bit âoddâ if you are used to autotools (hehehe) but on the other hand the same build instruction can be issued for mac, windows and linux |
| 12:56.45 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.225.90) |
| 13:09.25 | *** join/#brlcad clock (~clock@212.203.58.127) |
| 14:01.29 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 14:10.08 | starseeker | vladbogo: thanks. I started exploring what it will take to re-create Archer's level of functionality, so I haven't gotten too far yet |
| 14:12.02 | starseeker | vladbogo: you can build on what is there if you want, but it might still be worthwhile to implement the minimalist MGED interface and resolve some things like key binding mapping there. I would suggest re-using the cadconsole stuff for a command prompt, since there's no particular point in redoing that when it seems to be working... |
| 14:13.16 | starseeker | The Qt dock widget isn't *quite* what we need - it's very close, but when the windows de-dock they need to turn into full fledged toplevel windows instead of the "floating dockwindow" thing they've got going on right now |
| 14:14.27 | starseeker | I'm not sure how hard it will be to make our own modified version of QDock, so for now I'm going to focus on other things and return to that later |
| 14:17.03 | starseeker | the tree widget is critical to get right, since Archer handles that very well now - that and figuring out how to structure the edit panel look like the most complicated UI bits to deal with at this point |
| 14:17.40 | starseeker | I figure that should be fairly orthogonal to your work building up from the Qt dm/fb, and hopefully we can meet in the middle |
| 14:20.34 | starseeker | one note about the console - I deliberately stripped it down compared to the Paraview version, but it may prove I took that too far - scroll history has to have a limit regardless (even xterms have such a limit) and we may end up wanting the richer features of the fancier text environment if we want to add GUI integration to the console (things like clicking on objects in output of the tops command, for example, to draw them) |
| 14:21.17 | starseeker | for now we'll stay simple - stuff like that is for *after* we get MGED/Archer level fuctionality working - but I wanted to point it out for later |
| 14:23.00 | starseeker | rather likes that idea because it will hopefully be simpler than adding a filter system to the tree view - just do a search for what you want on the command prompt and have the search results be clickable to select things in the tree... |
| 14:30.38 | vladbogo | starseeker: that's what I thought too to reuse the console and get a minimal drawing functionality at first. That said I will start working at this approach and come back with updates. |
| 14:31.36 | starseeker | vladbogo: cool. With any luck the basic drawing will be quite simple (in theory it should be easier to use "proper" Qt interaction bindings than shoehorning in Tk stuff) |
| 14:32.53 | vladbogo | that's what I hope too |
| 14:34.20 | starseeker | Qt menus are also quite simple, and feel free to use standard Qt dialogs anywhere it makes sense (File open and save are definite, and I suspect QColorDialog will be an improvement over the Tk version: http://qt-project.org/doc/qt-5/qcolordialog.html) |
| 14:38.20 | starseeker | Don't worry about most of the dialogs that are custom in MGED at this stage - a lot of those are quick hacks that need re-thinking, and I know that the Build Pattern tool (for example) needs to be massively refactored into C and have its interface re-thought |
| 14:41.04 | starseeker | that will actually be the fun stage of all this - when we have the foundation in place, we can start to think about what the *good* ways to do UI bits for BRL-CAD are instead of what the *quick* ways are :-) |
| 14:45.08 | starseeker | one think I don't know for sure yet is whether the native Qt HTML support can usably display our help documentation, or whether we need an all-up webkit window to handle the CSS formatting. |
| 14:45.17 | starseeker | s/one think/one thing/ |
| 14:46.37 | starseeker | in principle it would be nice to avoid needing webkit for the help system, but if the choice comes down to building webkit as part of Qt or porting tkhtml3 from Tcl/Tk to Qt... urk |
| 14:47.42 | starseeker | another option would be a stand-alone CSS "pre-processor" that could feed finalized HTML to a renderer, but if one exists I haven't found it yet |
| 14:49.10 | starseeker | anyway, first things first. |
| 14:56.07 | Notify | 03BRL-CAD:starseeker * 63269 (brlcad/branches/qtged/src/qbrlcad/cadtreemodel.cxx brlcad/branches/qtged/src/qbrlcad/cadtreemodel.h and 2 others): Add headers to the cadtree code |
| 15:14.11 | Notify | 03BRL-CAD:starseeker * 63270 (brlcad/branches/qtged/src/qbrlcad/main.cxx brlcad/branches/qtged/src/qbrlcad/main_window.cxx brlcad/branches/qtged/src/qbrlcad/main_window.h): Move the dock widgets' initialization to main_window.cxx |
| 15:18.55 | teepee | runs screaming after reading "qt dock widgets" ;) |
| 15:51.17 | starseeker | teepee: have you had problems with them? |
| 15:51.56 | teepee | well, problems is maybe too big a word |
| 15:52.11 | teepee | mostly ask 3 users and get 5 answers how it's supposed to work |
| 15:52.18 | teepee | like "i don't want them to undock" |
| 15:52.24 | starseeker | heh |
| 15:52.25 | teepee | "the title bars are too big" |
| 15:52.58 | teepee | i've ended up with https://github.com/openscad/openscad/pull/1003 so far :) |
| 15:53.38 | teepee | or "i can't make them as small as previously" (before it was a dock widget) |
| 15:54.29 | teepee | there were some big issues in Qt5 on MacOS and in case of multi-monitor usage |
| 15:54.39 | teepee | I think most are solved now |
| 15:55.19 | starseeker | teepee: I was a little surprised there doesn't seem to be an option to make the undocked windows full toplevel windows, but perhaps that's too strange a use case |
| 15:56.01 | teepee | yep, that would be awesome. I do understand they are not supposed to be that way, but it would help in some cases |
| 15:56.19 | starseeker | for us it will be essential |
| 15:56.29 | teepee | undocking to separate top-level is not too much code |
| 15:56.39 | teepee | but it's annoying having to write it manually |
| 15:56.57 | starseeker | nods - I'm guessing if there is a problem, it will be recognizing the correct placement for a re-docking |
| 15:57.49 | teepee | I'm still thinking about having to GUI modes where the main window is a different widget |
| 15:58.06 | starseeker | you mean as opposed to docking? |
| 15:58.20 | teepee | depending on how the user works, the main widget is either the text editor or the output view window |
| 15:58.43 | teepee | more like a combination of both due to different usage |
| 15:59.00 | teepee | when using an external editor, the viewport is pretty much the main window |
| 15:59.03 | starseeker | that's why I want the ability to un-dock to toplevel windows - if that's working, in theory either could be treated as the "main" window |
| 15:59.36 | teepee | well, one has to have the toolbar :) |
| 15:59.47 | starseeker | can't they both have toolbars? |
| 15:59.58 | teepee | ok, it would be possible to copy that and use the "same" everywhere |
| 16:00.04 | teepee | but you can't set the same instance |
| 16:00.54 | teepee | I have no idea how MacOS and Unity (with common menu bar) handle that then, probably switching when the window changes |
| 16:01.14 | starseeker | is it critical to do so? I suppose if you have elements on the toolbar reflecting state that could be tricky, but if you used signals and slots to make have all instances of a button "listening" for a state change wouldn't that work? |
| 16:01.57 | teepee | when using actions the state->menu-item should be fine |
| 16:02.28 | teepee | the other direction should work too, I guess one just has to make sure not to create circles when triggering changes |
| 16:02.38 | teepee | but then that could happen with single menu/toolbar too |
| 16:02.46 | starseeker | is a little surprised the dock isn't more mature than this - is it a relatively new feature in Qt? |
| 16:02.56 | starseeker | or just something only now getting wide use? |
| 16:03.15 | teepee | don't know, it's at least in 4.8, so it's not very new |
| 16:03.34 | teepee | I think they really just see it as "Tool" window like for graphics editors |
| 16:04.08 | starseeker | ah |
| 16:04.26 | teepee | they do have that "MDI" mode, but it's modeled like on Windows which pretty much nobody wants to have :D |
| 16:04.31 | starseeker | nods |
| 16:04.55 | starseeker | yeah, I really like what they do have for docking aside from that "not a toplevel window" bit |
| 16:05.28 | starseeker | and that's mostly because MGED has established the tradition of the console and display both being toplevel. |
| 16:06.04 | teepee | yup, mostly it's fine. I have to try if the awful drawing problems with Qt5 are still there (I'm not sure if we cause this ourself or if that's really Qt5 bugs) |
| 16:06.54 | teepee | sometimes after redocking it just draws in some random rectangle in the main window that has nothing to do with the actual docked widget |
| 16:07.06 | teepee | with Qt4 that never happened |
| 16:07.18 | starseeker | huh |
| 16:07.31 | starseeker | yeah, that's not good |
| 16:08.06 | teepee | it's easy to fix by just touching anything that resizes the window or parts of it |
| 16:08.44 | starseeker | ah - so a "safe" workaround might be to trigger some sort of re-draw on the main window? |
| 16:09.14 | teepee | could be, I did not have much time to look at that |
| 16:09.31 | teepee | maybe it's something we do in the signal handlers |
| 16:09.48 | teepee | I guess the only way to find out would be to just do a tiny sample application |
| 16:09.56 | starseeker | nods |
| 16:10.27 | teepee | but getting all compiling fine is higher on the todo list ;) |
| 16:10.32 | starseeker | heh |
| 16:10.43 | teepee | it really gets funny if both Qt4-dev and Qt5 dev is installed on a Linux system |
| 16:11.10 | teepee | like compiling against Qt5 but some lib is compiled against Qt4 |
| 16:11.13 | *** join/#brlcad gaganjyot (~gaganjyot@124.253.225.90) |
| 16:11.26 | teepee | that's easy to notice though |
| 16:11.34 | teepee | instant crash on application start :/ |
| 16:11.39 | starseeker | nods - CMake tends to do pretty well with that in my experience |
| 16:12.14 | teepee | are you using cmake for the Qt app too? |
| 16:12.30 | teepee | we still use qmake for the main app and cmake for the test cases (that do not link Qt) |
| 16:12.44 | teepee | which is not really the ideal way ;) |
| 16:13.28 | starseeker | yes - see http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/branches/qtged/src/qbrlcad/ |
| 16:14.30 | starseeker | our toplevel CMake Qt setup is here: http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/branches/qtged/CMakeLists.txt#l1025 |
| 16:17.13 | starseeker | CMake does too many nice things at this point for us to switch without *very* compelling reasons - we've build some features on top of CMake that to my knowledge are unique in CMake land (in-src make clean support, distcheck, sophisticated third party dependency management, etc.) and would be a lot of work to duplicate elsewhere |
| 16:17.13 | teepee | cool, I guess I'll try that in case I have some spare time :) |
| 16:17.21 | *** join/#brlcad gurwinder (75c76b36@gateway/web/freenode/ip.117.199.107.54) |
| 16:17.25 | teepee | having both build tools is not really perfect |
| 16:18.55 | teepee | I guess if a cmake developer has a look at our CMakeLists.txt that will cause instant heart attack |
| 16:19.01 | starseeker | CMake gives us some bits that are very nice for Windows portability - it can handle file copying, decompressing archives, run scripts, etc. in a portable fashion. Normally it's the kind of thing you rely on standard tools like tar and sh for, but on Windows you can't count on anything |
| 16:19.07 | starseeker | heh |
| 16:19.08 | teepee | ctest is quite nice tho |
| 16:19.08 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 16:19.41 | teepee | ahh, right we currently don't have a native Windows built |
| 16:19.45 | starseeker | has little doubt our CMake logic is scary - I don't like that, but if you want advanced features you just end up not looking very vanilla in your code |
| 16:20.12 | starseeker | yeah, we did a *LOT* of work to get Windows support working cleanly |
| 16:20.26 | starseeker | including switching from flex/bison to re2c/lemon for portability |
| 16:20.40 | teepee | true, like I always try to tell some people it's not possible to solve complicated issues in a simple way ;) |
| 16:21.15 | starseeker | We don't have a portable sh that we can use to run our scripts, and windows doesn't have termlib so programs still using that don't build, but on the whole we're very close to full-featured building |
| 16:21.48 | teepee | nice. how do you handle the dependency builds in that case? |
| 16:22.28 | starseeker | has thought occasionally about trying to build https://www.mirbsd.org/mksh.htm with CMake... |
| 16:23.09 | starseeker | our dependencies are spelled out in CMake - it usually resolves them for us without trouble, including building tools it needs to build sources for libraries and such |
| 16:23.12 | starseeker | very nice |
| 16:24.18 | starseeker | Visual Studio projects are our only working target at the moment for Windows, but I would really like to see if I can get ninja working on Windows |
| 16:24.32 | teepee | ninja? |
| 16:24.47 | starseeker | http://martine.github.io/ninja/ |
| 16:24.56 | teepee | yet another build system :) |
| 16:25.00 | starseeker | CMake can generate build files for it |
| 16:25.08 | starseeker | no, in this case it's basically a make replacement |
| 16:25.17 | Stragus | I profoundly dislike how Qt wants to take over the whole build system, enough to make me stay away from it entirely. Am I missing something or it's really required? |
| 16:25.43 | Stragus | I assume it's required due to their weird C++ "extensions" |
| 16:26.33 | gurwinder | brlcad: Hi. I am still trying to get the whole information of our BRL-CAD's .g file. Want to know how information is stored( header, flags all other things ). Its not related with g-pov. Please provide me right way to get it. |
| 16:26.40 | starseeker | Stragus: I haven't found it too bad - you need moc as part of the build, but CMake manages that once you set up the right logic and after that it's not a big deal... it was more complex to get re2c/lemon build set up in my experience |
| 16:27.34 | Stragus | Let's suppose I would like to compile with a bash script, not any CMake magic to be compatible with Qt |
| 16:27.36 | starseeker | As I understand it those extensions are what allow object introspection, which is essential to how Qt works. |
| 16:27.59 | starseeker | Stragus: ah, yes if you are using bare bones build tools it will be more complicated |
| 16:28.06 | teepee | it basicall generates the signal/slot stuff |
| 16:28.08 | Stragus | Yes... Traditional callbacks aren't good enough for Qt, they want to send "signals" based on slots registered as strings of text |
| 16:28.26 | starseeker | has found it to be very powerful, so far |
| 16:28.29 | Stragus | (Totally inefficient, but no one cares I guess) |
| 16:29.03 | starseeker | I suspect it's seldom a performance bottleneck, since it's concerned mostly with user interaction... |
| 16:29.43 | Stragus | Probably so, but it doesn't seem like a good reason to mess up the build system to implement an inferior solution (to my eyes) |
| 16:30.04 | Stragus | Is there a way to write the signal/slot in plain C++? A lower-level interface?... |
| 16:30.14 | teepee | that moc thingy is ancient :) |
| 16:30.20 | starseeker | I think it depends on which version of C++ we're talking about |
| 16:30.35 | starseeker | yeah, when Qt started the answer was a flat "no" as I understand it |
| 16:30.42 | teepee | it's possible to write even in C (see glib) and as no-moc C++ (libsigc++ or what it's called) |
| 16:30.58 | starseeker | today you might check this out: https://github.com/pbhogan/Signals |
| 16:31.30 | Stragus | Of course I know it's possible. :) But I wonder if Qt makes it possible, not if it can be implemented in a different context |
| 16:32.06 | starseeker | I don't think the moc is optional unless you're willing to do without most of Qt's advanced features |
| 16:32.16 | teepee | I don't think it's possible and even Qt will not touch it as they are moving away from the Widget stuff anyway |
| 16:32.36 | gaganjyot | brlcad, if BRL-CAD participates under GCI this year will it consider LibreCAD too ? |
| 16:32.44 | Stragus | Meh, I see. All right, I think it's going to be GTK+ or wxwidgets |
| 16:34.01 | starseeker | Stragus: if you're not too concerned about native platform integration, what about fltk? |
| 16:34.30 | starseeker | If Qt wasn't a possiblity for us I'd be looking hard at fltk |
| 16:35.05 | Stragus | That one didn't seem to natively implement something I expected to need: a long list with multiple columns, the cells of some columns holding images, dropdown menu and such stuff |
| 16:35.30 | Stragus | ... something I expect* to need |
| 16:35.53 | starseeker | fair enough - fltk is minimalistic (by design) |
| 16:36.07 | Stragus | Yes, it seemed so |
| 16:36.37 | Stragus | Even GTK+ and wxwidgets seem to barely support what I just described, relying on new and poorly documented features |
| 16:37.12 | starseeker | yeah, that sounds like enough of an application specific widget that most people would assume it's something the application would do |
| 16:37.30 | starseeker | even with Qt we're going to have some custom work to do things like the edit panel |
| 16:37.42 | Stragus | I wouldn't mind that, I have just zero experience with GUI :) |
| 16:37.57 | Stragus | Except some win32 about... 15 years ago, and GUIs written from scratch in OpenGL |
| 16:39.03 | starseeker | Stragus: then you might want to write small programs in the various options to get a feel for them - for anything non-trivial you can pretty much count on having to do some custom work regardless, so you might want to get a sense of what framework best fits your style |
| 16:39.04 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:39.45 | Stragus | Yes, that sounds wise. I have no experience with the whole concept of creating new widgets from scratch within a toolkit (OpenGL doesn't count) |
| 16:40.27 | starseeker | realizes he'd better stop putting off the chores... |
| 16:40.41 | Stragus | :) Go ahead, thanks for the tips |
| 16:41.21 | Stragus | And it's probably weird that I'm tempted to just write GUI in OpenGL again. Somehow, it seems "easier", ten times the code but nothing to learn |
| 16:44.37 | starseeker | Stragus: if you go that route, you might want to look at this guy's work: https://github.com/memononen/ |
| 16:45.51 | Stragus | Ohhh! Unicode freetype rendering library written in C |
| 16:45.57 | Stragus | That is nice. |
| 16:46.26 | *** join/#brlcad gurwinder (75c76b36@gateway/web/freenode/ip.117.199.107.54) |
| 16:48.58 | Stragus | Thanks starseeker, very interesting |
| 17:44.29 | *** join/#brlcad teepee (~teepee@gateway/tor-sasl/teepee) |
| 18:14.13 | *** join/#brlcad mpictor (~mark@c-69-136-183-213.hsd1.in.comcast.net) |
| 18:21.09 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 19:35.45 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 20:06.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 20:18.53 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 22:04.12 | *** join/#brlcad ries (~ries@D979EA84.cm-3-2d.dynamic.ziggo.nl) |
| 22:30.13 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 23:39.58 | Notify | 03BRL-CAD Wiki:Mmattb117763 * 0 /wiki/User:Mmattb117763: |