creating a menu

[mschnell1]

Is there an existing issue for this?

• I have searched the existing issues.

Is this issue related to iced?

• My hardware is compatible and my graphics drivers are up-to-date.

What happened?

I am able to create a nice GUI using iced using text, buttons, checkboxes, and radio buttons. I also was able to use the "Table" example as a template and create a draft of decent part of the GUI for my project.

Now I'd like to add context menus. I found that there is iced_widgets-0.12.0 menu.rs and in there we have

impl<'a, Message, Theme, Renderer> Overlay<'a, Message, Theme, Renderer>
where
    Message: 'a,
    Theme: StyleSheet + container::StyleSheet + scrollable::StyleSheet + 'a,
    Renderer: text::Renderer + 'a,
{
    pub fn new<T>(
        position: Point,
        menu: Menu<'a, T, Message, Theme, Renderer>,
        target_height: f32,
    ) -> Self
    where
        T: Clone + ToString,
    {
        let Menu {
...

So seemingly there is a decent implementation of an infrastructure for menus. Moreover I was able to compile and run the halloy project that very nicely shows a GUI that uses context menus (but i am not able to analyze this complex project without help.

I don't find any documentation or short example on how to implement a menu using iced.

Hence I need some help on that.

What is the expected behavior?

I should be enabled to use menus by appropriate documentation and examples

Version

crates.io release

Operating System

Windows

Do you have any log output?

not possible

[fogarecious]

I also had this problem.

I tried to implement a custom widget and return an overlay element in the widget's overlay method.
But nothing happened.

The code is roughly like this (where ... omits some code):

impl<...> Widget<...> for MyWidget {
    // ...
    fn overlay(...) -> ... {
        Some(Menu::new(...).overlay(...))
    }
}

[mschnell1]

I did not yet understand the concept of "overlay". And I only understand a small gimps of the "theme" stuff.
Moreover it seems to be possible and/or necessary to use multiple renderers ?!?!?

[brianch]

There's a ready to use context_menu widget in iced_aw: https://github.com/iced-rs/iced_aw/tree/main/examples/context_menu

The menu in iced_widget is the dropdown part of the picklist, that's why there's no example using it alone.

[mschnell1]

THIS does look promising ....

[hecrj]

This isn't a bug. Please, read the available options when creating a new issue carefully next time:

Feel free to ask for help in our Discord server or our Discourse forum.

[mschnell1]

@hecrj
Hmm.
I do "have a problem with the library", as I can't use part of it.
Of course I am aware that this is not a problem of the software, but of the documentation.
But why should that not be discussed on GitHub, where Documentation and examples are hosted / maintained together with the source code ? (Both is just text, and both is equally necessary for usage, after all. And of course both needs appropriate maintenance / user feedback for a crate to flourish. )
IMHO it would be best to have an appropriately "speaking" category "I have a problem with the library documentation" besides the "I have a problem with the library (code) ".
Many thanks for your attention (and making this crate happen) !

[hecrj]

I do "have a problem with the library", as I can't use part of it.
Of course I am aware that this is not a problem of the software, but of the documentation.

You are aware and decided to file a bug report anyways. A bit passive-aggresive, isn't it? Isn't this behavior suggesting that either you don't care or, even though you just arrived here, you think you know better than me how I should be managing my own project?

But why should that not be discussed on GitHub

Because the author of the project (the person that you are writing the bug report to, is giving you the software for free, and ultimately addresses everyone's feedback) explicitly and literally asks you to.

IMHO it would be best to have an appropriately "speaking" category "I have a problem with the library documentation" besides the "I have a problem with the library (code) ".

What would be "best" doesn't matter. What matters is how the maintainers of the software you use for free want you to interact with them. I don't want to receive "bug reports" about documentation on GitHub when there are clearly other channels set up to ask for help and discuss these topics.

Many thanks for your attention (and making this crate happen) !

You are welcome! I appreciate it.

[brianch]

@mschnell1 As Héctor pointed out, you're welcome to ask questions and discuss things in Discourse or Discord, they exist exactly for this purpose, which is nice because that way github doesn't get too crowded with general questions, which would make the triage of actual bugs very difficult.

I do "have a problem with the library", as I can't use part of it.

Perhaps there's still some misunderstanding, as I mentioned, the 'menu' that appears in iced_widget is just part of the picklist widget, it's not something to be used by itself. For context menus there's the iced_aw widget.

[mschnell1]

" For context menus there's the iced_aw widget."

Yep. Happily in this discussion I have been pointed to same and of course I will try to make use of same ASAP. I did a lot of research and have not been able to find the appropriate "entry point" before. Maybe over there is a better place to discuss the "menu's" documentation / example / findability issues.

Sorry, if I have been perceived as rude, stating that for me documentation is an integral part of any software. Maybe this is just me.

In fact I did quite a lot of (rather small) open source software projects (here on GitHub on the "ReaTeam" repository), and always try to do sufficient documentation, and improve the documentation (if I see a shortcoming or on request) together with the source code.

Thanks to all trying to improve the rust GUI world, which - as I seem to see - right now is one of the most "critical" areas of the fantastically evolving Rust world.

[hecrj]

@mschnell1 No worries! Every project works differently and has different priorities. Software or open-source doesn't ought to work in any particular way.

As Rich Hickey once wrote in "Open Source is Not About You":

The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.

In this case, documentation has not been a focus of ours yet, since the project is very experimental and the APIs have been changing wildly as we figure out the best way to approach GUIs in Rust. But even if we just simply did not want to write any documentation, that would be fine as well!

[mschnell1]

@hecrj

In this case, documentation has not been a focus of ours yet, since the project is very experimental and the APIs have been changing wildly as we figure out the best way to approach GUIs in Rust.

I see.

For some time I have been involved in the "Lazarus" project (which is an open source version of the commercial "Delphi" software which features an extremely convenient way of doing GUI projects with a native compiled langauge). Hence I supposedly am spoiled in my attitude about GUI handling. After deciding to do all new projects in Rust I amoung other things evaluate the GUI crates and seemingly (regarding the great impression I got from the core of the Rust world) this is more bleeding edge than I expected. So thanks for baering with me.

Maybe come time, I might even be able to conrtibute something sensible :)