XUL custom layout
  • andy_oneandy_one December 2012

    Hi Dave! Many many thanks for this awesome project. 

    I have question about XUL interface layouts. At this moment default layout have 2 columns. One for labels and second for elements like textarea and dropdown. How I can customize layout using basic API methods (addButton, addDropdown and etc).

    And small second question. How I can select some element in Listbox?

  • DaveDave December 2012

    Hey Andy,

    Thanks! Glad you like it and it's doing the job for you :)

    XUL and xJSFL's take on it is always a bit of a compromise. I was always planning to make it even more customisable, but it's complex! And the xJSFL XUL class is already one of the biggest in the framework, if not, the biggest.

    Regarding the two-column label/control combo you mentioned, the existing methods should cover you, but if not, the setXML() method which attempts to parse the XML and add handlers:

    http://www.xjsfl.com/support/api/ui/xul#setXML

    And look here for setting values: http://www.xjsfl.com/support/api/ui/xul#setValues

    Hope that helps! XUL is, as you've seen, a big class with lots to remember.

    :D

  • andy_oneandy_one December 2012

    Thanks for setValues this is exactly what I was looking for.

  • andy_oneandy_one December 2012
    Dave said: XUL and xJSFL's take on it is always a bit of a compromise. I was always planning to make it even more customisable, but it's complex!

    This is easier than it seems. I modified the XUL to allow the use of custom styling (a couple of hours of work and about 150 lines of code).

    Code (version 2 with same result). Result.

     

  • DaveDave December 2012

    Looks good! Care to post the generated XML?

    The setXML() method should be able to take any XML and post-apply all the handlers and such like that XUL requires. This means you should be able to pass any (hand-coded or otherwise) XML layout in, and it should (in theory - by the time XUL was finished, I just wanted it out the door) wire up any controls it finds.

    Ultimately, the plan was to split the main XUL class into a whole bunch of (extendible) subclasses. That way you'd have XULCheckbox, XULDropdown, XULMyCustomControlSet, etc and would be able to build a XULDialog as you saw fit, or even extend a core control with your own properties.

    Each class would have core methods, such as init(), layout(), draw(), extending upon a core control which would have methods such as getValue(), setValue(), handleEvent(), etc.

    The ultimate plan would be that one could create any style of dialog (so, not just 2-column) just by extending the core classes.

    Unfortunately, due to how limited the Adobe (Macromedia) implementation of XUL is, I decided to put that on hold, as it seems like a lot of effort, just to support an fairly badly-implemented API in the first place. Often it's just easier to build your dialog using the API, then grab the generated XML and start customising that.

    Then of course, there's the trade off of "how cool do I want to make this" vs "who is / how many are actually going to use this" ! The answer for JSFL I fear is, "not that many" :(

    Anyway. Great stuff!

    Dave

  • DaveDave December 2012

    PS. Did you have to hack the core code, or did you manage to create a bit of code that could be just added on, and used the return values from the main XUL class?

  • andy_oneandy_one December 2012
    Dave said: PS. Did you have to hack the core code, or did you manage to create a bit of code that could be just added on, and used the return values from the main XUL class?

    This code simply extends XUL class and work around setXML method and exists templates. Modified XUL you can checkout there. Of course it's simple proof of concept, not production ready code.

    Dave said: Then of course, there's the trade off of "how cool do I want to make this" vs "who is / how many are actually going to use this" ! The answer for JSFL I fear is, "not that many" :(

    I think that's okay. Most people are not using jsfl because don't understand what issue can resolve with it. For example when I told about our project based on xjsfl, people says "Wow, I didn't think what it's was possible!".

    Dave said: Ultimately, the plan was to split the main XUL class into a whole bunch of (extendible) subclasses.

    I'm not sure what is good idea. xJSFL is already fairly large project with many relations between parts of code. It's very good tool for making snippets with 200-300 lines of code on average. But I doubt the correctness of creating large products based on it. Mainly due disgusting implementation quality by Adobe. IMHO xJSFL must be simple as possible.

  • DaveDave December 2012

    Yeah, it's a shame that the XUL implementation is so weak, when applications like Komodo leverage Mozilla's XUL implementation so well. I hope this gets addressed in the next or subsequent update cycle though.

    I'll have to diff the code you gisted so I can see what you added, but great you're extending!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with OpenID Sign In with Google Sign In with Twitter

Sign In Apply for Membership

Tagged