Le 30 oct. 06 à 18:37, Yen-Ju Chen a écrit :
On 10/30/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 30 oct. 06 à 07:52, Yen-Ju Chen a écrit :
> I am thinking to change PreferencesKit into library.
> The only reason PreferencesKti need to be a framework is because of
> a gorm file,
> which we can rewritten in codes.
> And frankly, GNUstep-make does not handle framework very well on
> GNUstep,
> which I think is a problem of GCC.
> I will need it for Grr and it may be a good time to revisit it
again.
> Any comment ?
Are any special problems triggered by the fact PreferencesKit is a
framework? If so, well we can add the option to compile it as the
library with the missing code and make it the default. Otherwise I
think it's better to keep as a framework.
I also think it's possible to have Resources installed with a library
but I don't know how to do it with gnustep-make. gnustep-gui uses
this feature though.
And what is the advantage of framework ?
Conceptually nicer ;-)
I haven't see that we need to supply resources for it.
Well, it's sometimes really useful to be able to provide resources.
It can be a real pain when everything must done in code. For example,
building a usable table view programmatically is a wizard secret that
nobody knows except Gorm.
In Preferences/PaneKit case, there is a tableview-based presentation,
that's why I created a gorm file. If you are able to write the proper
code which allows to create a tableview, well we could get rid of the
Gorm file. By the way, if you succeed it would be cool to add this
code in an NSTableView category that lets create a Gorm-like
tableview embedded within a scrollview or not. Then this category
could be put in EtoileUI framework.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
