unixodbc gui split

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

unixodbc gui split

Igor Korot
Hi, Nick,
Sorry to write on the private email. I just don't know which unixODBC
mailing list is still good...

Have a quick question: what was the reasoning behind the GUI part split?
I am running Gentoo and trying to compile the unixODBC GUI part it
gives an error.

It is very helpful to have the GUI part put back and ship it as one project.

Thank you.
_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Reply | Threaded
Open this post in threaded view
|

Re: unixodbc gui split

Cowbert
This is the UNIX principle of KISS (keep it simple stupid). In a
server environment, having the GUI part is neither necessary nor
desirable. Core codebase provides the core functionality. As long as
the API is documented and the hooks are present/maintained, the GUI
code should be kept separate. This helps with development process
workflow: why result in extra version bumps of UnixODBC every time
some code in the GUI got changed? Why reduce portability/stability
just to keep add-on code? I suppose an argument could be made to use
Make flags to tell it whether to build the GUI or not.

On Fri, Jan 15, 2016 at 9:35 PM, Igor Korot <[hidden email]> wrote:

> Hi, Nick,
> Sorry to write on the private email. I just don't know which unixODBC
> mailing list is still good...
>
> Have a quick question: what was the reasoning behind the GUI part split?
> I am running Gentoo and trying to compile the unixODBC GUI part it
> gives an error.
>
> It is very helpful to have the GUI part put back and ship it as one project.
>
> Thank you.
> _______________________________________________
> unixODBC-dev mailing list
> [hidden email]
> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Reply | Threaded
Open this post in threaded view
|

Re: unixodbc gui split

Igor Korot
Hi, Peter,

On Fri, Jan 15, 2016 at 10:32 PM, Peter Lai <[hidden email]> wrote:
> This is the UNIX principle of KISS (keep it simple stupid). In a
> server environment, having the GUI part is neither necessary nor
> desirable. Core codebase provides the core functionality. As long as
> the API is documented and the hooks are present/maintained, the GUI
> code should be kept separate. This helps with development process
> workflow: why result in extra version bumps of UnixODBC every time
> some code in the GUI got changed? Why reduce portability/stability
> just to keep add-on code? I suppose an argument could be made to use
> Make flags to tell it whether to build the GUI or not.

I believe you are wrong.
unixODBC is a software for a client to make a client connect to DB server.

Now as I said I am getting the error trying to compile the package:

x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed -shared -o
libodbcinstQ4.so .tmp/CAbout.o .tmp/CAdvanced.o
.tmp/CDataSourceNameList.o .tmp/CDataSourceNames.o
.tmp/CDataSourceNamesFile.o .tmp/CDataSourceNamesFileModel.o
.tmp/CDriverConnectPrompt.o .tmp/CDriverList.o .tmp/CDriverPrompt.o
.tmp/CDSNWizardProperties.o .tmp/CDSNWizardDriver.o
.tmp/CDSNWizardEntre.o .tmp/CDSNWizardFini.o .tmp/CDSNWizard.o
.tmp/CDSNWizardType.o .tmp/CFileSelector.o .tmp/CHelp.o
.tmp/CManageDataSourceNames.o .tmp/CManageDrivers.o .tmp/CODBCConfig.o
.tmp/CODBCInst.o .tmp/CPage.o .tmp/CPooling.o
.tmp/CPropertiesDelegate.o .tmp/CPropertiesDialog.o
.tmp/CPropertiesModel.o .tmp/CMonitorHandleCounts.o .tmp/CMonitor.o
.tmp/CMonitorProcesses.o .tmp/CThreading.o .tmp/CTracing.o
.tmp/ODBCDriverConnectPrompt.o .tmp/SQLManageDataSources.o
.tmp/moc_CAbout.o .tmp/moc_CAdvanced.o .tmp/moc_CDataSourceNameList.o
.tmp/moc_CDataSourceNames.o .tmp/moc_CDataSourceNamesFile.o
.tmp/moc_CDataSourceNamesFileModel.o .tmp/moc_CDriverConnectPrompt.o
.tmp/moc_CDriverList.o .tmp/moc_CDriverPrompt.o
.tmp/moc_CDSNWizardProperties.o .tmp/moc_CDSNWizardDriver.o
.tmp/moc_CDSNWizardEntre.o .tmp/moc_CDSNWizardFini.o
.tmp/moc_CDSNWizard.o .tmp/moc_CDSNWizardType.o
.tmp/moc_CFileSelector.o .tmp/moc_CHelp.o
.tmp/moc_CManageDataSourceNames.o .tmp/moc_CManageDrivers.o
.tmp/moc_CMonitor.o .tmp/moc_CMonitorHandleCounts.o
.tmp/moc_CMonitorProcesses.o .tmp/moc_CODBCConfig.o
.tmp/moc_CPooling.o .tmp/moc_CPropertiesDelegate.o
.tmp/moc_CPropertiesDialog.o .tmp/moc_CThreading.o .tmp/moc_CTracing.o
  -L/usr/lib64/qt4 -L -lodbc -lodbcinst -L../lib -lini -lQtGui
-L/usr/lib64/qt4 -lQtCore -lpthread
mv -f libodbcinstQ4.so ../lib/
make[1]: Leaving directory
'/var/tmp/portage/dev-db/unixODBC-GUI-QT-9999/work/unixODBC-GUI-QT-9999/odbcinstQ4'
 * ERROR: dev-db/unixODBC-GUI-QT-9999::rainyday failed (compile phase):
 *   emake failed
 *
 * If you need support, post the output of `emerge --info
'=dev-db/unixODBC-GUI-QT-9999::rainyday'`,
 * the complete build log and the output of `emerge -pqv
'=dev-db/unixODBC-GUI-QT-9999::rainyday'`.
 * The complete build log is located at
'/var/tmp/portage/dev-db/unixODBC-GUI-QT-9999/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/dev-db/unixODBC-GUI-QT-9999/temp/environment'.
 * Working directory:
'/var/tmp/portage/dev-db/unixODBC-GUI-QT-9999/work/unixODBC-GUI-QT-9999'
 * S: '/var/tmp/portage/dev-db/unixODBC-GUI-QT-9999/work/unixODBC-GUI-QT-9999'


I wonder: the split happened in 2.3.0. Right now the last stable
release is 2.3.2 (I think).
Does anybody tried to compile the package with latest or not so latest
qt/unixODBC?
Which brings even broader question: whether it is maintained at all?

Thank you.

>
> On Fri, Jan 15, 2016 at 9:35 PM, Igor Korot <[hidden email]> wrote:
>> Hi, Nick,
>> Sorry to write on the private email. I just don't know which unixODBC
>> mailing list is still good...
>>
>> Have a quick question: what was the reasoning behind the GUI part split?
>> I am running Gentoo and trying to compile the unixODBC GUI part it
>> gives an error.
>>
>> It is very helpful to have the GUI part put back and ship it as one project.
>>
>> Thank you.
>> _______________________________________________
>> unixODBC-dev mailing list
>> [hidden email]
>> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
> _______________________________________________
> unixODBC-dev mailing list
> [hidden email]
> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Reply | Threaded
Open this post in threaded view
|

Re: unixodbc gui split

Nick Gorham-2
In reply to this post by Cowbert
On 16/01/16 03:32, Peter Lai wrote:
> This is the UNIX principle of KISS (keep it simple stupid). In a
> server environment, having the GUI part is neither necessary nor
> desirable. Core codebase provides the core functionality. As long as
> the API is documented and the hooks are present/maintained, the GUI
> code should be kept separate. This helps with development process
> workflow: why result in extra version bumps of UnixODBC every time
> some code in the GUI got changed? Why reduce portability/stability
> just to keep add-on code? I suppose an argument could be made to use
> Make flags to tell it whether to build the GUI or not.

Yep, Peter Lai has it how I see it. The GUI part is not linked to the
core libs, it can live on its own, and as my interest is not GUI, and
Peter at the time wanted to work on it, splitting seemed the sensible
thing to do, and still does IMHO.

Also, the GUI while being far less use, created more support requests
that I had time to worry about, especially in every case, the users
actual problem cound be solved without the GUI.

And then the GUI makes less sense if the driver writers don't make a
setup lib, but doing that becomes a pain for them, as it is either
written using X intrinsics, or whatever is the GUI of choice this week,
or some graphics lib, that will just introduce extra dependencies and
work needed just to keep it working.

My take on open source is that the work is best done by someone who has
a requirement for the result, no one has come forward to do that with
the GUI, so it is what it is.
>
> On Fri, Jan 15, 2016 at 9:35 PM, Igor Korot <[hidden email]> wrote:
>> Hi, Nick,
>> Sorry to write on the private email. I just don't know which unixODBC
>> mailing list is still good...

AFAIK, they all should be, I do have to sleep now and then though.
>>
>> Have a quick question: what was the reasoning behind the GUI part split?
>> I am running Gentoo and trying to compile the unixODBC GUI part it
>> gives an error.

See above.
>>
>> It is very helpful to have the GUI part put back and ship it as one project.

Not so much IMHO, if you want to make it work for your platform, help
yourself.

--
Nick
_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Reply | Threaded
Open this post in threaded view
|

Re: unixodbc gui split

Nick Gorham-2
In reply to this post by Igor Korot
On 16/01/16 05:04, Igor Korot wrote:

> Hi, Peter,
>
> On Fri, Jan 15, 2016 at 10:32 PM, Peter Lai <[hidden email]> wrote:
>> This is the UNIX principle of KISS (keep it simple stupid). In a
>> server environment, having the GUI part is neither necessary nor
>> desirable. Core codebase provides the core functionality. As long as
>> the API is documented and the hooks are present/maintained, the GUI
>> code should be kept separate. This helps with development process
>> workflow: why result in extra version bumps of UnixODBC every time
>> some code in the GUI got changed? Why reduce portability/stability
>> just to keep add-on code? I suppose an argument could be made to use
>> Make flags to tell it whether to build the GUI or not.
> I believe you are wrong.

Belief will always be personal, though not always correct.
> unixODBC is a software for a client to make a client connect to DB server.
>
> Now as I said I am getting the error trying to compile the package:

Well, if you find the fix, by all means make it available.

--
Nick
_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
Reply | Threaded
Open this post in threaded view
|

Re: unixodbc gui split

Igor Korot
Nick,

On Sat, Jan 16, 2016 at 5:30 AM, Nick Gorham <[hidden email]> wrote:

> On 16/01/16 05:04, Igor Korot wrote:
>>
>> Hi, Peter,
>>
>> On Fri, Jan 15, 2016 at 10:32 PM, Peter Lai <[hidden email]> wrote:
>>>
>>> This is the UNIX principle of KISS (keep it simple stupid). In a
>>> server environment, having the GUI part is neither necessary nor
>>> desirable. Core codebase provides the core functionality. As long as
>>> the API is documented and the hooks are present/maintained, the GUI
>>> code should be kept separate. This helps with development process
>>> workflow: why result in extra version bumps of UnixODBC every time
>>> some code in the GUI got changed? Why reduce portability/stability
>>> just to keep add-on code? I suppose an argument could be made to use
>>> Make flags to tell it whether to build the GUI or not.
>>
>> I believe you are wrong.
>
>
> Belief will always be personal, though not always correct.

Can't agree more. But not in this case.
unixODBC is a client-oriented software designed to make it easier for a client
to connect to a database thru the familiar interface. And this is
contradicting on what
Peter is saying.
I just wonder how unixODBC become a server-side software?

>>
>> unixODBC is a software for a client to make a client connect to DB server.
>>
>> Now as I said I am getting the error trying to compile the package:
>
>
> Well, if you find the fix, by all means make it available.

Is GUI part is building with every unixODBC release?

Another question: does it depend solely on unixODBC? And what version
of qt it can be built against?

Thank you.

>
>
> --
> Nick
> _______________________________________________
> unixODBC-dev mailing list
> [hidden email]
> http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev
_______________________________________________
unixODBC-dev mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev