Andrey Prigogin schrieb:
Ok, here is what I am doing right now.
The container widget SfNavMenu extends QxVerticalBoxLayout(Sf is my namespace,
will change it to Qx when and if this widget is useful in qooxdoo) has a
property maxHeight, which ultimatelly governs how many items could be displayed
fully. In the constructor for SfNavMenu i am adding icon box as the last
element. I override .add method from QxWidget so that add adds items to the
position next to last (last item is the iconbox). SfNavMenu also has
QxRadioManager for managing item selection. The handler for _modifyMaxHeight,
figures out how many items can be displayed fully with labels and larger icons
and either moves items from icon box at the bottom to self or the other way
arround. The menu will fire selection change event so that listeners can be
attached.
If you overwrite "add" you change the default behaviour of core methods
in qooxdoo. Sometimes there is no way around this, but if you not really
rely on this I think it's better to not do this.
Each item is SfNavMenuButton extends QxAtom. SfNavMenuButtons can find which
QxNavMenu they belong to, by traversing parent hierarchy to find
SfNavMenu.prototype.isPrototypeOf(curParent). This way there is no hard linking
between items and menu that contains it. The handler _modifyParent will take
care of registering/unregistering items with the manager from the parent menu.
It is sort of lame that moving item from iconbox to the menu will trigger
unregister/register, but that's ok i guess. SfNavMenuButton will also have
methods for converting them between showing both icon and text and showing
smaller icon. These methods will be called from inside _modifyParent handler.
It also overrides _modifyFont method to only change font on the label part of
QxAtom.
This Atom patching is not anymore neccessary as there is no font
property anymore in QxAtom.
One difference from 0.1.4 release that I find to be somewhat annoying is that
in 0.1.4 changes in widget state where also reflected in its cssClassName,
which allowed me to do skinning of the widget through my stylesheet that
referenced images from my images directory via relative path for backgrounds
and such. Without this functionality doing css custom skinning is impossible,
and i am currently forced to hardcode image paths inside the widget code.
CSS styling is not the way to go in renderer. We will move all the
appearance related things a new internal handling which allows you to
write your own appearance for any widget in qooxdoo.
Probably we can add something like a custom image path to the image
manager. Currently there are some transparent extended path stuff like:
images/icons/...
images/widgets/...
Then this:
images/custom/...
could be translated into a own path of images. This has nothing todo
with your widget problem, but is just another idea to allow the
developer of the application (not of the classes) to easily embed images
from other pathes than the qooxdoo image root.
In your case, why not just put your background graphics to the widget
stuff inside "windows". Create a new directory there for your widget and
put your images then inside. You should then be able to simply use
something like:
images/widgets/yourWidget/background1.png
as an image path for the background image.
What is the thinking with regards to this?
I think that ability to skin widgets through a custom stylesheet is a killer
feature, especially in the new world of gradient backgrounds. We should at
least provide an api for adding css class name modifiers like
addCssClassName/removeCssClassName from 0.1.4.
As I explained before this will be completly removed with the next
release. Styles from CSS, especially when using stuff like padding,
borders and so on make it very hard for us to layout widgets correctly
because these class definitions are only available after the element is
created. Also there is no "event" if there are pseudoclasses like
"hover" applied to elements, which needs a special handling on events
sometimes. We have tried it this way, but have choosen that it is to
hard to go further.
Regards,
Sebastian
thanks,
andrey.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
