Cool. I stand corrected. It's been the collective experience of our
initial team (a mixture of bad nightmares) that that wasn't the case.
I never said it wasn't possible, just we hadn't seen it (yet). Can you
name any (GPL or LGPL or commercial) names that we might
investigate further or that you would recommend to a friend (or
recommend to avoid) ?
> For example, in a former life, I used to maintain one of the
> frameworks used by Adobe Systems for their software. As such, I was
> one of the only people on the team (and we're talking multiple teams
> of 10+ people per team) who ever touched platform-centric code. All
> of the platform-centricity, from file I/O and memory management all
> the way up to windows, dialogs & widgets had been abstracted out.
> And if you look at any Adobe product, it looks and feels like a
> native application, because it is!
Cool. Is this a proprietary (in-house developed) package of Adobe
or was there a third-party supplier?
> >My goals in building abi framework, were [1], [4], [3], and [2], and in that
> >order. That is, we were able to minimize platform code as a side-effect of
> >[3] and [4], but not eliminate it.
>
> IMO, the problem with the current abisource framework is that
> it doesn't go far enough in the XP abstraction, in terms of the
> GUI-related issues. You now have enough experience and example
> dialogs & widgets to sit down and design higher level "wrapper"
> classes for all this stuff. Do it NOW before you get further and
> further down the platform-centric path...
yes, we do. And part of me wants to "take a year off" and do that. there
are parts that i'm proud of and parts that, well, are just there taking up
space. But I think the right thing to do is to continue on as we are and
finish 1.0 with a respectable feature set. THEN as it gains critical
acceptance in the user community, we can pause and DECIDE how to proceed.
It might be the wrong thing to do from an engineering point of view, but
it's the right thing to do from a product point of view.
when we get past 1.0, there are several parts that i want to spend some time
staring at and possibly redoing/refactoring. this is most definitely one of
them. but at this point in time, i think our time is better spent looking at
bullet lists, page numbers, and (gulp) tables.
> >Part of this is an artifact of the naming scheme we chose for the class
> >hierarchies. We put the platform name in the class -- this gives us unique
> >function names in LXR and makes it easy to see the line between platform
> >and XP code, but does force an explicit branch to platform code. For example,
> >we have an abstract GR_Graphics class, from which the GR_Win32Graphics and
> >GR_UnixGraphics classes are derrived. All the methods are virtual, but
> >because of the naming, platform code has to call the constructor even though
> >all the drawing happens in XP code using the base class definition and the
> >virtual methods.
>
> The way to solve this is to use a higher level object
> (GR_Graphics) which knows which platforms it's been compiled for and
> "shims" to the appropriate platform-centric class. Using inlines
> for many/most of the methods will also help avoid speed issues with
> the extra level of indirection.
yes, that would work too.
> >Often you'll see nearly identical blocks of platform code,
> >with platform class names being the only difference.
>
> And that's just (IMO) silly! It's easy to fix - so do it!
yes, i've been wanting to do this, but haven't found the time. Now that I
think about it I do think this would make a nice weekend hack for someone and a
good introduction to the code. If anyone is interested....
jeff