Using gtkmm with Visual C++ and _SECURE_SCL=0
2008/10/18 Armin Burgmeier [EMAIL PROTECTED]: On Fri, 2008-10-17 at 16:05 +0200, Thomas Frank wrote: I searched for _SECURE_SCL in the archives but didn't get any results. Has this ever been a topic? I didn't even know this option existed. Of course, we could enable this for the gtkmm runtime binaries, but then people need to set the same flag in their applications, which is just one step more that could go wrong. This is why I would rather avoid it. _SECURE_SCL=1 is similar to libstdc++ Debug Mode - http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html quote To use the libstdc++ debug mode, compile your application with the compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the sizes and behavior of standard class templates such as std::vector, and therefore you can only link code compiled with debug mode and code compiled without debug mode if no instantiation of a container is passed between the two translation units. /quote which means binary incompatibility. We could also supply release binaries for both _SECURE_SCL=0 and _SECURE_SCL=1 (so we would have 6 different VC++ DLLs for each C++ module). Again, I'm not quite happy with this considering the duplication it involves. How many applications do (need to) use the _SECURE_SCL=0 option? Is it kind of standard that it is used for release builds? The VS default release build doesn't define _SECURE_SCL=0 by default, AFAIK. If you just compile the header files define _SECURE_SCL=1 by default. If not, then I'm sorry, but I don't think it's reasonable to support all the different MSVC++ compiler settings that produce incompatible binaries. Just because there are too much of them. My impressions is, that performance suffers when using std containers and algorithm with _SECURE_SCL=1. This might be a problem when i.e. doing heavy duty text processing using the stl. I for example was bitten by _SECURE_SCL=1 being the default :-). Coding a ND-LookupTable, mingw-gcc-4.2.3 outperformed msvc-8.0 by a factor of 2.5. A few month later I've read posting about this topic at the boost-ML. Rebuilding everything with _SECURE_SCL=0 made msvc outperform gcc by a factor of 1.3. However, considering the rules posted on [1], I don't see an easy workaround for your problem without rebuilding the involved C++ libraries. It would be best to have generic build scripts for msvc. Do the autotools scripts work with CC=cl CXX=cl? A workaround is using LoadLibrary to open _SECURE_SCL=0 compiled DSOs containing performance critical code. Best, -- Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using CMake wiki page notice
Am Mittwoch, den 20.12.2006, 01:32 +0100 schrieb Marko Anastasov: http://live.gnome.org/gtkmm/UsingCMake It's just a simple example, I don't know very much about CMake ATM. Actually a guy on the cmake-list showed me how to do it with pkg-config properly, This guy was me ;) I was trying something on my own but it wasn't perfect. Anyway, later I or anyone can update it to show how to check for a particular version etc, so that we can have one good place to copy and paste from if and when we want to use CMake :). Marko ___ I want to say some word about cmake. Its a meta build system, since it doesn't build anything but Makefiles(i.e. for gnu's make or msvc's nmake) or IDE project files (KDevelop, .NET Studio). For unix like systems this means: * autoheader * aclocal * autoconf * automake * ./configure * make turns into * cmake ../ # we did 'mkdir build cd build' at the project folder * make It combines autoconf and automake, but isn't gnu-centric. The autotools are slow as hell on Win32 plus the cmake error messages make it much easier to track problems down. The most important drawback is: cmake doesn't install anything by default(the autotools use conventions: bin_progexe - .. /usr/bin/progexe ). You have to use the install(... cmake macro. I did some work on CMake and gmmproc and libgnomevfsmm builds including all the .hg/.ccg to h/p_h/cc and corresponding dependency checking stuff. I will add the Module to the wiki page. But before you scream for cmake as the new portable(i.e. build gtkmm out of the box using msvc) build system consider this: KDE changed to cmake, but gnome isn't KDE. For building gnome proper a hole bunch of libs has to be build in configuration-sync with each other. IMHO the autotools are a joy for maintainers but a hassle for developers. IMHO CMake is a joy for developers, but it has to be proven for not being a hassle for maintainers. For just building apps, cmake is the best choice I know. Its easy to use, easy to extend and OS/compiler portable. Best regards, Maik Beckmann ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Hash Tables?
Am Dienstag, den 05.12.2006, 17:58 -0500 schrieb Daniel Levin: Hi - I haven't been able to find any information on how to use hash tables, such as in GLib. Is there a hash table implementation in glibmm? Thanks, Dan I never used them but... ...since hash tables and the related unordered_map are part of TR1, they will be provided by (hopefully) every c++ compiler soon. My gcc-4.1.1 ships: tr1-dir array functional_iterate.h ref_wrap_iterate.h type_traits_fwd.h bind_iterate.h hashtable repeat.h unordered_map bind_repeat.h memory tuple unordered_set boost_shared_ptr.h mu_iterate.h tuple_iterate.h utility functional ref_fwd.h type_traits /tr1-dir Hashes are part of boost too: http://boost.org/doc/html/hash.html Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk window.show() (maybe just c++ related)
Hi,
Please consider any foo widget with a show() method.
Why :
foo* foo1=new(foo);
foo-show();
shows the widget, but:
foo foo1;
foo.show();
does not?
I assume the code you posted is inside a constructor or GUI-arrange
function.
Consider this:
{ // enter scope
...
foo* foo_ptr=new(foo);
bar_container-add(*foo_ptr);
foo_ptr-show();
foo foo_obj;
bar_container-add(foo_obj);
foo_obj.show();
...
} // leave scope
foo_obj will be destroyed, gtk+ can't show it because its gone.
foo_ptr is destroyed too, but the object it pointed to still lives.
MfG Maik
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk window.show() (maybe just c++ related)
Am Samstag, den 02.12.2006, 12:58 +0100 schrieb eric jrdn2: Thank you, the assumptions you made are right. Another newbie question: Should I call delete() on each widget created with new() inside this widget1, or will widget1 do it itself when it will die? Sorry for such a lame understanding of c++ :-) You sent this message to my private e-mail address. Please re-send it to gtkmm-list@gnome.org Maik I did a reply to all, it is on the list too. Eric Sorry for this, evolution seems to play tricks on me ;) Your question on calling delete or not isn't C++ specific, but framework specific. If you want this framework, Gtkmm , to manage your heap object you write: foo* foo_ptr = Gtk::manage(new foo() ); bar_container-add(*foo_ptr); When bar_container is destroyed the object foo_ptr pointed to will be destroyed too. If you just do foo* foo_ptr = new foo() ; bar_container-add(*foo_ptr); you have to save foo_ptr and call delete on it before your app ends. MfG Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: virtual signal system ?
Am Samstag, den 11.11.2006, 11:42 -0500 schrieb Paul Davis: k3d has nothing on ardour (http://ardour.org/), where we have upwards of 2000 widgets visible on the screen sometimes. from a theoretical perspective, the design in GFC is interesting and appears more efficient in terms of space. however, i cannot honestly say that i have ever detected the size of the virtual function tables in gtkmm to be a problem, or even a hint of a problem. Just a comment... As one can read here - http://xfc.xfce.org/history.xhtml xfc(Xfce Foundations Classes) - http://xfc.xfce.org/index.xhtml is the successor of of GFC. GFC is the successor of Inti - http://inti.sourceforge.net/index.html The person behind this is Jeff Franks. But he seems to be missed for while now - http://foo-projects.org/pipermail/xfc-dev/2006-May/000159.html Did someone receive vital signs of him? Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gnome::Vfs::DirectoryHandle::list_load
I sent a bug report: http://bugzilla.gnome.org/show_bug.cgi?id=371487 I coded an working alternative(see bug report). Please comment it. Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Eclipse plugin
Hello! is there an eclipse plugin that will speed up and ease the UI development with GTKmm. I would like to find out if there is a development kit that will allow me to drag and drop the widgets/objects (buttons, ...), and the kit will generate the GTKmm code... Is there maybe an eclipse plugin that can do that? Thnx, Sasa The bad news first: AFAIK there isn't any kind of UI wizard eclipse plug-in for any kind of C/C++ GUI-toolkit. The good new: GLADE! http://glade.gnome.org/ The UI you created with glade is stored into a xml file. There is no need to generate code: http://gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/ch23.html (Note: a library named libglademm does the work) For learning gtkmm it may also be useful to generate code out of glades xml files. This can be done by: a application named glademm - http://home.wtal.de/petig/Gtk/ Regards, Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Gnome::Vfs::DirectoryHandle::list_load
Hello
I think there is something wrong with the gnome-vfsmm the static
member-function of Gnome::Vfs::DirectoryHandle:
static void list_load(const Glib::ListHandleGlib::ustring list,
const Glib::ustring text_uri,
FileInfoOptions info_options) throw(exception);
See this little example program:
code
#include libgnomevfsmm.h
#include iostream
#include list
int main(int argc, char** argv)
{
Gnome::Vfs::init();
std::listGlib::ustringlist;
Glib::ListHandleGlib::ustring listHandle(list);
Gnome::Vfs::DirectoryHandle::list_load(
listHandle,
ftp://ftp.gnome.org;,
Gnome::Vfs::FILE_INFO_DEFAULT );
std::cout list.size() std::endl;
// --
GList* glist;
gnome_vfs_directory_list_load(
glist,
ftp://ftp.gnome.org;,
static_castGnomeVFSFileInfoOptions(Gnome::Vfs::FILE_INFO_DEFAULT) );
std::cout g_list_length(glist) std::endl; // prints: 17
GnomeVFSFileInfo* info =
static_castGnomeVFSFileInfo*(g_list_nth_data(glist,5));
std::cout info-name std::endl;
return 0;
}
/code
output
0
17
conspiracy
/output
The GList holds pointers GnomeVFSFileInfo structures, so Glib::ustring
being ListHandle-type makes no sense to me.
Is this a bug or didn't I get how to use this this function?
Maik
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gnome::Vfs::DirectoryHandle::list_load
Robert Caryl: I'd suggest that you submit this to: gnome-devel-list@gnome.org and you'll probably get some good answers. I don't think gnome-devel is the right place, since the problem I mentioned seems to be an wrapper issue. AFAIK the related gnomemm-list was closed: http://marc.theaimsgroup.com/?l=gnomemm-listm=114918803729469w=2 Regards, Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Widget::destory() ?
Am Dienstag, den 10.10.2006, 15:46 +0200 schrieb Murray Cumming: On Fri, 2006-10-06 at 11:28 -0500, Jonathon Jongsma wrote: ...which means that the documentation that Maik brought up at the beginning of this thread should really be changed so that it doesn't mention anything about Gtk::Widget::Destroy() (which doesn't exist) but instead tell people to 'delete' the widget in the normal C++ way. Fixed. The new Version: void Gtk::Container::remove (Widget widget) Removes widget from container. widget must be inside container. If widget is managed with Gtk::manage(), and you don't want to use widget again then you should delete widget , because there will no longer be any parent container to delete it automatically. This is correct, but I think the following is clearer widget must be inside container. If widget is a pointer to a Widget allocated on heap by new in combination with Gtk::manage(), there will no longer be any parent container to delete widget automatically. So if you don't want to use widget again, then you should apply the delete opereator to widget after removing it. regards, Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Fwd: Re: Gtk::Widget::destory() ?
vbox-remove( *pbar ) ; At this point it should be destroyed automatically. No, child widgets are not destroyed when you remove them (well, since we fixed that bug, in 2.6 or 2.8). That would be quite random. They _are_ destroyed, if they are managed, when the parent container is destroyed, if the child is _still_ a child of that parent. -- Murray Cumming So calling gtk_widget_destroy is a good way to prevent an unnecessary memory consuption, if a huge number of Widgets is created on the fly ? greetz Maik -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Gtk::Widget::destory() ?
Hello List On http://gtkmm.org/docs/gtkmm-2.4/docs/reference/html/classGtk_1_1Container.html#9f31c07118f7bdc7a4e0651acf35abbc in the description for void Gtk::Container::remove ( Widget widget ) one can read: ... If you don't want to use widget again it's usually more efficient to simply destroy it directly using Gtk::Widget::destroy() since this will remove it from the container and help break any circular reference count cycles. But there is no Gtk::Widget::destroy(), or is there something I didn't get right? greetz Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: verbose exception
I like this idea. But what about a structure like this: #ifndef DEBUG_VE_USE_EXCEPTIONS #define VE_THROW_???_???(..., info, ...) \ std::cerr info std::endl; #else DEBUG_VE_USE_VERBOSE_EXCEPTIONS #define VE_THROW_???_???(..., info, ...) \ /* the verbose exception */ \ ... \ ... #endif greetz, Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::StatusIcon 'activate' signal
Hello Rui, I am no gtkmm developer, but I guess the the activate signal was not implemented so far. When you look at gtk/src/statusicon.hg you will see _IGNORE_SIGNAL(activate); Change this to _WRAP_SIGNAL(void activate(), activate); and use gmmproc as described at http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/aphs03.html After a short re-make you should be able to use signal_activate() as intended - For me it worked. I hope you can use this information Maik Beckmann http://eigenco.de Rui Tiago Cação Matos wrote: Hi all, I'm trying to use the new Gtk::StatusIcon in gtkmm 2.10.1 but I can't find the activate signal either in the documentation or the header file. Note: I'm learning gtk+ and gtkmm at the same time so I might be missing some really simple thing. One thing I noticed until now is that the gtk+ documentation seems to be much more comprehensive and easier to navigate/find what you need. Thanks, Rui ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using CMake
Hello
I'm using the autotools on linux and cmake on winxp (at work). The
UsePkgConfig macro seems to be a gcc only hack. Here is an additional
macro which uses UsePkgConfig, but returns the compiler independent
information cmake needs.(I didn't tried anything else than mingw until
now, please give response.)
greetz Maik
*** the macro... cmake-version =2.4:
## FILE...
include(UsePkgConfig)
MACRO(PKGCONFIG_PARSE_FLAGS FLAGS INCLUDES DEFINES)
#MESSAGE(DEBUG: FLAGS: ${FLAGS})
STRING(REGEX MATCHALL -I[^ ]* ${INCLUDES} ${FLAGS})
STRING(REGEX REPLACE -I ${INCLUDES} ${${INCLUDES}})
#MESSAGE(DEBUG: INCLUDES: ${${INCLUDES}})
STRING(REGEX REPLACE -I[^ ]* ${DEFINES} ${FLAGS})
#MESSAGE(DEBUG: DEFINES: ${${DEFINES}})
ENDMACRO(PKGCONFIG_PARSE_FLAGS)
MACRO(PKGCONFIG_PARSE_LIBS LIBS LINKDIRS LINKLIBS)
#MESSAGE(DEBUG: LIBS: ${LIBS})
STRING(REGEX MATCHALL -L[^ ]* ${LINKDIRS} ${LIBS})
STRING(REGEX REPLACE -L ${LINKDIRS} ${${LINKDIRS}})
#MESSAGE(DEBUG: LINKDIRS: ${${LINKDIRS}})
STRING(REGEX MATCHALL -l[^ ]* ${LINKLIBS} ${LIBS})
STRING(REGEX REPLACE -l ${LINKLIBS} ${${LINKLIBS}})
#MESSAGE(DEBUG: LINKLIBS: ${${LINKLIBS}})
ENDMACRO(PKGCONFIG_PARSE_LIBS)
MACRO(PKGCONFIG_PARSE LIB ICDS LDIRS LIBS DEFS)
PKGCONFIG(${LIB} INCLUDE_DIRS LIB_DIRS LIBFLAGS CFLAGS)
PKGCONFIG_PARSE_FLAGS( ${CFLAGS} ${ICDS} ${DEFS})
PKGCONFIG_PARSE_LIBS( ${LIBFLAGS} ${LDIRS} ${LIBS} )
ENDMACRO(PKGCONFIG_PARSE)
## ... EOF
* I saved it to /home/maik/cmake/PkgConfigParser.cmake
*** usage for a 'main.cc' in folder 'src'
** CMakeLists.txt :
## FILE...
project(tests)
include(/home/maik/cmake/PkgConfigParser.cmake)
pkgconfig_parse(gtkmm-2.4 gtkmm_inc gtkmm_ldirs gtkmm_libs gtkmm_def)
include_directories( ${gtkmm_inc} )
link_directories( ${gtkmm_ldirs} )
add_executable(test1 src/main.cc)
target_link_libraries(test1 ${gtkmm_libs})
## ... EOF
** main.cc:
// FILE ...
#includegtkmm.h
int main(int argc, char** argv) {
Gtk::Main kit(argc,argv);
Gtk::Window win;
win.show();
Gtk::Main::run(win);
return 0;
}
// ... EOF
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
gtkmm wiki
Hello! I searched for a gtkmm-wiki for being able to share my spare knowledge ;) with other people. What I found was this post: http://marc.theaimsgroup.com/?l=gtkmmm=111590792131148w=2 Are there some news about this? greetz Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
ustring bug?
Hello!
This code
code
#include glibmm.h
#include iostream
int main(int argc, char **argv) {
Glib::ustring ustr ( hää? );
try {
Glib::locale_from_utf8(ustr);
} catch (Glib::ConvertError e) {
std::cout e.what() std::endl;
}
return 0;
}
/code
produces
output
Invalid byte sequence in conversion input
/output
Is this the normal behavior of glibmm? If not, can some of you compile
it and give me response, please.
Thanks in advance, Maik
PS:
I'm using
glib-2.12.1
glibmm-2.11.3
on a gentoo-linux x86 maschine with this
[EMAIL PROTECTED] ~ $ locale
LANG=de_DE.utf8
LC_CTYPE=de_DE.utf8
LC_NUMERIC=de_DE.utf8
LC_TIME=de_DE.utf8
LC_COLLATE=de_DE.utf8
LC_MONETARY=de_DE.utf8
LC_MESSAGES=de_DE.utf8
LC_PAPER=de_DE.utf8
LC_NAME=de_DE.utf8
LC_ADDRESS=de_DE.utf8
LC_TELEPHONE=de_DE.utf8
LC_MEASUREMENT=de_DE.utf8
LC_IDENTIFICATION=de_DE.utf8
LC_ALL=de_DE.utf8
locales.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring bug?
Hello Dodji
Do not forget to call setlocale (LC_ALL, ) to initialize the charset
conversion subsytem.
You are right, this version works:
code
#include glibmm.h
#include iostream
int main(int argc, char **argv) {
// edit
setlocale (LC_ALL, );
// /edit
Glib::ustring ustr ( hää? );
try {
Glib::locale_from_utf8(ustr);
} catch (Glib::ConvertError e) {
std::cout e.what() std::endl;
}
return 0;
}
/code
Even
setlocale (LC_ALL, de_DE.utf8)
works. Thank you Dodji, I did not know that setlocale is necessary.
Also, I think ustring(foo) cannot work properly if foo is not a
valid utf8 sequence.
In your case, foo is not. So if foo is a string for which each
character can fit in one byte, you should rather put foo in a
std::string and convert it to a valid utf8 string using
Glib::locale_to_utf8() .
foo works all the way, but füü will only if setlocale is called. As
far as I know this is caused by the hehavior of utf8 only to use more
than 8 Bits for an non-ASCII character. But I didn't know about
setlocale, until today ;)
I will google for it.
regards, Maik
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ustring bug?
After googleing arround I found out, that string loc = setlocale(LC_ALL,); cout loc endl; sets the right locale und even prints it to the screen (im my case de_DE.utf8). I think it's a good idea to put this information into the Glib::ustring reference and the two part in the book concerning ustring: 3. Basics Glib::ustring 22. Internationalization and Localization Expecting UTF8 Thanks again Dodji and good night Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
gtkmm wiki
Hello! I searched for a gtkmm-wiki for being able to share my spare knowledge ;) with other people. What I found was this post: http://marc.theaimsgroup.com/?l=gtkmmm=111590792131148w=2 Are there some news about this? greetz Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm wiki
Another topic regarding documentation. I think the docs for using gtkmm are at a good state. I'm not a newbie and no pro, but I know mastering a gui-toolkit is only one thing about coding an app. There are two things which come to my mind when looking back: First: In the the beginning I tried to code everything by myself because it was just about having fun. But when doing real work it seems to be an holy rule to use existing libs! Second: Understanding and adaoting examples is an efficient way to get things done. I want (or have to) make things portable! There is a hole bunch of c++ libs(e.g. boost), wrappers(e.g. libxml++, gtkmm) and c libs which are useful without a wrapper (e.g. gsl) out there to accomplish this, but nearly no docs about using them together. If I figured out how to get something done I want to shared this by writing an documented example. I might not be the only one ;) I don't think it's the task of gtkmm to provide the ability to do this and I'm not sure about if it's gnome's business to provide docs about using gtk or gtkmm for making none-gnome apps. ??? any ideas ??? greetz, Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
C++ Portable Components: poco
Hello! What your're thinking about this all in wonder library HP: http://appinf.com/poco/info/index.html Sourceforge: http://sourceforge.net/projects/poco It's under boost-license and has been written for embedded system. I wrote a ebuild for my gentoo system and it takes about 14MB (without docs) localhost poco # equery size poco [ Searching for packages matching poco... ] * size of dev-cpp/poco-1.1.2 Total files : 417 Total size : 13907.10 KiB The reason why I'm asking this list is . . . will I be flamed if I'm going to use this kind of none-community libs? Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: C++ Portable Components: poco
Am Donnerstag, den 27.07.2006, 22:26 +0200 schrieb Murray Cumming: On Thu, 2006-07-27 at 21:59 +0200, Maik Beckmann wrote: Hello! What your're thinking about this all in wonder library HP: http://appinf.com/poco/info/index.html Sourceforge: http://sourceforge.net/projects/poco It's under boost-license and has been written for embedded system. I wrote a ebuild for my gentoo system and it takes about 14MB (without docs) localhost poco # equery size poco [ Searching for packages matching poco... ] * size of dev-cpp/poco-1.1.2 Total files : 417 Total size : 13907.10 KiB That's probably mostly all debugging symbols. Regular distributions would provide stripped libraries. The reason why I'm asking this list is . . . will I be flamed if I'm going to use this kind of none-community libs? I've never heard of it before. It's open source. You should use what you like, and I can't imagine why anybody would want you not to. Ok, I try to reimplement some of the Qt4-doc examples (i.e. ftp client, bittorrent client ...). It will take some time. Maik ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
