From: Henrik Kinnunen <fluxgen@us...> - 2002-03-17 12:03:03
I have drawn a UML chart of what Fluxbox should look like in the
(Use Dia http://www.lysator.liu.se/~alla/dia/ to open .dia file)
The chart is not 100% done thought.
Any comments and/or suggestions are welcome.
I uploaded an early stage of FbTk (Fluxbox Toolkit) Widget set, for
those who are interested.
There is documentation of almost all classes in FbTk and you'll find
UML chart of the Widget set in widgets-0.1.1/doc .
This is what needs to be done in FbTk:
Input focus to widgets
Widgets like: List, ScrollBar, TextButton
I'm not sure about having a m_name for every widget. It's nice to
have name on them when you debug but this widget set should probably
be very light weighted. It's not going to be a full widget set like
Gtk or Qt.
The toolbar is going to be a separate app.
And I was thinking about making the slit a separate app too, but I'm
And again, suggestions and comments are welcome.
From: Tomer Kol <tomer@cw...> - 2002-04-04 12:55:36
Just a few thoughts.
Looking at the UML chart =
I failed to see what encapsulates the frame notion.
I may be missing something, but the frame seems to be a fundamental =
I would expect to see a frame object, that contains an ordered set of =
Characteristics such as location and size seems to belong to the frame, =
set for a window dropped onto a frame. Similarly, a frame is shaded as a =
single entity, and not just the window in the foreground.
A new window should then implicitly create a frame to hold it, and a =
frame is deleted when it has no windows left, e.g., when its last window =
is closed or
dragged into another frame.