gestiong-development — Development of GestiONG

[Gestiong-development] problems with the subscription

[<go...@fe...>]

Hi,

I have read all these messages just know, with the monthly digest. I  
don't know if I had forgotten to subscribe me to the English list and  
you Santi have subscribed me now or what have happened, anyway from  
now I will check the list manually each several days for being sure :)

Thanks for your great effort in documenting the whole project so that  
bumpkins as me be able to join to it :P I hope to start coding as soon  
as I have a bit of more leisure time, you know in this semester the  
university is killing me...

In the meanwhile I will continue helping in the wiki and learning  
about QT4 library.

Kind regards,

Rober

[Gestiong-development] Working arrangement of proyects/libraries

[Santiago C. T. <san...@ya...>]

Hi, after a few days poundering around, I have find a setup that can be 
used temporaryly for developing gestiong:

All subprojects in gestiong_common are static libraries. When released, 
they will be shared libraries.
gestiong_gui_qt4 has both the gui_impl subproyect as a static library to 
implement the gui interface and the application subproyect linked both 
with gestion_common and gui_impl and with a minimal main function to 
build the gui and, in the future, load the plugins.

The task of loading the gui as a plugin seems to be too much complex 
because of the inherent problems with dlopen.

So, the release nr. 37 is fully working in debug mode and has 
gestiong_gui_qt4/application as the main program.

-- santilin

Re: [Gestiong-development] Created gestiong-config to help building gestiong both in debug and release mode

[Santiago C. T. <san...@ya...>]

The problem with qmake:
The scope is not tested with debug {} but with CONFIG(debug).

Santiago Capel Torres escribió:
> Hi, aftear a mad morning dealing with automake/autoconf, I have been 
> able to almost prepare the environment for easily building gestiong.
>
> I have made autoconf to create a bash script, gestiong-config, (look 
> into acinclude.m4) similar to those package-config that are shipped with 
> 'good' libraries. Then, I have made gestiong_gui_qt4 use it (look into 
> gestiong-config.pri) so that it runs gestiong-config and gets the libs 
> and cflags options.
>
> There is still a problem:
>
> * I couldn't make qmake to distinguish between 'debug' and 'release' 
> modes, as it goes through both scopes:
>    debug {
>        message ( debug );
>    }
>    release {
>        message (release );
>     }
>
>
> I have also changed gestiong_common in order to buy only a shared 
> library, libgestiong.la, instead of the three it was generating before 
> (base, gui and system). Now we will only have to link agains one 
> library. I would have liked to be able to build static libraries, but I 
> couldn't, so I have uses libtool libraries. More info at: 
> http://www.gnu.org/software/automake/manual/html_node/A-Shared-Library.html
>
> Everything has been commited.
> -- santilin
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Gestiong-development mailing list
> Ges...@li...
> https://lists.sourceforge.net/lists/listinfo/gestiong-development
>
>   

[Gestiong-development] Make gestiong_gui_qt4 compile

[Santiago C. T. <san...@ya...>]

Up to this point, gestiong_common compiles and builds the gestiong 
shared library.

But gestiong_gui_qt4 does not compile because it lacks a few interface 
implementation methods.

-- santilin

[Gestiong-development] Created gestiong-config to help building gestiong both in debug and release mode

[Santiago C. T. <san...@ya...>]

Hi, aftear a mad morning dealing with automake/autoconf, I have been 
able to almost prepare the environment for easily building gestiong.

I have made autoconf to create a bash script, gestiong-config, (look 
into acinclude.m4) similar to those package-config that are shipped with 
'good' libraries. Then, I have made gestiong_gui_qt4 use it (look into 
gestiong-config.pri) so that it runs gestiong-config and gets the libs 
and cflags options.

There is still a problem:

* I couldn't make qmake to distinguish between 'debug' and 'release' 
modes, as it goes through both scopes:
   debug {
       message ( debug );
   }
   release {
       message (release );
    }


I have also changed gestiong_common in order to buy only a shared 
library, libgestiong.la, instead of the three it was generating before 
(base, gui and system). Now we will only have to link agains one 
library. I would have liked to be able to build static libraries, but I 
couldn't, so I have uses libtool libraries. More info at: 
http://www.gnu.org/software/automake/manual/html_node/A-Shared-Library.html

Everything has been commited.
-- santilin

[Gestiong-development] Wiki updates

[Santiago C. T. <san...@ya...>]

I have updated the wiki,mainly the article about arquitecture:

http://wiki.gulmu.com/index.php/Gongen:Documentation_for_developers

--santilin

[Gestiong-development] Proposed set of gestiong_gui classes

[Santiago C. T. <san...@ya...>]

Hi list,

I have committed to svn a proposed set of gui classes for the 
gestiong_gui module. The classes are:

GuiObject
    GuiWidget
        GuiMenu
        GuiMenuItem
        GuiMainWindow
        GuiStatusBar
        GuiForm
            GuiComboBox
            GuiDataTable
            GuiLabel
            GuiLayout
            GuiLineEdit
            GuiPushButton
            GuiTabWidget

The indentations does not mean exactly inheritance, but the fact that, 
for example, a GuiForm can contain GuiComboBoxes, GuiLabels, etc.

This is a simplification of the great number of classes that every 
toolkit provides, but I think is a good starting point and that they are 
enough to build basic GUI applications. Other classes that we will have 
to add later are: GuiTreeView, GuiRadioButton and GuiFrame.

Each gui implementation will have to adhere to this set of interfaces 
and, maybe, build intermediate objects behind the scenes. For example, 
not having a class for toolbars, the implementation will be able to 
create them based upon the definition of the menus. Another example is 
hiding the MDI interface: GuiMainWindow only have a createClient() and a 
deleteClient() method and the implementation will take care of 
workspaces and everything else.

To be continued...

Re: [Gestiong-development] Reorganization of the code. Next steps

[Santiago C. T. <san...@ya...>]

Hi list,

I have reorganized the whole code in what I think looks like the final 
structure.

 +gestiong-0.4
  |_________________ + gestiong-common
  |                             |________________________ gestiong_base
  |                             |________________________ gestiong_gui
  |                             |________________________ gestiong-system
  |                             |________________________ tests
  |
  |_________________ + gestiong_gui_qt4
  |                             |________________________ application
  |                             |________________________ gui_impl
  |
  |_________________     gestiong_socias
  |
  |_________________     gestiong_contable


So far, only gestiong_base, gestiong_gui and 
gestiong_gui_qt4/application compile.

gestiong_base contains the base classes for gestiong like db-access, 
regional information, os utils, dates, settings, data models, etc. It 
depends only on the standard C, C++ and Boost libraries plus mysql-dev 
libraries.

gestiong_gui contains an independent definition of the gui elements of 
gestiong. It only depends on gestion_base.

gestiong_system, which currently doesn't compile, depends on the two above.

tests is a subproyect for unit testing. It depends on all the other 
libraries.

gestiong_gui_qt4 has been created as a Qt project, so it has a different 
set of Makefiles and configuration files. It depends on Qt4 libraries 
plus the gestiong_common libraries.

gestiong_gui_qt4/gui_impl implements the abstract classes defined in 
gestiong_gui. Currently, only GuiAction has been implemented. The 
procedure is like this:

In gestiong_gui/gongguiaction.h we define a class named GuiAction. It 
has the typical members like Text, Checkable, Visible, etc. but the 
implementation will be carried out by its member void *impl.

In gestiong_gui_qt4/gui_impl/qt4_guiaction.cpp is the implementation of 
GuiAction. In the constructor, it creates a QAction object (from the Qt 
library) and assigns it to the member 'impl' in GuiAction. The rest of 
the implementation is done using this QAction object. It is still to see 
if this object must delete the QAction object or not, as Qt usually 
automatically deletes all the objects in its applications.


With this in mind, we create the gestiong main window inside the 
subproject gestiong_common/gestiong_system using only the gui classes 
defined in gestiong_common/gestiong_gui.

The main program has to link all the libraries together: both from 
gestiong_common and gestiong_gui_qt4. One thing to experiment with is 
where to place the main program:
a )inside gestiong_common
    This is discouraged as gestiong_common is only a set of libraries, 
so it shouldn't have a main program. (I have implemented this in the 
test subproject as a means to test the whole project)
b) inside gestiong_gui_qt4
    This could be ok, but this should be just a dynamically loadable 
plugin. (I have implemented this temporarily just to compile the whole 
project)
c) In another project.
    I think this is the best option. This project would have a small 
main program that would be linked against the gestiong_common library 
and then would load any of the gui implementation libraries, like 
gestiong_gui_qt4 or gestiong_gui_curses.

List of TODOs:
- Complete the implementation of 
gestiong_gui_qt4/gui_impl/qt4_guiaction.cpp (Roberto)
- Create a new project, called capel, to automatize the definition of 
the GUI classes (Santi)
- Complete the definition of gestiong_common/gestiong_gui GuiWidget, 
GuiMenuBar, GuiPushButton, GuiEditText, etc. (Santi)
- Create the main window in gestiong_common/gestiong_system (Santi & 
Roberto)
- Create a new project, called gestiong_main, which contains only a main 
function and links against all the libraries as stated above. (Roberto?)


Well, enough for now :)
-- santilin










Santiago Capel Torres escribió:
> Hi list,
>
> after reorganizing the code of gestiong, the next step is to make it 
> compile again.
>
> Inside, gestiong_common:
> - the subproject gestiong_base compiles ok as it has no other dependencies.
> - the subproject gestiong_gui has to be wholy refactored:
>      - All references to the qt library have to be moved to the 
> gestiong-gui-qt4 project
>      - Virtual classes for every GUI element have to be created. They 
> will be implemented in gestiong-gui-xxxxxx
> - the subproject gestiong-rtk has very little references to 
> gestiong-gui, but they have to be found and refactored
> - the subproject gestiong-system depends greatly on gestiong-gui, so it 
> will be the last one refactored.
>
> To start off with something, I will virtualize the LineEdit class. You, 
> Roberto, can start with the implementation of that class in 
> gestiong-gui-qt4. We can discuss the details of this here on the list.
>
> See you,
> -- santilin
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Gestiong-development mailing list
> Ges...@li...
> https://lists.sourceforge.net/lists/listinfo/gestiong-development
>
>   

[Gestiong-development] Initial import of gestiong/trunk

[Santiago C. T. <san...@ya...>]

Hi list,

I have just imported the source tree of gestiong into the 'trunk' branch 
of svn at sourceforge.

The command was:

svn import gestiong-0.4 
https://gestiong.svn.sourceforge.net/svnroot/gestiong/trunk -m "Initial 
import of gestiong-0.4"

As recommended on the svn-book, 
http://svnbook.red-bean.com/en/1.1/index.html, I have placed the code 
under the trunk directory, so, to make the initial checkout, you have to do:

svn co https://gestiong.svn.sourceforge.net/svnroot/gestiong/trunk gestiong

The last 'gestiong' meaning that the code be created on your filesystem 
under the directory 'gestiong' instead of 'trunk'

The documentation of the layout of the new code for gestiong-0.4 can be 
found in the wiki at:


http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG

(it is in Spanish, though).

We have to research how to maintaing the spanish and english version of 
the wiki. We can create subpages of any page for the translations, like 
this:

http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG/en
http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG/fr
http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG/ca

but the problem is that the title of the page is still in Spanish. I 
think we can do #redirect to the english one, can not we?

See you,
-- santilin

[Gestiong-development] Initial import of gestiong/trunk

[Santiago C. T. <san...@ya...>]

(I am resending this message for it seems not to have arrived to the 
list on the first time)

Hi list,

I have just imported the source tree of gestiong into the 'trunk' branch
of svn at sourceforge.

The command was:

svn import gestiong-0.4
https://gestiong.svn.sourceforge.net/svnroot/gestiong/trunk -m "Initial
import of gestiong-0.4"

As recommended on the svn-book,
http://svnbook.red-bean.com/en/1.1/index.html, I have placed the code
under the trunk directory, so, to make the initial checkout, you have to do:

svn co https://gestiong.svn.sourceforge.net/svnroot/gestiong/trunk gestiong

The last 'gestiong' meaning that the code be created on your filesystem
under the directory 'gestiong' instead of 'trunk'

The documentation of the layout of the new code for gestiong-0.4 can be
found in the wiki at:


http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG

(it is in Spanish, though).

We have to research how to maintaing the spanish and english version of
the wiki. We can create subpages of any page for the translations, like
this:

http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG/en
http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG/fr
http://wiki.gulmu.com/index.php/Arquitectura_de_GestiONG/ca

but the problem is that the title of the page is still in Spanish. I
think we can do #redirect to the english one, can not we?

See you,
-- santilin

[Gestiong-development] Reorganization of the code. Next steps

[Santiago C. T. <san...@ya...>]

Hi list,

after reorganizing the code of gestiong, the next step is to make it 
compile again.

Inside, gestiong_common:
- the subproject gestiong_base compiles ok as it has no other dependencies.
- the subproject gestiong_gui has to be wholy refactored:
     - All references to the qt library have to be moved to the 
gestiong-gui-qt4 project
     - Virtual classes for every GUI element have to be created. They 
will be implemented in gestiong-gui-xxxxxx
- the subproject gestiong-rtk has very little references to 
gestiong-gui, but they have to be found and refactored
- the subproject gestiong-system depends greatly on gestiong-gui, so it 
will be the last one refactored.

To start off with something, I will virtualize the LineEdit class. You, 
Roberto, can start with the implementation of that class in 
gestiong-gui-qt4. We can discuss the details of this here on the list.

See you,
-- santilin