making 1 user interface to handle multiple products (advice needed)

[technoViking]

hi guys,

So we have been developing software for an embedded device for about 8 months with qt and were making pretty good progress but suddenly requirements have changed and its making me re-think the entire project.

Basically now we need 1 user interface to handle multiple different products. Qt is almost looking like a bad choice, it seems more like a web based interface would work better.

Have any of you run into this issue before and how did you go about solving it (with or without qt)?

[tbscope]

... but suddenly requirements have changed ...

There's your problem. If it was my project, this would not happen. It's either the original request or nothing at all.
You can't change every month, you'll get nowhere. Ask your clients to sign a project description report.

That said, what are the products you're talking about. What are the differences on the screen. What do you need to show?
There are at least two extremely powerfull techniques in Qt and that is Item Views and GraphicsView. I can't imagine that you're in a situation that can't be solved by either techniques.

[squidge]

Have any of you run into this issue before and how did you go about solving it (with or without qt)?

That depends on a few things. What the requirements were before, what they are now, when the deadline is, what equipment is available, etc, etc.

[technoViking]

Thanks for the replys.

Well sadly I work for a large company and we have no say in CIA's. They happen all the time and the deadline gets cut after they add more features (it makes no sense). The manager says its okay and the programmers suffer.

We acquired a company and we want to use their products as well as our products but to the customer they will see the same UI for both our product or the product we just bought the only different will be the backend device (which does similar things as our products.)

Think of the UI as being a control device. I can't go into detail but pretend it can turn lights on and off, make calls, schedule meetings, etc.

We are currently using graphics view and we are also using model's for all our custom widgets.

The deadline is in 1-2 months. But considering they just changed the requirements again and fired some qt contractors I'm assuming they will extend the deadline.

The main difference between the 2 products is the feature set and how they communicate. Ours can do a lot more than theirs can and theirs uses a totally different API and communication protocol than we use. We use xmlrpc they use REST I believe. They already have a UI that uses java as the front end to control their device.

I'm not a qt expert (we hired qt contractors to help us get started and we kept 2 of them). I did learn a lot though and am doing a fair amount of the front end as well as back end development.

[SixDegrees]

It's really impossilble to say how to approach this problem without more details. In general, though, a workable approach is to define the common user interface, implement your backend as a plugin, then provide intermediate "translator" classes that mediate between the backend and the GUI, performing whatever transformations of data are required.

The key to all this is defining an API for the GUI and the intermediaries that will accomodate foreseeable changes, and is flexible enough to accomodate a wide variety of backend APIs through the translators.

[technoViking]

I like that idea of having translator classes hm...it doesn't sound that complex when you put it that way

thanks!