|
The BeOSJournal.
Discussing the news of the BeOS Community.
FAQ Search Memberlist Usergroups Register |
Profile Log in to check your private messages Log in |
|
Porting the Visual Component Framework to BeOS
|
|
The BeOSJournal. Forum Index -> BeOS Problems |
View previous topic :: View next topic |
Author |
Message |
JimCrafton
NewBe
Joined: 13 Aug 2002
Posts: 4
Location: NYC
|
Posted: Tue Aug 13, 2002 4:54 am1 Post subject: Porting the Visual Component Framework to BeOS
|
Next
|
|
Hi,
I have been working on a C++ cross platform project for a while now called the Visual Component Framework (VCF), and beginning to port it to other platforms, starting with linux.
I am posting this here in the hopes that others in the BeOS community may find it interesting and consider helping out with the project.
The framework itself is similar to Java and Borland's VCL, and is extremely component oriented. In addition to the framework, there is a an IDE called the VCF Builder. It is built to support a single workspace, and multiple projects, as well as full blown support for RAD GUI building. It supports editing forms/controls/components and editing properties and events. All changes made to the form are reflected immediately in the C++ code - there is no need for a separate code gen step, like Qt's Designer, or Glade, etc. Supports multiple undo/redo, and multiple compilers/linkers. i.e. The tool is compiler agnostic - Currently I am working on support for VC6, but the base libraries compile with GCC so soon there will be support for GCC as well. Future plans include supoprt for debugging so this would be a sophisticated IDE that is unique as far as I can tell (from a price/functionality standpoint).
Currently it (the VCF Builder) is under heavy development, and is not quite ready for any sort of use, I expect to have something people can play with on Win32 sometime by the end of August/early Sept.
I think this could be an extremely useful tool for BeOS/OpenBeOS, and provide a great way to create applications not only for BeOS but for other platforms as well, especially since I am trying to design to not care what your compiler/linker toolchain is.
I currenly do not have BeOS5 ( I have BeOS4.5 and it will not load on my current machine, something about not recognizxing the Promise drivers) right now. Any help would be appreciated and I would be happy to explain things to folks to get them started.
I expect the BeOS port to be the simples of all, since the is a fair amount of similarity between the VCF and BeOS API's and because both are in C++ and OOP.
For those interested, more information can be gleaned here:
http://sourceforge.net/projects/vcf
http://vcf.sourceforge.net/
and some docs here:
http://sourceforge.net/docman/?group_id=6796
and
http://vcf.sourceforge.net/docs/
Thanks
Jim Crafton
_________________
Why not try the VCF?
|
|
Back to top |
|
|
DaaT
Site Admin
Joined: 02 Jun 2002
Posts: 177
Location: Portugal
|
Posted: Tue Aug 13, 2002 1:08 pm2 Post subject:
|
Previous Next
|
|
Hello Jim,
First of all, thanks for posting here and for considering BeOS as a possible port. When we get the frontpage working again (as you might have noticed there are no news ATM), i'll post the news about VCF. Hopefully (and quite surely) that will bring more attention to your request.
I'm not a coder but it definitely looks like an interesting project.
Good luck with everything
DaaT
_________________
"Windows 95 is a 32-bit shell for a 16-bit extension to an 8-bit operating system designed for a 4-bit microprocessor by a 2-bit company that can't stand one bit of competition."
|
|
Back to top |
|
|
JimCrafton
NewBe
Joined: 13 Aug 2002
Posts: 4
Location: NYC
|
Posted: Tue Aug 13, 2002 2:07 pm3 Post subject:
|
Previous Next
|
|
Thanks, by the way, love your signature !
_________________
Why not try the VCF?
|
|
Back to top |
|
|
DaaT
Site Admin
Joined: 02 Jun 2002
Posts: 177
Location: Portugal
|
Posted: Tue Aug 13, 2002 10:49 pm4 Post subject:
|
Previous Next
|
|
hehehe, thanks
Not an original though, but love it
DaaT
_________________
"Windows 95 is a 32-bit shell for a 16-bit extension to an 8-bit operating system designed for a 4-bit microprocessor by a 2-bit company that can't stand one bit of competition."
|
|
Back to top |
|
|
philippe
NewBe
Joined: 01 Jul 2002
Posts: 2
Location: France
|
Posted: Wed Aug 14, 2002 11:58 am5 Post subject: Promise support...
|
Previous Next
|
|
Quote: |
I currenly do not have BeOS5 ( I have BeOS4.5 and it will not load on my current machine, something about not recognizxing the Promise drivers) right now. |
You should try this updated IDE driver: http://www.bebits.com/app/2625.
I bet it should works fine with BeOS R4.5 too.
Quote: |
I expect the BeOS port to be the simples of all, since the is a fair amount of similarity between the VCF and BeOS API's and because both are in C++ and OOP. |
Do you mean the BeOS API inspired your VCF API design? Or they are just similar on the OOP C++ API aspect only?
-Philippe
|
|
Back to top |
|
|
JimCrafton
NewBe
Joined: 13 Aug 2002
Posts: 4
Location: NYC
|
Posted: Wed Aug 14, 2002 3:17 pm6 Post subject:
|
Previous Next
|
|
Quote: |
Do you mean the BeOS API inspired your VCF API design? |
Not exactly, though the BLooper and BMessenger are very cool classes the VCF does not quite use something like that.
What i meant is that they are similar in rough API design, i.e. window and control classes, file, classes, graphics classes, etc.
_________________
Why not try the VCF?
|
|
Back to top |
|
|
moooooooo
Pencil Pusher
Joined: 12 Jun 2002
Posts: 43
Location: Melbourne, Australia
|
Posted: Fri Aug 23, 2002 12:14 pm7 Post subject:
|
Previous Next
|
|
Jim,
this would be really nice to have on BeOS. I appreciate you taking the time to let us know.
Make sure you get the IDE Replacement driver from BeBits mentioned previously and you should be able to find BeOS Personal Edition on BeBits as well.
The trick to get the Promise controller working is to attach the hard disk to a "normal" IDE controller and install this driver, and then re-attach the hard disk back on to the Promise controller.
It should be fine after that.
cheers
peter
|
|
Back to top |
|
|
memson
NewBe
Joined: 30 Aug 2002
Posts: 1
|
Posted: Fri Aug 30, 2002 3:40 pm8 Post subject: Writing a wrapper to the BeAPI
|
Previous Next
|
|
Having done something similar (and you will need to at least partially wrap to controls or use a multiple inheritence bodge to add commonality to multiple BControl descendents) I can say that it's not as easy as you think it will. Unless you have a heavily multithreaded model (like BeOS) you will suffer a lot when it comes to getting you essentially single threaded world to play nicely with BeOS. Stuff like locking loopers and such will be the bain of your life!!!
Take a look at http://sf.net/projects/befpc to see what I mean. It was an attempt to present a flattened simple interface to the BeAPI to use with languages such as Pascal (which cannot link to C++ classes)... It is on hiatus at the moment, and has been for a while, but feel free to take a look/borrow ideas. There is definetely some questionable code in there.. so be warned.
|
|
Back to top |
|
|
JimCrafton
NewBe
Joined: 13 Aug 2002
Posts: 4
Location: NYC
|
Posted: Sun Sep 01, 2002 5:21 am9 Post subject:
|
Previous
|
|
Well I have been looking at the API again, and as far as I can tell the main problem is that most toolits/frameworks expose the whole message/event loop mechanism at a very low level, and attempt to mirror on a function for function mapping for the event looping.
In the VCF things are a bit different, you simply call the UIToolkit's runEventLoop() or runModalEventLoopFor(control) - you don't deal with the platform event specifics at all.
The advantage this gives you is that the runEventLoop() call is actually optional ! So if you already have an event loop running (at least in Win32, and I would imagine X as well, not sure about BeOS), the VCF can seamlessly plugin, allowing integration into existing code like MFC or strainght Win32 programming, that is not possible with other frameworks - Fox, Qt, wxWindows, et al, are all or nothing, you use the library as a whole or none of it.
If there are disadvantages to this I have not run into them so far
So, hopefully this should be able to extend to the BeOS API as well, since the details of event loop will be hidden inside the toolkit implentation. It would mean that certain parts probably will need to made thread safe, but I don't see this as being too horribly difficult, as the framework has Mutex and Semaphore classes to deal with this.
_________________
Why not try the VCF?
|
|
Back to top |
|
|
|
|
The BeOSJournal. Forum Index -> BeOS Problems |
All times are GMT + 1 Hour
|
Page 1 of 1 |
|
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB 2.0.4 © 2001, 2002 phpBB Group
|