Re: unixODBC-GUI-Qt: Builds
Peter Harvey <[email protected]>
| Newsgroups | gmane.comp.db.unixodbc.devel |
|---|---|
| Message-ID | <[email protected]> |
>> > Well, its configured and seems to be building fine at this moment, > good work. What do you want to do with odbctest? Its a bit of a half > way house, can't help thinking it should go with the Gui parts as it > is one, What do you think? If that (and the associated test lib and > sample that goes with it) was removed, then all the GUI parts could be > removed (I think). > > We also need to work on the web site, so there is a place for both > projects, and people can find how to get the bits they need. Also the > drivers need splitting out as well, so the folk who needs the txt > driver can get their builds working again. > > BTW, if anyone else reading this has any views on this division, let > me know, as I don't want to do stuff thats going to break others work. > re. odbctest I think odbctest should be with unixODBC-GUI-Qt. I can get it in there if you like? re. gtk The only other GUI bits would be gODBCConfig (I think). My thinking is that a unixODBC-GUI-Gtk project would handle that. I have no plans to do that work but I could, if need be, init the project so it can be removed from the unixODBC-core. re. web site I was going to put some web material for unixODBC-GUI-Qt on the sourceforge space but it probably makes more sense to just link people over to a revised unixodbc.org. I think this is what you are suggesting and if so - do you have a resource for this? I could do it in a pinch - just not really my thing. re. txt driver I have plans to do *something* with the text file stuff - including the txt driver. I need to see about getting it into a sourceforge project itself and then see how much time I have for it. At a min I want to see that stuff, in its current state, available and usable to people. re. driver setups My understanding is that you will remove all drivers from unixODBC-core? What about the DRVConfig stuff? I do not see an obvious vehicle for delivering DRVConfig to people - other than unixODBC-core. Perhaps rethink how GUI abstracted (if any) driver setups should be done? re. test framework & tests Should these be their own project? Perhaps look at that at a later date? -- Peter _______________________________________________ unixODBC-dev mailing list [email protected] http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev