By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,159 Members | 946 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,159 IT Pros & Developers. It's quick & easy.

Design question for UI library

P: n/a
Hi everyone,

I am writing a small user interface library in C++ (I know it has been
done to death, but it is good for learning ).

Anyways, I need some help/advice with the deisgn of the software
architecture. The problem I am facing is that a control can have so
many states... For example, a button could be have various shapes
(rounded, square, some other custom geometry). Also, it could be
bitmapped, textured, text only, text with bitmap etc. So, you get the
picture. Having a specialized Button class for each of these would be
very difficult to maintain.

So, my question to you gurus is how would you organize a widget library
like that. What design patterns would you recommend that I look into?
Any advice would be appreciated.

Thanks and cheers!

xargy

Dec 9 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
On 9 Dec 2005 13:20:04 -0800, "xargon" <pa********@excite.com> wrote:
Hi everyone,

I am writing a small user interface library in C++ (I know it has been
done to death, but it is good for learning ).

Anyways, I need some help/advice with the deisgn of the software
architecture. The problem I am facing is that a control can have so
many states... For example, a button could be have various shapes
(rounded, square, some other custom geometry). Also, it could be
bitmapped, textured, text only, text with bitmap etc. So, you get the
picture. Having a specialized Button class for each of these would be
very difficult to maintain.

So, my question to you gurus is how would you organize a widget library
like that. What design patterns would you recommend that I look into?
Any advice would be appreciated.

Thanks and cheers!

xargy


Don't make separate classes buttons with different properties. Use
different classes for different /things/. If you want to be able to
choose between a rounded button and a square button for example,
expose this choice as a property in the class interface.
Dec 9 '05 #2

P: n/a
xargon wrote:
Hi everyone,

I am writing a small user interface library in C++ (I know it has been
done to death, but it is good for learning ).

Anyways, I need some help/advice with the deisgn of the software
architecture. The problem I am facing is that a control can have so
many states... For example, a button could be have various shapes
(rounded, square, some other custom geometry). Also, it could be
bitmapped, textured, text only, text with bitmap etc. So, you get the
picture. Having a specialized Button class for each of these would be
very difficult to maintain.

So, my question to you gurus is how would you organize a widget library
like that. What design patterns would you recommend that I look into?
Any advice would be appreciated.

Thanks and cheers!

xargy


This post is off-topic here, as it does not concern the C++ *language*
proper (see the FAQ:
http://www.parashift.com/c++-faq-lit....html#faq-5.9). Try in
comp.software.patterns or comp.object.

Cheers! --M

Dec 9 '05 #3

P: n/a

W Marsh wrote:
On 9 Dec 2005 13:20:04 -0800, "xargon" <pa********@excite.com> wrote:
Hi everyone,

I am writing a small user interface library in C++ (I know it has been
done to death, but it is good for learning ).

Anyways, I need some help/advice with the deisgn of the software
architecture. The problem I am facing is that a control can have so
many states... For example, a button could be have various shapes
(rounded, square, some other custom geometry). Also, it could be
bitmapped, textured, text only, text with bitmap etc. So, you get the
picture. Having a specialized Button class for each of these would be
very difficult to maintain.

So, my question to you gurus is how would you organize a widget library
like that. What design patterns would you recommend that I look into?
Any advice would be appreciated.

Thanks and cheers!

xargy


Don't make separate classes buttons with different properties. Use
different classes for different /things/. If you want to be able to
choose between a rounded button and a square button for example,
expose this choice as a property in the class interface.


OT: That's just one way to do it, but it's really not the design
patterns or OO way.

Cheers! --M

Dec 9 '05 #4

P: n/a
On 9 Dec 2005 13:50:41 -0800, "mlimber" <ml*****@gmail.com> wrote:

W Marsh wrote:
On 9 Dec 2005 13:20:04 -0800, "xargon" <pa********@excite.com> wrote:
>Hi everyone,
>
>I am writing a small user interface library in C++ (I know it has been
>done to death, but it is good for learning ).
>
>Anyways, I need some help/advice with the deisgn of the software
>architecture. The problem I am facing is that a control can have so
>many states... For example, a button could be have various shapes
>(rounded, square, some other custom geometry). Also, it could be
>bitmapped, textured, text only, text with bitmap etc. So, you get the
>picture. Having a specialized Button class for each of these would be
>very difficult to maintain.
>
>So, my question to you gurus is how would you organize a widget library
>like that. What design patterns would you recommend that I look into?
>Any advice would be appreciated.
>
>Thanks and cheers!
>
>xargy


Don't make separate classes buttons with different properties. Use
different classes for different /things/. If you want to be able to
choose between a rounded button and a square button for example,
expose this choice as a property in the class interface.


OT: That's just one way to do it, but it's really not the design
patterns or OO way.

Cheers! --M


Hm? Why not? Would you create a new class because you wanted a red
button also?
Dec 9 '05 #5

P: n/a
W Marsh wrote:
Hm? Why not? Would you create a new class because you wanted a red
button also?


Depends. If you had a different button shape, then the button function
CalculateArea might use a different function. All depends on what
functions you have on the button class and what you need to change.

Dec 9 '05 #6

P: n/a
On 9 Dec 2005 14:32:32 -0800, "Josh Mcfarlane" <da*****@gmail.com>
wrote:
W Marsh wrote:
Hm? Why not? Would you create a new class because you wanted a red
button also?


Depends. If you had a different button shape, then the button function
CalculateArea might use a different function. All depends on what
functions you have on the button class and what you need to change.


Ah, right, yes. The way I phrased it made it sound like it was THE
solution for the problem, which is obviously foolishness. I meant that
it sounds like the best way to do it in the circumstance.
Dec 9 '05 #7

P: n/a

W Marsh wrote:
On 9 Dec 2005 14:32:32 -0800, "Josh Mcfarlane" <da*****@gmail.com>
wrote:
Ah, right, yes. The way I phrased it made it sound like it was THE
solution for the problem, which is obviously foolishness. I meant that
it sounds like the best way to do it in the circumstance.


Well, in his specific example, how would you differentiate drawing the
circle button from the bitmap button?

Dec 9 '05 #8

P: n/a
Well, I feel guilty about posting this in the wrong forum... but both
these solutions are kinda complicated. One would have a lot of
functions in same class... other might result in an unmanagable number
of classes..

Dec 9 '05 #9

P: n/a
On 9 Dec 2005 14:56:59 -0800, "Josh Mcfarlane" <da*****@gmail.com>
wrote:

W Marsh wrote:
On 9 Dec 2005 14:32:32 -0800, "Josh Mcfarlane" <da*****@gmail.com>
wrote:
Ah, right, yes. The way I phrased it made it sound like it was THE
solution for the problem, which is obviously foolishness. I meant that
it sounds like the best way to do it in the circumstance.


Well, in his specific example, how would you differentiate drawing the
circle button from the bitmap button?


I didn't take what he said to mean a circle button - I thought he
simply meant rounded edges, a minor aesthetic difference.
Dec 9 '05 #10

P: n/a
On 9 Dec 2005 14:56:59 -0800, "Josh Mcfarlane" <da*****@gmail.com>
wrote:

W Marsh wrote:
On 9 Dec 2005 14:32:32 -0800, "Josh Mcfarlane" <da*****@gmail.com>
wrote:
Ah, right, yes. The way I phrased it made it sound like it was THE
solution for the problem, which is obviously foolishness. I meant that
it sounds like the best way to do it in the circumstance.


Well, in his specific example, how would you differentiate drawing the
circle button from the bitmap button?


The one GUI library I saw generalized control shapes with a separate
class, and used composition to assign the appropriate shape to the
control.

It seemed to work well enough, but it didn't feel like the ideal
solution at all.
Dec 10 '05 #11

P: n/a
> This post is off-topic here, as it does not concern the C++ *language*

This of course IS the concern of the C++ **Language**. The **Language**
IS designed to deal with these problems where you need **Language**
level support in addition to library level support.

Ben
Dec 10 '05 #12

P: n/a
Josh Mcfarlane wrote:
W Marsh wrote:
Hm? Why not? Would you create a new class because you wanted a red
button also?


Depends. If you had a different button shape, then the button function
CalculateArea might use a different function. All depends on what
functions you have on the button class and what you need to change.


Right. See WTL (http://sourceforge.net/projects/wtl) which provides
separated classes for button and bitmap button. I think such variations
should be expressed as differennt classes.

First, I thought a kind of traits or policies could be fine but I'm not
an expert of traits so I can not say much :-)

Cheers
--
Mateusz Loskot
http://mateusz.loskot.net

Dec 10 '05 #13

P: n/a
* xargon:
Hi everyone,

I am writing a small user interface library in C++ (I know it has been
done to death, but it is good for learning ).

Anyways, I need some help/advice with the deisgn of the software
architecture.
Make sure that C++ object creation is identical to control/widget/window
creation.

No "init" or "create" functions available to client code.

I.e., let constructors construct, and destructors destruct (not doing
this is the most common & fundamental architectural flaw in GUI libs).

The problem I am facing is that a control can have so
many states... For example, a button could be have various shapes
(rounded, square, some other custom geometry). Also, it could be
bitmapped, textured, text only, text with bitmap etc. So, you get the
picture. Having a specialized Button class for each of these would be
very difficult to maintain.


Some of the problem here is that you're looking at concrete effects
rather than general means to implement such effects. E.g., you complain
that a button can contain anything, and supporting every different thing
it can contain is impractical. Yes, it is, and therefore you should
support the general functionality of containment, and perhaps some very
common cases, not each and every thing client code might want to use.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 10 '05 #14

P: n/a
On 9 Dec 2005 17:19:23 -0800, "Mateusz Loskot" <ma*****@loskot.net>
wrote:
Josh Mcfarlane wrote:
W Marsh wrote:
> Hm? Why not? Would you create a new class because you wanted a red
> button also?


Depends. If you had a different button shape, then the button function
CalculateArea might use a different function. All depends on what
functions you have on the button class and what you need to change.


Right. See WTL (http://sourceforge.net/projects/wtl) which provides
separated classes for button and bitmap button. I think such variations
should be expressed as differennt classes.


I agree there. But rounded edges is, in my opinion, a property of a
type of button, not a new type of button itself.

An actual round button, or a bitmap button, should probably be a new
type.

Some code libraries, such as the .NET platform don't seem to agree. A
button is made into a bitmap button by setting a property of the
object - this sort of thing occurs throughout the different controls.
I wonder what the code looks like beyond the interface.
Dec 10 '05 #15

P: n/a
xargon wrote:
Hi everyone,

I am writing a small user interface library in C++ (I know it has been
done to death, but it is good for learning ).

Anyways, I need some help/advice with the deisgn of the software
architecture. The problem I am facing is that a control can have so
many states... For example, a button could be have various shapes
(rounded, square, some other custom geometry). Also, it could be
bitmapped, textured, text only, text with bitmap etc. So, you get the
picture. Having a specialized Button class for each of these would be
very difficult to maintain.

So, my question to you gurus is how would you organize a widget library
like that. What design patterns would you recommend that I look into?
Any advice would be appreciated.

Thanks and cheers!

xargy


Don't lump everything into a single class. You do want a number of
simpler classes than the a single monolith. And a class must be able to
do no more than what it should do.

Breaking down to the very bottom line, a button serves three needs:

1. to be contained in some UI framework;
2. to trap user action especially the clicking;
3. to let some external routine to handle the user action.

Anything else is desirable but not at all essential. So my personal
suggestion is for you to provide a simple class to encapsulate the above
three and give a way for the user to extend it.

For example, letting the user provide a drawing routine (by overriding a
virtual function, by assigning a function pointer, or by a policy class)
can pretty much do away all those shape and color properties. Whichever
way you do it is up to you.

That done, you can build up more interesting buttons upon the existing.
If you are doing OOP, then provide some derived button classes
(Round_button, Transparent_button, Scary_button, etc); If you prove the
basic button as a template, provide default policy class and additional
policy classes, for example:

template <typename DrawingPolicy = Default_drawing_policy>
class basic_button;

class Defaut_drawing_policy;
class Round_button_drawer;
class Scary_button_drawer;
class Transparent_button_drawer;

Ben
Dec 10 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.