Home » Developing U++ » U++ Developers corner » U++ talk
| Re: U++ talk [message #17923 is a reply to message #17922] |
Wed, 03 September 2008 03:44   |
captainc
Messages: 278
Registered: December 2006
Location: New Jersey, USA
|
Experienced Member |
|
|
| Quote: |
They save the doc in external files. What I said: do exactly the same process. The document manager (not his subordinates) can have a look into the topic++ work (what his subordinate, those without write access to the code, have done) than, if he think that all is ok, he presses a topic++ button and all validated modifications are synchronized back into the source file, ready for doxygen and U++ final release.
|
This would impose a set structure on the topic++ documentation; it would limit the customization of the documentation by the authors. Also, Doxygen/Javadoc is picky. I don't see how reversing Topic++ documentation to Doxygen would be effective. For example, why would you put a tutorial in code documentation? On the other hand, having Doxygen documentation show in Topic++ would be quite helpful. The entire src documentation section could be automatically generated.
|
|
|
|
|
|
| Re: U++ talk [message #17925 is a reply to message #17922] |
Wed, 03 September 2008 09:58 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| amrein wrote on Tue, 02 September 2008 17:37 |
| Quote: |
It's not about creating translation (current system is working great) as contributing documentation. Someone has to write the documentation directly in the source code. That means write access is needed, plus someone has to test that it still compiles.
|
At present, people use topic++ right? They save the doc in external files. What I said: do exactly the same process. The document manager (not his subordinates) can have a look into the topic++ work (what his subordinate, those without write access to the code, have done) than, if he think that all is ok, he presses a topic++ button and all validated modifications are synchronized back into the source file, ready for doxygen and U++ final release.
| Quote: |
If user doesn't have write access, somebody needs to merge the changes for him.
|
Yes, modifications has to be validated. U++ API can break at any time before final release. Two eyes are better than one. You keep total control of the final documentation submitted but your contributors have full access to the topic++ generated documentation.
|
OK, now I see where are you heading. Anyway, this is even more complex that what we wanted to do. And, let me say, perhaps a little bit more risky too.
OTOH, it appears that you would like to do some work on .so etc.
Maybe, as part of this process, you can do exactly this.
I mean, it appears that ".so" work will have to somehow take existing uppsrc and via some nice tool transform it to .so (or, rather, something with makefile that produces .so).
The T++ contains enough information (ok, barely enough, but it is manageable) to put the comments back to the code even now. So do it!
Or, maybe, you can export doxygen to separate files, that is even easier.
BTW, to put things into perspective and understand each other, if you are speaking about Doxygen, I was thinking about putting docs into sources, that is why confusion. Exporting Doxygen formatted docs from T++ is IMO completely unrelated topic and perhaps a good idea, if it can be done with relatively low costs.
Mirek
|
|
|
|
| Re: U++ talk [message #17928 is a reply to message #17925] |
Wed, 03 September 2008 10:23 |
cbpporter
Messages: 1401
Registered: September 2007
|
Ultimate Contributor |
|
|
Yes, we should go forward and get started on .so. The question is how many .sos should we create.
On possible layout would be: one for Core and other non GUI stuff, one For CtrLib and all control and draw, and one for each SQL dialect. There is no way I as a normal user am installing MySQL, Sqlite3 and the other client so that I can install a .so for U++.
Also, I don't know what to do with NOGTK versions of GUI packages. Linking a NOGTK app with a GTK .so (if possible) would give strange results.
Also, with .so distributions comes the problem of devel packages. Traditionally installed .h files would not work well with out packaging scheme so I think we should skip this one and use the RPM/DEB for full U++ packages to get these files.
Edit: also for MT version of lib.
[Updated on: Wed, 03 September 2008 10:28] Report message to a moderator |
|
|
|
| Re: U++ talk [message #17929 is a reply to message #17928] |
Wed, 03 September 2008 11:10 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| cbpporter wrote on Wed, 03 September 2008 04:23 |
Yes, we should go forward and get started on .so. The question is how many .sos should we create.
On possible layout would be: one for Core and other non GUI stuff, one For CtrLib and all control and draw
|
Well, it might not be actual now, but in future, I would like to have "pure" Draw that is not related to X11, to support web applications (which want to draw images, but do not want to have X11 dependency). But that can wait.
Related problem - Image formats. Should it contain all of them? Maybe yes...
| Quote: |
, and one for each SQL dialect.
|
And one for SQL as whole and another for SQL GUI....
Or, maybe, generic Sql can be part of 'core.so' (there are no dependencies) and SQL GUI can be part of 'ctrllib.so' ?
| Quote: |
Also, I don't know what to do with NOGTK versions of GUI packages. Linking a NOGTK app with a GTK .so (if possible) would give strange results.
|
IMO, that is not a real problem, these are just two libraries.
| Quote: |
Also, with .so distributions comes the problem of devel packages. Traditionally installed .h files would not work well with out packaging scheme so I think we should skip this one and use the RPM/DEB for full U++ packages to get these files.
|
Maybe just put 'upp' folder to /usr/include and put all headers there in normal way - I mean, basically, just delete all .cpp files from uppsrc packages, put result into /usr/include/upp and add /usr/include/upp to INCLUDE path.
| Quote: |
Edit: also for MT version of lib.
|
Well, I think, MT should be just activated for .so.
Mirek
[Updated on: Wed, 03 September 2008 11:11] Report message to a moderator |
|
|
|
| Re: U++ talk [message #17939 is a reply to message #17875] |
Wed, 03 September 2008 18:52 |
 |
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
| Quote: |
OK, now I see where are you heading. Anyway, this is even more complex that what we wanted to do. And, let me say, perhaps a little bit more risky too.
|
Yes.
I don't know how to generate complex doxygen doc without including the documentation back into the code.
| Quote: |
OTOH, it appears that you would like to do some work on .so etc.
Maybe, as part of this process, you can do exactly this.
I mean, it appears that ".so" work will have to somehow take existing uppsrc and via some nice tool transform it to .so (or, rather, something with makefile that produces .so).
The T++ contains enough information (ok, barely enough, but it is manageable) to put the comments back to the code even now. So do it!
|
Makefile already done, just for testing. I modified the upp-2008.1 Makefile to see how much disk space a lib.so could take.
At present, I'm trying to learn U++. Doc is not enough to be a good U++ programmer. I really need to build a few small applications (statically linked). I'm still a real noob in U++.
When I will feel ready, I will work on TheIDE source code to generate Makefile able to produce dynamic libraries from uppsrc packages and certainly also on U++ missing documentation.
| Quote: |
Or, maybe, you can export doxygen to separate files, that is even easier.
BTW, to put things into perspective and understand each other, if you are speaking about Doxygen, I was thinking about putting docs into sources, that is why confusion. Exporting Doxygen formatted docs from T++ is IMO completely unrelated topic and perhaps a good idea, if it can be done with relatively low costs.
Mirek
|
I think you mean Topic++ will still use external files but TheIDE will be able to show them directly side by side in the code editor, right?
| Quote: |
There is no way I as a normal user am installing MySQL, Sqlite3 and the other client so that I can install a .so for U++.
|
No need to. Same goes for Qt, wxWindows, Gnomedb, Kde, Gambas, ...
| Quote: |
On possible layout would be: one for Core and other non GUI stuff, one For CtrLib and all control and draw, and one for each SQL dialect.
|
The idea in the sent list (other thread) was to have several libs. Each directory in level 3 could be a library:
./source/upp/core
./source/upp/gui/core/x11
./source/upp/gui/core/win
./source/upp/gui/core/osx
./source/upp/gui/core/directfb
./source/upp/gui/library
./source/upp/gui/dialogs/x11
./source/upp/gui/dialogs/win
./source/upp/gui/dialogs/osx
./source/upp/network
./source/upp/database
./source/upp/database/oracle
./source/upp/database/odbc
./source/upp/database/sqlite
./source/upp/database/mysql
./source/upp/database/postgresql
./source/upp/dbus
./source/upp/opengl
./source/upp/xml
./source/upp/sound
./source/upp/video
./source/upp/html
./source/upp/script
./source/upp/richtext
./source/theide/...
./source/unstable/my_unstable_ide/
(...)
Core, Gui, Network, Database, Opengl, XML could be dynamic libraries. Upp could be an all in one library too.
How to have X11 or directFb back end is a good question. Build several libraries like wxWindows: gui-x11, gui-directfb, gui-gtk? Other solution: gui-core load its screen plugin (x11, directfb, linuxfb, javascript, ...) at runtime.
QtEmbedded does this for Qtopia: if you don't provide a special switch the lib try to connect to the Linux framebuffer, if not it connect to the framebuffer simulator. At compile time, you can remove the ability to connect to different backend and select the main one.
[Updated on: Wed, 03 September 2008 19:02] Report message to a moderator |
|
|
|
|
|
| Re: U++ talk [message #17944 is a reply to message #17939] |
Wed, 03 September 2008 23:00 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Quote: |
I think you mean Topic++ will still use external files but TheIDE will be able to show them directly side by side in the code editor, right?
|
Of course, but not only. Maybe, as complete unrelated issue, we can provide doxygen export.
AFAIK, doxygen allows separated documents too. So we can export such files.
| Quote: |
| Quote: |
There is no way I as a normal user am installing MySQL, Sqlite3 and the other client so that I can install a .so for U++.
|
No need to. Same goes for Qt, wxWindows, Gnomedb, Kde, Gambas, ...
|
What goes for them? I am lost 
Mirek
|
|
|
|
| Re: U++ talk [message #17948 is a reply to message #17944] |
Thu, 04 September 2008 04:52 |
cbpporter
Messages: 1401
Registered: September 2007
|
Ultimate Contributor |
|
|
This could be a possible list of packages to go into the first .so and also some thoughts regarding them:
- Core
- Crypto (also, add description to Crypt and maybe AES - I still have a textbook AES somewhere if you're interested)
- Esc (Esc is a pretty nice minimal scripting language, perfect to embed in your code, so we could include it. OTOH, a plan for the future: make Esc a strict subset of and existing and established scripting language, so that Esc works in that language, but not the other way around necessarily. There is a myriad of scripting languages for any given purpose, and I don't think we or the world needs a new one. Or maybe replace Esc with something small like Lua, but Lua is not my first choice for what Esc should accomplish)
- Geom (also maybe clean-up and decide future of it)
- Geom\Coords (this package depends on TCore package, which is empty; also same clean-up as with Geom)
- plugin/astyle - maybe (add description)
- plugin/bz2
- plugin/dbf - maybe, I don't know exactly what it is and if it is related to the old database format, in which case we may decide move it to DB .so (also add description)
- plugin/ftp
- plugin/pcre - I didn't even know we had regexp, this should be advertised more (add description)
- plugin/z (also, I think it shouldn't be a requirement for basic Core console app)
- Web and friends (add description, and some parts are in need of some extensions)
This would basically be it. I hope I didn't miss any packages.
The question is what to do about image format packages. Some can be included without Draw, while others can't. The best solution would be to make these plugins work with in-memory images and streams, and registering the encoder/decoder, and Draw stuff being able to work with those images and display them as soon as the required plugin is included. This way it would also work for servers (like the way gdlib is used for this purpose).
We could still squeeze in PNG and maybe some other formats which work without GUI packages right now.
So there would be a first .so with maybe some graphical formats. I see 3 more .sos at least: one for GTK GUI, one for NOGTK GUI (but we do need a new default skin for that, because that look is worst than Gtk 1, which was ugly as hell, and doesn't really fit in with any modern look) and at least a SQL .so.
Also, either build packages for MT, or double the number of .sos.
This is just a proposal though. The important thing is getting them out one by one, and not focus on getting all the .so structures at once. We need some time and get it right, because once you settle on something, it is going to be harder to change it.
Also, some other crazy ideas: make U++ able to run and draw it's own windows when in a framebuffer like environment. This way it could run on the Linux framebuffer, or in a normal WinAPI window, but in DirectX buffers for games. I did some hobby gamedev in the past and there was always the problem of GUI toolkit able to render itself in the DirectX framebuffer. And if this works, why not make it work in a console, for text mode GUI's. We could call it UltimateVision++   .
|
|
|
|
| Re: U++ talk [message #17950 is a reply to message #17948] |
Thu, 04 September 2008 09:30 |
mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
| Quote: |
- plugin/pcre - I didn't even know we had regexp, this should be advertised more (add description)
|
WOW, I did wish for this one, and I missed it completely when I took a short look at packages.
It should be listed somewhere in features.
Now I see there is reference/RegExp, I can't understand how I missed it.  Must have been that "I'm blind" moment.
I may be wrong, but doesn't the Core depend on the compression a bit with some files? For example .iml data, aren't they compressed?
(I'm asking, I have no idea what's the true)
I know you don't need .iml files for console application, so if your first ".so" is supposed to be like minimal bare Core library with minimal dependencies, and adding "z" later trough extending .so is of no problem, then your point is still valid.
I wonder also how we will combine those .so in final application? How should it work, like having core.so + guigtk.so + sql.so + application, with each ".so" having different functions and working together? I think there may be some funny stuff about making the memory allocator to work together across all the .dll files, but my knowledge is next to none, so if somebody has serious experience/knowledge, I would welcome some explanation how such application should work (the bigger picture).
|
|
|
|
| Re: U++ talk [message #17953 is a reply to message #17950] |
Thu, 04 September 2008 12:45 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| mr_ped wrote on Thu, 04 September 2008 03:30 |
I may be wrong, but doesn't the Core depend on the compression a bit with some files? For example .iml data, aren't they compressed?
(I'm asking, I have no idea what's the true)
|
It does. zlib has to be mandatory.
| Quote: |
I wonder also how we will combine those .so in final application? How should it work, like having core.so + guigtk.so + sql.so + application, with each ".so" having different functions and working together?
|
Yes. In fact, this is not uncommon - GTK = gobject + gdk + gtk.... (roughly equals to Core, Draw and CtrlLib+CtrlCore).
Sure, for those of us that understand and use U++ way of things, this sounds just like stone-age solution. But .so are for those that do not, I guess
| Quote: |
I think there may be some funny stuff about making the memory allocator to work together across all the .dll files, but my knowledge is next to none, so if somebody has serious experience/knowledge, I would welcome some explanation how such application should work (the bigger picture).
|
Well, in the very worst case, we can just compile .so with NOMALLOC.
Anyway, I believe that if core.so is first, it will override new/delete for the rest.
AFAIK, the same applies in Win32. The trick (AFAIK!) is that linker searches .lib files for symbols in the order they are specified on commandline. new/delete are defined in standard c++ library, but that, as default, gets searched last.
Then, when linking, references are directed to the .so/.dll that contains the symbol...
Mirek
|
|
|
|
| Re: U++ talk [message #17955 is a reply to message #17944] |
Thu, 04 September 2008 13:38 |
|
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
| Quote: |
| Quote: |
| Quote: |
There is no way I as a normal user am installing MySQL, Sqlite3 and the other client so that I can install a .so for U++.
|
No need to. Same goes for Qt, wxWindows, Gnomedb, Kde, Gambas, ...
|
What goes for them? I am lost
|
He said: if I install U++ dynamic libraries, I don't want all database to be installed. I reply "No need to". Other libraries have solutions to solve this.
When you install those dynamic libraries, there is no dependencies with the database. You don't need to install any of them. The database plugins (with database dependencies) are separated from the main package:
# urpmq --list | grep qt3 | sort
libqt3
libqt3-devel
libqt3-mysql
libqt3-odbc
libqt3-psql
libqt3-sqlite
libqt3-static-devel
libqt3support4
qt3-assistant
qt3-common
qt3-doc
qt3-example
qt3-linguist
qt3-tutorial
I mean, there is no rpm/deb dependencies between your application and the database binary as long as you don't link against one of those plugins. Database connections are done at runtime with the plugins and only if those database are available. Your application can list dynamically all available database plugins. You only need headers and libs from MySQL, Sqlite, ... when you build all packages from U++.
Examples:
In Qt3, If your application need ODBC only, you need to install libqt3-odbc and its dependencies (libqt3-odbc needs libqt3 and libunixODBC1).
Gambas goes farer: its plugins doesn't install database dependencies. They try to load those dependencies at runtime and if your program ask for MySQL, the plugin can answer "MySQL lib not available" or "Good, it's there, I load it".
|
|
|
|
| Re: U++ talk [message #17956 is a reply to message #17948] |
Thu, 04 September 2008 13:41 |
|
amrein
Messages: 278
Registered: August 2008
Location: France
|
Experienced Member |
|
|
| Quote: |
Also, some other crazy ideas: make U++ able to run and draw it's own windows when in a framebuffer like environment. This way it could run on the Linux framebuffer, or in a normal WinAPI window, but in DirectX buffers for games. I did some hobby gamedev in the past and there was always the problem of GUI toolkit able to render itself in the DirectX framebuffer. And if this works, why not make it work in a console, for text mode GUI's. We could call it UltimateVision++ .
|
Or UltimateTUI (text user interface) 
If draw use plugins for backend, you can think about plugins like: X11, text/console, pdf, DirectX, SDL, xml ...
[Updated on: Thu, 04 September 2008 13:48] Report message to a moderator |
|
|
|
| Re: U++ talk [message #17962 is a reply to message #17955] |
Thu, 04 September 2008 21:54 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| amrein wrote on Thu, 04 September 2008 07:38 |
| Quote: |
| Quote: |
| Quote: |
There is no way I as a normal user am installing MySQL, Sqlite3 and the other client so that I can install a .so for U++.
|
No need to. Same goes for Qt, wxWindows, Gnomedb, Kde, Gambas, ...
|
What goes for them? I am lost
|
He said: if I install U++ dynamic libraries, I don't want all database to be installed. I reply "No need to". Other libraries have solutions to solve this.
When you install those dynamic libraries, there is no dependencies with the database. You don't need to install any of them.
|
Well, this is consistent with what I think we need....
Mirek
|
|
|
|
| Re: U++ talk [message #17963 is a reply to message #17956] |
Thu, 04 September 2008 21:55 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| amrein wrote on Thu, 04 September 2008 07:41 |
| Quote: |
Also, some other crazy ideas: make U++ able to run and draw it's own windows when in a framebuffer like environment. This way it could run on the Linux framebuffer, or in a normal WinAPI window, but in DirectX buffers for games. I did some hobby gamedev in the past and there was always the problem of GUI toolkit able to render itself in the DirectX framebuffer. And if this works, why not make it work in a console, for text mode GUI's. We could call it UltimateVision++ .
|
Or UltimateTUI (text user interface)
If draw use plugins for backend, you can think about plugins like: X11, text/console, pdf, DirectX, SDL, xml ...
|
I was thinking about it too, but I am afraid it perhaps is not really possible to make CtrlLib run in textmode. But I might be wrong...
Mirek
|
|
|
|
|
|
|
|
|
|
| Re: U++ talk [message #18046 is a reply to message #18043] |
Mon, 08 September 2008 05:01 |
Novo
Messages: 1358
Registered: December 2006
|
Ultimate Contributor |
|
|
| Mindtraveller wrote on Sun, 07 September 2008 17:34 |
I wonder if it really makes sense - making text version of such a complex library. For me it is hard to imagine typical scenario where text support should be necessary.
99% of modern PC handle graphics - they don`t really need text mode support. Those who don`t (some kind of controllers or may be very special purpose computers) usually don`t have wide support for advanced character work (such as on-screen character attributes support) - so text version of library should be mostly unsupported.
|
Let me not agree with you. If you are working with Linux all the time, you just cannot do anything without text mode. X-Window + SSH are working at acceptable speed only if you have gigabyte network. Even in case of such combination TheIDE is not very fast, I would say it is somewhat slow. It is just not possible to use TheIDE over cable modem. Of curse, there is no such problem if you have a Linux desktop. No network. No SSH.
The only comfortable way for me to work in Linux is to use *vi*. I would use TheIDE just as a text editor, if I could adapt it to understand Makefiles. The build system of TheIDE, which I would like to use at home (in case if I can adapt it to my previous build system ), is not that important at work, where I can use distcc against 6 servers with 8 CPU-cores each.
Regards,
Novo
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 20 11:40:32 CEST 2024
Total time taken to generate the page: 0.04887 seconds
|
Members
Pages
Help
Register
Login
Home
