IupConvertXYToPos is limited to a few elements (IupText, IupScintilla, IupList, IupTree and IupMatrix), it's currently implemented in the Element trait.

However it seems like a case it should be either:

• Move into a separate trait...
• or maybe add directly in the implementation of those specific controls.

Thoughts?

There are two types of elements:

• Those that are containers (e.g. dialog, frame, hbo, vbox, etc) and can store other elements in it. They can have parents, childs and a brother. For instance IupAppend only works on those containers.
• Those that are final nodes, they can have parents and a brother but cannot have childs. The container containers are a superset of this node type.

Currently all the hierarchy operations are implemented in the Element trait. Should those prehaps be separated in two traits instead of leaving them in Element?

The upside I see is that it'll be cleaner which objects are containers and which aren't. The downsides is that Handle would need to implement both (?) and give the doubt if the contained handle is really part of that trait.

Adds the ability to use Rust closures as callbacks to IUP. Very trivial to add new callbacks, see the impl_callback! documentation.

Also see examples/counter_newcb.rs for examples/counter.rs rewritten with closures.

Make .travis.yml publish the result of cargo doc somewhere. I don't recommend to host the docs on rust-ci as the documentation gets outdated on it due to hansjorg/rust-ci#22.

Instead, host it in ghpages of the project by using ghp-import. See how the hyper project does it here.

From IUP docs

If IupMainLoop is called without any visible dialogs and no active timers, the application will hang and will not be possible to close the main loop. The process will have to be interrupted by the system.

So we should perhaps enforce a visible dialog by making the user return a dialog (wrapped in a Result?) from the f closure passed to with_iup

Though what about this and no active timers parts?!?!?!! That probably means we're able to call IupMainLoop with no active dialogs if the user have set up a timer in f, how to deal with this?

The objects we are implementing here are just a newtype over a raw pointer with no Drop (as the objects are managed internally by IUP). So prehaps they should be Copy?

Currently it does not implement Clone either and there is a fn dup(&self) -> Self; in the Element trait for that purposes, this should probably be removed when this issue is resolved...

The downside I see by using Copy is that it might look like we are not dealing with a object. And the downside I see by using Clone is it gives a look of deep copying the entire object but we'll just be copying a loose handle.

However I see a huge upside in using Copy, we'll not need to wrap the objects in a Rc<RefCell<_>> and add a scope, and add a clone call for every closure callback that wants access to those as seen in the counter.rs example (and seen worser in the older counter example).

There is a impl From<E: Element> for Handle implemented (which allows Handle::from(elem) and at most elem.into()) to allow a conversion between specialized objects to a basic elemental handle and there's also a pub fn from_element<E: Element>(elem: E) -> Handle implemented as a constructor of the Handle object.

Should the from_element constructor be removed in favor of From trait?

Note there are other from-like methods in the Element trait (Handle is also a Element), those shouldn't be removed but it's good to think they exist in relation to from_element:

• fn from_handle(handle: Handle) -> Result<Self, Handle>
• unsafe fn from_raw_unchecked(ih: *mut iup_sys::Ihandle) -> Self
• fn from_raw(ih: *mut iup_sys::Ihandle) -> Self

dcampbell24/iup-rust now has a Chat Room on Gitter

@thelink2012 has just created a chat room. You can visit it here: https://gitter.im/dcampbell24/iup-rust.

This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.

Happy chatting.

PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

LED (dialog specification language) is an language (by the IUP folks) used to very expressively describe a user-interface in textual-form.

The grammar of this language is very simple, it's only a matter of

elem = element[attribute1=value1,attribute2=value2,...](...expression...)

Where:

• elem maps to a handle (as in IupSetHandle).
• element maps to a GUI object (e.g. vbox, button, radio).
• attributes and values maps to IupSetAttribute.
• expression is specific to each GUI object and is well specified in the documentation of them (e.g. for vbox it's a variadic parameter list of children; for button it's the title and the action callback name (as in IupSetFunction)).

An example of LED source file can be found here. More info about it can be found here.

An LED file can be easily loaded by the IupLoad or, from a string, by IupLoadBuffer. However, I see two issues with it:

1. Distributing a .led file alongside the executable may be a inconvenience.
2. IupSetHandle and IupSetFunction does not go very well in Rust.

in C 1. can be bypassed by using the ledc compiler which transforms a .led file into a .c file. While the 2. is a non-issue as type-safety is not much of a concern there and casts are all over the place.

A led2rs may be tiring to write and may still not fix the issue 2.; So I propose a led! or iup_led! macro! The led grammar maps very well to the rust grammar and with the powerful macro system rust has it's perfectly possible to build a led compiler inside it.

The macro should be used in a expression context, and it returns a dialog (or whatever GUI object is presented last in the macro). We clearly see how it solves issue 1. but what about issue 2.?

• Assignments in LED should assign to outer-scope variables instead of IupSetHandle (prehaps do both).
• Callbacks expressions should take a closure as argument instead of a string.

With this we also gain another feature in the LED language, the ability to use any expression as the evaluator for attribute values [attrib={/*eval*/}] and the same for the GUI object constructor expression ({/* eval title */}, {/* eval closure*/}).

An concern is the fact LED is case insensitive:

In LED there is no distinction between upper and lower case, except for attribute names.

So we should choose either lower or upper case, I'd choose lower.

To finalize this lovely brainstorm, here's a possibly usage example:

fn main() {
    /* ... */
    let mybutton;
    let mydialog = iup_led!(
        mybutton = button []("Button Name", |_| println!("Clicked!"))
        dialog [TITLE="Window Name"] (mybutton) // the macro should return this dialog
    );
    /* ... */
}

A step to the a high-level binding is to decide the object model to be used, each has pros and cons, mainly because of the C model used in IUP.

Note: The pros and cons lists are not exhaustive, please consider adding more if any comes to mind.

Terminology:

• string attributes: Using IupGetAttribute and IupSetAttribute which gets and sets a string instead of a well specified object type.
• function/methods for attributes: Using a function/method for each attribute, giving more type safety to it since each of those functions will set/get the correct type of the attribute instead of a string.

Ihandle and Functions (using string attributes)

This is the current model in the library, all the IUP objects are described with a Ihandle structure and passed to functions as the first argument.

Pros:

• Simple model.
• Maps 1:1 to IUP documentation

Cons:

• Attributes aren't type-safe.
• Not possible to find out about attributes by using auto-completion.
• Annoying &mut handle on each function call.

Ihandle and Functions (using functions for attributes)

Pros

• Simple model.
• Maps almost 1:1 to IUP documentation.
• Type-safe attributes.
• Possible to find out about attributes by using auto-completion.

Cons:

• Annoying &mut handle on each function call.

Ihandle and Methods

Mirror Ihandle and Functions (using string attributes) and Ihandle and Functions (using functions for attributes) here by excluding the Annoying &mut handle on each function call cons.

Structs/Traits and Methods (using methods for attributes)

Pros:

• More Rusty
• Very type-safe.
• Possible to find out about attributes by using auto-completion + only the attributes and callbacks that applies to this object in question.

Cons:

• Complex model.
• Does not map 1:1 to IUP documentation.

Issues:

• How to deal with functions that returns a handle to any kind of object (e.g. IupGetHandle)?

a breaking (but backwards compatible) change was introduced into rustc. This commit makes sure that iup works now on all rust versions after 1.0

sorry about the whitespace noise

I suggest removing the Self return type from run, stop and set_time. Or changing it to &mut Self so chaining still works but you don't accidentally unwrap the Guard while still having the guard.

Even better would probably be to remove the Guard alltogether and implement Drop for Timer. That would remove the possibility for others to stop/start the timer. So another way would be to simply use Rc instead of Guard.

IUP uses a encoding depending on the C locale, Rust is Unicode aware by the means of UTF-8. Thus the UTF-8 mode of IUP must be enabled by us right after calling IupOpen, the global attributes are UTF8MODE and UTF8MODE_FILE (docs here).

Additionally it should be clearly documented we turn UTF-8 mode ON so the user don't need to worry about it.

Some conventions on the functions must be discussed...

Null parameters

Some functions allow null pointers to be passed to them.. For instance IupInsert and IupReparent allow the ref_child parameter to be NULL essentially making the first found child to be used as the ref_child.

Currently our binding enforces the passing of ref_child (i.e. it's not a Option).

fn insert<E1, E2>(&mut self, ref_child: &E1, new_child: E2) -> Result<Handle, E2>
                where E1: Element, E2: Element {

The thing is, if it was a Option, passing None as parameter would bring a error that it does not know enough about E1 constraint and thus we'd need to specify it explicitly (e.g. None::<Handle>) and that does not look quite beauty.

What should be done in such cases?

There is also this other related on Dialogs:

pub fn new<E: Element>(child: E) -> Dialog
pub fn new_empty() -> Dialog

Didn't use a single new with a Option parameter for that very same reason.

And that brings us to another issue.

Constructor namings

Should we use a fn new<E: Element>(child: E) -> Dialog or fn with<E: Element>(child: E) -> Dialog or use a Option (see previous topic)? The same question applies to layout boxes and other container objects.

If still new without Option should the empty version be named new_empty?

As a side note, buttons (and other future controls?!) does it this way:

fn new() -> Button
fn with_title<S: Into<String>>(title: S) -> Button
fn with_image(image: ?)  -> Button // in the future

Get/Set

Currently the library follows Rust guidelines of setters having a set_ prefix and getters having no prefix (e.g. set_attrib sets and attrib gets, parent instead of get_parent and so on), that seems the way to go but if there's any contradiction to it please enlighten me.

Result

Since IUP does not give any manner of a descriptive error message (with strings), we shouldn't perhaps be returning Result<T, String> mainly in the cases only IUP_NOERROR and IUP_ERROR are possible.

We should be using Result<T, ()> (or anything along those lines) for the case where there can be only one single error (e.g. IUP_ERROR) and use a Result<T, Enum in cases it may return different error types (i.e. with_iup).

Another issue with strings is that they cannot be matched to easily find out what happened wrong in the multi-error case.

Tracking progress on the events section of iup docs. If you wish to implement any of those items leave a comment :)

Functions:

• [x] IupMainLoop
  • Wrapped in with_iup.
• [ ] IupMainLoopLevel
  • Must make with_iup be able to be called several times like IupMainLoop is able to.
• [ ] IupLoopStep
• [ ] IupExitLoop
• [ ] IupFlush
• [ ] IupGetCallback
• [X] IupSetCallback
  • Abstracted off in the callback submodule.
• [ ] IupRecordInput
• [ ] IupPlayInput

IupSetCallbacks won't be implemented.

Common:

• [x] IDLE_ACTION
• [x] MAP_CB
• [x] UNMAP_CB
• [x] DESTROY_CB
• [x] GETFOCUS_CB
• [x] KILLFOCUS_CB
• [x] ENTERWINDOW_CB
• [x] LEAVEWINDOW_CB
• [ ] K_
  • [ ] K_ANY
  • [ ] K_*
• [x] HELP_CB
• [x] ACTION

Other:

• [ ] Drag&Drop

Tracking progress on attributes. If you wish to implement any of those items leave a comment :)

This issue is not about method to access individual attributes on each control, instead about the general attribute system. At this moment making attributes as methods is not a priority (but will mostly like come to life later on) and thus why this is not a track of attribute as methods.

Main: Some of the items here must be skeptically taken a look to realize if they are actually needed.

• [ ] IupSetAttribute
  • [x] IupSetAttribute
  • [x] IupSetStrAttribute
  • [ ] IupSetAttributeId
  • [ ] IupSetStrAttributeId
  • [ ] IupSetAttributeId2
  • [ ] IupSetStrAttributeId2
• [x] IupResetAttribute
• [x] IupSetAttributeHandle
• [ ] IupGetAttribute
  • [x] IupGetAttribute
  • [x] IupGetStrAttribute
  • [ ] IupGetAttributeId
  • [ ] IupGetStrAttributeId
  • [ ] IupGetAttributeId2
  • [ ] IupGetStrAttributeId2
• [x] IupGetAllAttributes
• [x] IupGetAttributeHandle
• [x] IupSetGlobal
• [x] IupSetStrGlobal
• [x] IupGetGlobal
• [x] IupGetStrGlobal

The IupSetAttributes IupGetAttributes, and IupSetAtt aren't going to be implemented either because they don't fit rust or to avoid over-bloat of functions that does essentially the same thing with no advantage over the simpler version.

Sub functions will not to be implemented (at least not until we start doing attribute methods), they are a major bloat that does not even provide a performance gain (please leave a comment if you disagree with this!)

Tracking progress on resources. If you wish to implement any of those items leave a comment :)

• [x] LED
• [ ] Fonts
  • Since fonts are attributes (working) and the purpose of this item is to have a trait for fonteable controls, it's not a priority right now.
• [x] Images
• [ ] Keyboard
• [ ] Menus
• [ ] Handle Names
  • [x] IupSetHandle
  • [x] IupGetHandle
  • [x] IupGetName
  • [ ] IupGetAllNames
  • [ ] IupGetAllDialogs
• [ ] String Names
  • [ ] IupSetLanguage
  • [ ] IupGetLanguage
  • [ ] IupSetLanguageString
  • [ ] IupGetLanguageString
  • [ ] IupSetLanguagePack
• [x] IupClipboard
• [x] IupTimer
• [ ] IupUser
• [ ] IupConfig
• [ ] IupHelp