Bricscad releases BIM Module for Linux

Now thats one topic that will make me throw a party because, lets face it, it's the reason I'm using Bricscad on Fedora Linux.  This module in Linux will not only be fair for non-windows addicts but also revolutionary.   So is this gonna happen or .... ?

Comments

  • I don't have a windows installation, so I just had a look at the provided .chm file:

    "Visual Basic for Applications (VBIM) and Visual Basic Scripting (VBS) create an open environment for the BricsCAD BIM Module, providing the opportunity for customization and localization by users and third party developers worldwide. VBS scripts can be opened from inside the BricsCAD BIM Module, and from external applications like Excel, Word etc. VBIM is the foundation of our reporting system, allowing unlimited customization."

    So I guess it's not realistic to hope for something sometime soon.

    Judging just from the documentation, the BIM module seems to be a pretty complex piece of software, with some interesting concepts. It just puzzles me a little that there doesn't seem to be a single reference to ifc in the whole document...
  • Oh no ... and I thought it would be a BRX thing.  This is a bit discouraging ... kinda *forces* the end-user to hug MS-Windows.  Perhaps basing such modules on a platform independent interpreter like Python would produce a more universal Module.  I agree that its a complex thing, but believe me, I don't mind creating mine if Bricsys won't deliver ... no matter how long it takes. 

    At least since it is tagged "BIM" there should be some reference to open standards like IFC and Building XML.   If those are absent then I am stunned.  The only thing that prevented my students from fully embracing the Bricscad line was the absence of BIM (like with AutoCAD Architecture).  Now it comes, and its all MS-Windows again, we use Bricscad Linux here and perform green analysis on cross-platform open-source applications too.  It is only natural to have a BIM Design tool for Linux too.  Why is this not happening?
  • Just some clarification :-)

    The BIM module is based on BRX ... the external APIs are based on VB/COM; that's a difference.
    The BRX code could likely be ported to Linux (imho) ... the problem is the user interface;
    I did not have a closer look yet, but I guess it is based on MFC, not on WxWidgets ...

    If the Linux community would ever have ported COM and/or WinSDK and/or MFC to Linux, then
    it would be much more easy to port ... but they never did, unfortunately;
    but when .NET was published (which is also COM based !!), half a year later MONO was started ...

    I do not understand the logic here ... but it is Linux, which prevents applications to be ported;
    cross-platform systems like WxWidgets / Qt are great - but none of those systems provides a way
    to re-use existing (WinSDK / COM / MFC) based code ... you have to *start* programming in WxWidgets / Qt.

    That is the bottleneck, and the main reason ... very bad :-(

    Greetings to all !
  • MONO is not getting much smiles from the Linux community because of its roots -- and, of course, the fear of potential litigation over license infringements.  You can't place that blame on the Community because they didn't create the License issues.  Again I was of the impression that since the core of Bricscad Linux is already using wxwidgets the code deficit for additional modules wouldn't be significant --- unless there are too many dialogues to port.  I was hoping to highlight BIM potentials using Bricscad in Fedora Linux next month (FESSA Week, ESUT -- last week of July).  I guess I was being too hopeful.
  • Dear Onyeibo,

    for sure, I don't wanto to blame anything or anyone at all ... :-)
    I'm not very sure about BIM user interface ... but it originates from Architectural roots, and I assume, at that
    time, WxWidgets was not yet used ... but I could be wrong; having a look at the code, I see MFC resources only,
    but no WxWidgets resources.

    The non-GUI code is mainly BRX, which is available on Linux - so from that side, no potential problems for a Linux port.

    Besides - there is no license issue at all for Linux - APIs are not protected by copyright laws (even US copyright laws),
    regardless what an API developer side claims ... so re-implementing an API and its behaviour is not a legal risk
    (see BRX)

    But what is definitely true - the Linux community does not develop what is necessary, but what the developers like :-)
    In main priciple ...

    For example, the so-called WinSDK is about 200 ... 300 functions, more or less wrapping C runtime functions ...
    and available since > 15 years ...
    it is nearly trivial to re-implement ...

    Another example is COM - it is designed by MS as platform-independent, what I can confirm, it is platform-independent.
    And MS actively offered to port COM to other systems, nobody followed.

    Another example : from string-related C runtime functions, at this moment around 30% ... 40% of then are available as Unicode version,
    after > 15 years of Unicode being available ... and the total amount of such functions is < 200; but it was never completed.
    I know that Linux prefers UTF and all the arguments around ... but nobody can explain why still 50% ... 70% of C runtime's
    string functions are not available as Unicode version ...
    definitely a trivial job, but nobody ever did. And this is what I do not understand ... if Linux targets to desktop (since 10 years),
    they have to do this - simple + sraight.

    And this kind of mismatch is the reason for so less applications porting from Windows to Linux ... in my opinion.
    It is especially the lack of such APIs like WinSDK, some non-GUI MFC parts, COM and more, which blocks porting applications to Linux.

    Instead of having all these fundamental programming APIs - we have dozens of distributions :-)
    Can you imagine, if 10%...20% of all that manpower, put into development of all those (more or less similar) distributions would have spent
    into development of those APIs ... ?

    When we started Linux port of BRX, we had to re-invent most of those WinSDK, none-GUI MFC, some COM and COM related stuff ...
    a huge work for us, but would be a simple thing for linux community ...

    As you said : "MONO is not getting much smiles from the Linux community because of its roots" - I fully agree :-)
    And as we all know, if political reasons are more important than technical reasons ... result is what we have today.

    So I only wanted to pinpoint the problems that developers encounter when porting to Linux ... it is a heavy job,
    And the main reason for is not (Windows) developers not wanting to port, but Linux' lack of APIs (and the less focus on "applications"
    and ignorance of API compatibility betwene versions + distributions - see Gnome project, and the heavy critics from it former Portuguese leader)

    Just to clearify - I really like Linux - close to love it :-)
    But I also see the dilemma there ...
    but now enough for philosophy :-)

    Many greetings & a nice day
    Torsten
  • Dear Onyeibo,
    oops - the previous post has corrupted your name :-) I apologise ....
  • Hi Torsten,

    That was elaborate.  I see your point.  It is indeed a dilemma.  Nevertheless, is it all gloom for us Linux users?  You said and I quote, "When we started Linux port of BRX, we had to re-invent most of those WinSDK, none-GUI MFC, some COM and COM related stuff ... a huge work for us, but would be a simple thing for linux community ..."

    You came short of saying a port is feasible.  I mean, you have already crossed most of the API huddles.  I went for the Bricscad Linux license with hope that the development drive will see "Architecturals" (BIM-Module) through to Linux users.  Please tell me I didn't make a mistake.  It will make Linux based customers happy to have a date to look forward to.
  • Dear Onyeibo

    homestly, I do not know about strategy for "BIM on Linux" ... I'm not that involved here;
    but as I mentioned, and as far as I see, it is mainly the MFC based GUI which would need to be ported to WxWidgets.

    Not sure how simple that is - a different GUI also means different code, even when it is similar.

    But I guess, this topic is likely aready under discussion for our development head ... best is, to ask directly or by a support request for this ?

    So for sure - you didn't make a mistake :-) Committment to Linux was + is definitely there, no doubt.

    Wish you a nice sunday & many greetings
    Torsten
This discussion has been closed.