New shiny VCF release
-
Why would anybody vote this down? :confused: Anyway, great job Jim. It takes a lot of courage, patience and hard work to do what you did. Thanks.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
where's the linux version? http://sourceforge.net/pm/task.php?group_project_id=12937&group_id=6796&func=browse[^] I see alot of 0%'s on the task manager for the abstraction you're doing over GTK?? Are you doing this over GTK for C or GTKmm for C++ OO implementation? I'm working on a WinGDI over Xlib without the GTK middle man myself.
-
where's the linux version? http://sourceforge.net/pm/task.php?group_project_id=12937&group_id=6796&func=browse[^] I see alot of 0%'s on the task manager for the abstraction you're doing over GTK?? Are you doing this over GTK for C or GTKmm for C++ OO implementation? I'm working on a WinGDI over Xlib without the GTK middle man myself.
The linux version, as I mentioned to you in an earlier thread, needs a lot of help. We are using GTK to do the drawing controls, etc. We don't need gtkmm, as we already provide a suitable C++ API, and it just adds another layer, useless for our purposes, as far as I can tell. We could definitely use the help, given that WxWidgets is pretty much MFC for X, and that, IMHO, VCF is miles away better and easier to use than MFC. Wouldn't it make sense to use that? Or are you really wanting something that is basically one for one API compatible with MFC for X? If this is the case you should really look into wxWidgets. I'm working on a WinGDI over Xlib without the GTK middle man myself. Well then you're in for a special treat. Having tried this myself, here's what you have in store for you (based on my experience): Conceptually the XLib event loop is simple to understand and quite similar to Win32. However the first gotcha comes you realize that there is nothing like a SendMessage() API call. Everything is done asynch, equivalent to PostMessage(). Next you realize that you will have to brush up on your network code - why? Because X is implemented over sockets, and for certain things you need to drop down to that level, especially if you are writing a higher level lib on top of it. For example, lets say you want to implement something equivalent to SendMessage - you'll almost certainly drop down to the socket level using select() and friends. Don't beleive - take a glimpse at the Qt source and you'll see how ugly it gets. Timers - nope, nada, zip. Gotta implement those yourself. Don't waste you're time going to the xlib newsgroups - they'll just repeat the X mantra - "policy not implementation". Next up for fun: fonts. On Win32 you just ask for a font, specify some params, like name, size, weight, etc, and Boom, you get back a handle - no matter what, unless some critical error occurs, you'll get a handle! There is a built in font mapper that's part of the Win32 API. In XLib there is no such thing. You have to implement the font mapping code yourself, or find some 3rd party lib that does. Further more, XLib is done with Ascii character sets in mind - it doesn't do unicode, again you'll to implement this stuff yourself, or find a 3rd party lib. Colors - On Win32 this is pretty simple. You just pick an RGB val and you're done. The HDC will either support it or not, and if it doesn't then it will dither for you. On XLib, of course, nothing is this simple. X supports a bunch of different di
-
The linux version, as I mentioned to you in an earlier thread, needs a lot of help. We are using GTK to do the drawing controls, etc. We don't need gtkmm, as we already provide a suitable C++ API, and it just adds another layer, useless for our purposes, as far as I can tell. We could definitely use the help, given that WxWidgets is pretty much MFC for X, and that, IMHO, VCF is miles away better and easier to use than MFC. Wouldn't it make sense to use that? Or are you really wanting something that is basically one for one API compatible with MFC for X? If this is the case you should really look into wxWidgets. I'm working on a WinGDI over Xlib without the GTK middle man myself. Well then you're in for a special treat. Having tried this myself, here's what you have in store for you (based on my experience): Conceptually the XLib event loop is simple to understand and quite similar to Win32. However the first gotcha comes you realize that there is nothing like a SendMessage() API call. Everything is done asynch, equivalent to PostMessage(). Next you realize that you will have to brush up on your network code - why? Because X is implemented over sockets, and for certain things you need to drop down to that level, especially if you are writing a higher level lib on top of it. For example, lets say you want to implement something equivalent to SendMessage - you'll almost certainly drop down to the socket level using select() and friends. Don't beleive - take a glimpse at the Qt source and you'll see how ugly it gets. Timers - nope, nada, zip. Gotta implement those yourself. Don't waste you're time going to the xlib newsgroups - they'll just repeat the X mantra - "policy not implementation". Next up for fun: fonts. On Win32 you just ask for a font, specify some params, like name, size, weight, etc, and Boom, you get back a handle - no matter what, unless some critical error occurs, you'll get a handle! There is a built in font mapper that's part of the Win32 API. In XLib there is no such thing. You have to implement the font mapping code yourself, or find some 3rd party lib that does. Further more, XLib is done with Ascii character sets in mind - it doesn't do unicode, again you'll to implement this stuff yourself, or find a 3rd party lib. Colors - On Win32 this is pretty simple. You just pick an RGB val and you're done. The HDC will either support it or not, and if it doesn't then it will dither for you. On XLib, of course, nothing is this simple. X supports a bunch of different di
Thanks, but I'm currently reading through the o'reilly XLib library(programming manual series) and I'm aware of the client/server nature of Xlib and it's other limitations. I don't expect xlib to be comparable to win32 or winGDI, I intend to implement what I want of win32 on Xlib. There are ways around alot if not all of the problems you listed. Text can be passed as pointers to a short array instead of a char array, ect... Window hndl = XCreateSimpleWindow(...) Window can by typedef'd to HWND in a pseudo windows.h ext... and I can store it in a .so that people will eventually be able to include. MFC is not even on my radar right now. Basically, first of all I want to emulate most of the functionality in the petzold programming windows book over x as my library and it's header(s) That is my first challenge. And no, I don't want to make it 100% compatible where you can take win source and compile with g++ with my library under pkg-config --libs I only want to expose the API for GDI and windows, not the other stuff, that can stay linux/unix. I want to make it more comfortable for myself and perhaps other win programmers or ex win programmers to make linux UI software. I don't want to make a one touch library that recompiles win code to lin with no modifications. If I am successful doing what I'm going to code now, I will move on to try to put "my favorite aspects" of MFC on top of it in another .so shared lib. I have no intention of doing winAPI verbatim. Thanks for the good advise though, I saved it in my project notes.
-
Thanks, but I'm currently reading through the o'reilly XLib library(programming manual series) and I'm aware of the client/server nature of Xlib and it's other limitations. I don't expect xlib to be comparable to win32 or winGDI, I intend to implement what I want of win32 on Xlib. There are ways around alot if not all of the problems you listed. Text can be passed as pointers to a short array instead of a char array, ect... Window hndl = XCreateSimpleWindow(...) Window can by typedef'd to HWND in a pseudo windows.h ext... and I can store it in a .so that people will eventually be able to include. MFC is not even on my radar right now. Basically, first of all I want to emulate most of the functionality in the petzold programming windows book over x as my library and it's header(s) That is my first challenge. And no, I don't want to make it 100% compatible where you can take win source and compile with g++ with my library under pkg-config --libs I only want to expose the API for GDI and windows, not the other stuff, that can stay linux/unix. I want to make it more comfortable for myself and perhaps other win programmers or ex win programmers to make linux UI software. I don't want to make a one touch library that recompiles win code to lin with no modifications. If I am successful doing what I'm going to code now, I will move on to try to put "my favorite aspects" of MFC on top of it in another .so shared lib. I have no intention of doing winAPI verbatim. Thanks for the good advise though, I saved it in my project notes.
Well you might consider taking a look at the code I wrote for xlib - it may be of some use, and it may be a little easier than trying to look into stuff with Qt or wxWidgets. If you look in http://cvs.sourceforge.net/viewcvs.py/vcf/vcf/src/vcf/ApplicationKit/ And look at the files with a XLL prefix, those are the ones for making the VCF work with raw XLib calls (plus I used imlib2 as well). The stuff in the GraphicsKit kit got zapped - if you look in the file release section you may be able to get code from an older release (say 0-6-2) with the X11 code for the GraphicsKit. Cheers and again, good luck! ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
-
Well you might consider taking a look at the code I wrote for xlib - it may be of some use, and it may be a little easier than trying to look into stuff with Qt or wxWidgets. If you look in http://cvs.sourceforge.net/viewcvs.py/vcf/vcf/src/vcf/ApplicationKit/ And look at the files with a XLL prefix, those are the ones for making the VCF work with raw XLib calls (plus I used imlib2 as well). The stuff in the GraphicsKit kit got zapped - if you look in the file release section you may be able to get code from an older release (say 0-6-2) with the X11 code for the GraphicsKit. Cheers and again, good luck! ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
http://cvs.sourceforge.net/viewcvs.py/vcf/vcf/src/vcf/ApplicationKit/X11Window.cpp?view=markup[^] Ok, I see that this class is most likely your implementation of a CWnd with a couple of methods here and there. void X11Window::setMinimized( const bool& minimized ) { } ... void X11Window::setIconImage( Image* icon ) { } Quite alot of methods missing and unimplemented, I gather you probably gave up on this. This could be helpful seeing how you did things, but it's not really the way I'd ideally like to implement WinGDI over X, so I'm not going to build on it. I thank you very much for it though, I'm sure it will be useful when I'm coding it, if I get stuck, though I have the X protocol reference book as well, and I'll be looking at that to build my implementation. I can really see where you're going with this library and why you may not have had time to implement win over x, but I really have no time table, and I'm ready to waste a good chunk of time on this to get it right. The one person that gets it right will unlock linux and unix to many windows developers that simply don't want to learn GTKmm or your toolkit or any other toolkit for that matter. QT is horrible in my opinion and it costs a fortune for a single developer license. I will not use KDE nor do i use most QT based applications, aside from my ATI control panel that they made with QT for some unknown reason.
-
The linux version, as I mentioned to you in an earlier thread, needs a lot of help. We are using GTK to do the drawing controls, etc. We don't need gtkmm, as we already provide a suitable C++ API, and it just adds another layer, useless for our purposes, as far as I can tell. We could definitely use the help, given that WxWidgets is pretty much MFC for X, and that, IMHO, VCF is miles away better and easier to use than MFC. Wouldn't it make sense to use that? Or are you really wanting something that is basically one for one API compatible with MFC for X? If this is the case you should really look into wxWidgets. I'm working on a WinGDI over Xlib without the GTK middle man myself. Well then you're in for a special treat. Having tried this myself, here's what you have in store for you (based on my experience): Conceptually the XLib event loop is simple to understand and quite similar to Win32. However the first gotcha comes you realize that there is nothing like a SendMessage() API call. Everything is done asynch, equivalent to PostMessage(). Next you realize that you will have to brush up on your network code - why? Because X is implemented over sockets, and for certain things you need to drop down to that level, especially if you are writing a higher level lib on top of it. For example, lets say you want to implement something equivalent to SendMessage - you'll almost certainly drop down to the socket level using select() and friends. Don't beleive - take a glimpse at the Qt source and you'll see how ugly it gets. Timers - nope, nada, zip. Gotta implement those yourself. Don't waste you're time going to the xlib newsgroups - they'll just repeat the X mantra - "policy not implementation". Next up for fun: fonts. On Win32 you just ask for a font, specify some params, like name, size, weight, etc, and Boom, you get back a handle - no matter what, unless some critical error occurs, you'll get a handle! There is a built in font mapper that's part of the Win32 API. In XLib there is no such thing. You have to implement the font mapping code yourself, or find some 3rd party lib that does. Further more, XLib is done with Ascii character sets in mind - it doesn't do unicode, again you'll to implement this stuff yourself, or find a 3rd party lib. Colors - On Win32 this is pretty simple. You just pick an RGB val and you're done. The HDC will either support it or not, and if it doesn't then it will dither for you. On XLib, of course, nothing is this simple. X supports a bunch of different di
Jim - you've probably started my re-occurring nightmares again by describing the development 'experience' with X so accurately - I put together several apps on VMS/DecWindows (which is X/Motif, really) and even using a widget set like Motif didn't help the experience much (except they did have a set of standard dialogs, which made things easier). It was even harder in the days before we got a C compiler (FORTRAN and Ada, anyone ;P). And then we started moving over to Windows...VC++ 5 with MFC4.2 - what a revelation! Needless to say, I've never looked back. Stuart Dootson 'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
-
I'd like to let people know that there's a new release of the VCF available! And before people get all annoyed think this is a commercial advertisement, it's NOT - I make no money from the VCF at all. It's a labor of "love", so to speak, and my attempt to fill a perceived lack in the C++ set of libraries and give something back to others. One of the big new features, and something that numerous people on this board have requested, is printing support. Yes, we now have the ability to print, and popup the common print dialog. An example might look like this:
PrintContext* ctx = session.beginPrintingDocument();
session.beginPage( ctx );//your code here that draws in the ctx
ctx->getCurrentFont()->setName( "Times New Roman" );
ctx->getCurrentFont()->setPointSize( 20 );
ctx->textAt( 100, 100, "Hello World" );session.endPage( ctx );
session.endPrintingDocument();
Another big change is the way we handle resources. Previously we could only access resoruces by loading through the native API's - i.e. if you didn't bind your resoruecs with an RC script, then you were SOL. On top of that, you could only access the resource if your program used the ApplicationKit. Instead, any program can now access resources (through the ResourceBundle[^] class ), and you can add resources either the old way, by using a platform dependant solution (i.e. binding them to the executable through rc scripts), *or* by using the new "Resources" bundle directories. Basically this means you add a directory called "Resources" at the same level as you program executable, and then you put your various resource files in the Resources directory. You can also localize the files by added locale sensitive sub directories like so:
MyCoolAppDir/
MyCoolApp.exe
Resources/
MyCoolApp.strings //this holds all your string translations
Cool.png
NotCool.png
SortaNotCool.png
//localized dirs
en_US/
MyCoolApp.strings -
http://cvs.sourceforge.net/viewcvs.py/vcf/vcf/src/vcf/ApplicationKit/X11Window.cpp?view=markup[^] Ok, I see that this class is most likely your implementation of a CWnd with a couple of methods here and there. void X11Window::setMinimized( const bool& minimized ) { } ... void X11Window::setIconImage( Image* icon ) { } Quite alot of methods missing and unimplemented, I gather you probably gave up on this. This could be helpful seeing how you did things, but it's not really the way I'd ideally like to implement WinGDI over X, so I'm not going to build on it. I thank you very much for it though, I'm sure it will be useful when I'm coding it, if I get stuck, though I have the X protocol reference book as well, and I'll be looking at that to build my implementation. I can really see where you're going with this library and why you may not have had time to implement win over x, but I really have no time table, and I'm ready to waste a good chunk of time on this to get it right. The one person that gets it right will unlock linux and unix to many windows developers that simply don't want to learn GTKmm or your toolkit or any other toolkit for that matter. QT is horrible in my opinion and it costs a fortune for a single developer license. I will not use KDE nor do i use most QT based applications, aside from my ATI control panel that they made with QT for some unknown reason.
The one person that gets it right will unlock linux and unix to many windows developers that simply don't want to learn GTKmm or your toolkit or any other toolkit for that matter. Well the problem there is that people coming from Win32 have a lot of expectations. And if your lib only does drawing, and a few windowing things, then it's not much of a help either, even if it's really nicely designed. The problem is that coming from a Win32 background, people will expect stuff like standard controls, menus, proper font mapping. You realize you'll basically be re-implemnenting all of GTK, right? Unless you just plan to focus on the drawing stuff. Also, what does "get it right" mean? Do you mean an API that pretty closely mirror the Win32 GDI? Why do you think Qt is horrible? I actually think they did a really nice job with it. It's too bad that it's so expensive though. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
-
I'd like to let people know that there's a new release of the VCF available! And before people get all annoyed think this is a commercial advertisement, it's NOT - I make no money from the VCF at all. It's a labor of "love", so to speak, and my attempt to fill a perceived lack in the C++ set of libraries and give something back to others. One of the big new features, and something that numerous people on this board have requested, is printing support. Yes, we now have the ability to print, and popup the common print dialog. An example might look like this:
PrintContext* ctx = session.beginPrintingDocument();
session.beginPage( ctx );//your code here that draws in the ctx
ctx->getCurrentFont()->setName( "Times New Roman" );
ctx->getCurrentFont()->setPointSize( 20 );
ctx->textAt( 100, 100, "Hello World" );session.endPage( ctx );
session.endPrintingDocument();
Another big change is the way we handle resources. Previously we could only access resoruces by loading through the native API's - i.e. if you didn't bind your resoruecs with an RC script, then you were SOL. On top of that, you could only access the resource if your program used the ApplicationKit. Instead, any program can now access resources (through the ResourceBundle[^] class ), and you can add resources either the old way, by using a platform dependant solution (i.e. binding them to the executable through rc scripts), *or* by using the new "Resources" bundle directories. Basically this means you add a directory called "Resources" at the same level as you program executable, and then you put your various resource files in the Resources directory. You can also localize the files by added locale sensitive sub directories like so:
MyCoolAppDir/
MyCoolApp.exe
Resources/
MyCoolApp.strings //this holds all your string translations
Cool.png
NotCool.png
SortaNotCool.png
//localized dirs
en_US/
MyCoolApp.stringsCool! You know, when you've become famous for VCF, I will be able to tell people "I almost know this guy!" :cool: :-D -- Weiter, weiter, ins verderben. Wir müssen leben bis wir sterben. I blog too now[^]
-
The one person that gets it right will unlock linux and unix to many windows developers that simply don't want to learn GTKmm or your toolkit or any other toolkit for that matter. Well the problem there is that people coming from Win32 have a lot of expectations. And if your lib only does drawing, and a few windowing things, then it's not much of a help either, even if it's really nicely designed. The problem is that coming from a Win32 background, people will expect stuff like standard controls, menus, proper font mapping. You realize you'll basically be re-implemnenting all of GTK, right? Unless you just plan to focus on the drawing stuff. Also, what does "get it right" mean? Do you mean an API that pretty closely mirror the Win32 GDI? Why do you think Qt is horrible? I actually think they did a really nice job with it. It's too bad that it's so expensive though. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned
Hi, I don't care what they expect, I'm mainly doing it for myself. GTKmm is ok, but it's not as good as Win32 for me. Yes, I plan on reimplementing it closely to win32 for what I do of it. I think QT is horrible because it's so expensive then all the default projects in KDevelop are using their libraries. I use eclipse CDT now with G++ and the intel compiler and I like it better.