/usr/share/doc/libhippocanvas-1-0/TODO is in libhippocanvas-1-0 0.3.1-1.2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 | List of possible future enhancements / likely directions, we are doing these "as needed"
- Avoid having to always align images
image item should maybe default to center alignment instead of fill like most items do
- Allow composite items to be activated/prelighted
e.g. in one place in mugshot we have a CLOSE link and then an X icon next to it; should be able
to make the box containing those two a composite button, where the whole thing prelights
as a whole, and you can connect to "activated" on the whole thing.
One way to do this would be to make HippoCanvasBox::clickable into a settable
property; and if a box is clickable, do not forward click events to
its children, instead just activate the parent. This doesn't address
prelighting the composite as a whole though.
- Clean up cascading styles
Right now affect_font_desc / affect_color / get_color are on HippoCanvasContext,
they should probably all be on a separate interface (HippoStylist?) or something
like that. Then HippoStyle would also implement this interface perhaps. Or maybe
these go on HippoCanvasContainer somehow?
- Set class-default font and colors
if you allow setting a box to "gray 11px" for example, then the CanvasLink items in there
will override the gray with blue, since links default to blue. So each item should
first use its own props, then its context's props, then its class props, then its
parent class props.
There's a little hack around this right now with HippoCanvasBoxClass::default_color
- The return value of button press event needs to be known by the
parent in advance.
If the parent is going to handle the click if the child doesn't, then it needs
to be able to display prelights and change the mouse cursor and so forth.
One approach might be to generalize get_pointer to return some kind of
"what-this-item-handles-info" (and enforce it by not delivering events
the item doesn't say it will handle)
Or get_pointer and get_tooltip could be merged into a sort of "hover state"
indicating info about the hover point.
The "handles click" flag is probably per-mouse-button.
- To handle tooltips correctly, a widget or CanvasBox displaying a canvas item
really needs a unique ID for a each different logical zone that's returned.
Both the tooltip text and the for_area can change while the pointer is
still inside the same logical element of the display.
This could be done by having in a "hover state" the desired mouse pointer,
tooltip text, tooltip area, and an "owner" made up of a pointer (usually
a canvas item pointer) and an integer id.
- Summarizing the last two ideas, an ugly version might be:
struct {
HippoCanvasPointer pointer;
char *tooltip;
HippoRectangle area;
void *owner_id_pointer_part;
int owner_id_int_part;
} ButtonOneHandlerInfo;
/* returns true if it handles */
gboolean (* get_button_one_handling) (HippoCanvasItem *item,
ButtonOneHandlingInfo *info_p);
|