[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: namazTime 0.9
- To: Development Discussions <developer at arabeyes dot org>
- Subject: Re: namazTime 0.9
- From: ahmed <ahmed at piousity dot net>
- Date: Mon, 26 Jun 2006 00:34:55 -0400
On Sun, 2006-06-25 at 22:40 +0300, Mohammed Sameer wrote:
> I don't think you should give it to me or you will wake up one day to find out that I've
> rewrote the whole thing. Which is something you won't like. I'm serious.
okay -- but speaking of which, if you look at it, the whole code (well,
the parts that are not glade-generated anyways, total up to 411 lines...
which means if it'll make life easier to design it properly and rewrite
it (rather than hack it together like i did) - that its not a bad time
to do it... i am willing to do this, but i have to sit down and think
about a good design... right now (as you can tell) there's very little
distinction between module/view/control... its just one big pot of
"koshari" at the moment.
do you have any ideas or suggestions with this regard at the moment?
> The 2nd point is that I can't guarantee my time.
lol, i can't either -- its just "hobby hacking" for me (and plus,
utility driven hacking sometimes as well i guess).
> I don't think that XML is the best thing.
> IMHO, We can have a file that lists all the available profiles. And one plain file per
> each profile.
that would work -- i suggested xml because its more structured, but i
think a big concern with using full xml stuff is being forced to bring
in a heavy dependency (like expat) to parse it and such and its too much
of an overhead for something on this scale... so either as you said a
file per profile or maybe just add some more structure to the current
file format.
>
> IMHO, I'd represent The whole thing like this:
> PS. That's a basic prototype.
>
> class Config {
> public:
> void list_profiles(std::vector<std::string>& profiles);
> Profile& get_profile(int);
> };
>
> // Profile is an object with methods to get/set all the available parameters.
> // I'd load all the profiles in the Config constructor and get_profile() loads the actual
> profile from the disk.
sounds good... that and add/delete profile methods.
>
> That's the basic idea. Of course we needn't implement it in an OO style. It's just easier
> for me to express it that way!
>
> Ideally, I'd treat each profile as an object and have a "viewer" object that is
> responsible for "rendering" the prayer profile on the screen.
yeah that sounds good...
jazakAllah khair,
wsalams,
-ahmed